cloud-custodian icon indicating copy to clipboard operation
cloud-custodian copied to clipboard

Validation failed for using "copy-related-tag" to copy tags from rds-cluster to rds intances

Open yufuluo opened this issue 4 years ago • 4 comments

Describe the bug I am trying to copy tags from rds-cluster to the instances in the cluster with the following policy:

policies:
  - name: rds-copy-cluster-tags-to-instance
    resource: rds
    filters:
      - type: value
        key: DBInstanceStatus
        op: eq
        value: available
    actions:
      - type: copy-related-tag
        resource: rds-cluster
        skip_missing: true
        key: DBClusterIdentifier
        tags:
          - Email

The policy itself actually works fine. However, it failed with policy validation, thus breaking our pipeline.

To Reproduce Run the following command:

custodian validate policies/rds_copy_cluster_tags_to_instance.yml

And it returns the following error:

2021-07-02 14:13:46,667: custodian.commands:ERROR Configuration invalid: policies/rds_copy_cluster_tags_to_instance.yml
2021-07-02 14:13:46,667: custodian.commands:ERROR Policy: rds-copy-cluster-tags-to-instance is invalid: Error: Invalid resource type selected: rds-cluster

Expected behavior The validation should pass.

Background (please complete the following information):

  • OS: OSX 10.15.7 and Ubuntu 18.04
  • Python Version: 3.8.7
  • Custodian Version: 0.9.12
  • Cloud Provider: aws
  • custodian version --debug output
Custodian:   0.9.12
Python:      3.8.7 (default, Dec 30 2020, 10:13:08) 
            [Clang 12.0.0 (clang-1200.0.32.28)]
Platform:    posix.uname_result(sysname='Darwin', nodename='USLC02ZV4S4MD6P', release='19.6.0', version='Darwin Kernel Version 19.6.0: Thu May  6 00:48:39 PDT 2021; root:xnu-6153.141.33~1/RELEASE_X86_64', machine='x86_64')
Using venv:  False
Docker: False
Installed: 

argcomplete==1.12.3
attrs==21.2.0
boto3==1.17.96
botocore==1.20.96
importlib-metadata==4.5.0
jmespath==0.10.0
jsonschema==3.2.0
pyrsistent==0.17.3
python-dateutil==2.8.1
pyyaml==5.4.1
s3transfer==0.4.2
setuptools==51.1.1
six==1.16.0
tabulate==0.8.9
typing-extensions==3.10.0.0
urllib3==1.26.5
zipp==3.4.1

yufuluo avatar Jul 02 '21 21:07 yufuluo

Thanks for reporting this @yufuluo, I'm seeing this too. After a bit of poking at it, I think it stems from the way we're lazy loading resources in the validate command here.

Looks like we're only loading resources that are specified in the top-level resource key of a policy. So when the copy-related-tag action's validation logic fires here, it doesn't know about rds-cluster. We can verify that with a policy file like this, which does validate because it sees and loads the rds-cluster resource.

policies:
  - name: no-op-just-loading-resource-data
    resource: rds-cluster
    conditions:
      - type: value
        key: now
        value_type: date
        value: "2300-01-01"
        op: greater-than

  - name: rds-copy-cluster-tags-to-instance
    resource: rds
    filters:
      - type: value
        key: DBInstanceStatus
        op: eq
        value: available
    actions:
      - type: copy-related-tag
        resource: rds-cluster
        skip_missing: true
        key: DBClusterIdentifier
        tags:
          - Email

If this policy runs successfully for you, I would imagine you're running an rds-cluster policy earlier in the same custodian session?

One way to address this issue would be to look for resource keys deeper in a policy structure during validation (whether explicitly in the copy-related-tag or more generally). I'm not sure if that's the best/right approach though.

ajkerrigan avatar Jul 09 '21 00:07 ajkerrigan

Hi @ajkerrigan thanks for looking into the issue! Adding the load-data policy does help validation pass!

I am running cloud custodian on k8s containers, so each time it's a clean environment. Even if I just run this single policy, it can be executed successfully, while the validation would fail if not adding the load-data policy before the copy-related-tag. (But I use custodian validate command for validation, while using c7n-org run command to run the policy. Does that make any difference?)

yufuluo avatar Jul 09 '21 18:07 yufuluo

A related question came up in Gitter today, in that case trying to copy aws.ebs-snapshot tags to an aws.ami resource. I'm thinking it may be worthwhile to:

  • Ensure that all AWS resources are loaded before this check fires, perhaps by calling load_resources(('aws.*',)) first
  • Normalize the related resource name by stripping off any provider prefix, so ebs-snapshot or aws.ebs-snapshot would both pass validation

Regarding normalization, one approach would be changing:

related_resource = self.data['resource']

to:

related_resource = self.data['resource'].rpartition('.')[-1]

ajkerrigan avatar Nov 12 '21 16:11 ajkerrigan

Has any progress been made on this issue? I'm still seeing this error in 0.9.15 when trying to copy tags from an rds-cluster to an instance, and it is causing our build pipeline to fail.

mattheidelbaugh avatar Jun 30 '22 20:06 mattheidelbaugh