copilot-cli icon indicating copy to clipboard operation
copilot-cli copied to clipboard

Policies/Roles and Debugging Access Issues

Open Offlein opened this issue 6 months ago • 1 comments

Hello! I'm using a copilot "Scheduled Job" to do database sanitization. This should run in ECS and run some bash scripts that use the aws CLI tools.

My understanding is that if the ECS running user has certain access (via Policies, I guess?) the aws command will recognize this and use those somehow. These should all be related to rds.

It seems to me the easiest way to do this would be to define an IAM "role" with the appropriate permissions and then somehow have the ECS task user get this role... But I don't see any way to do that.

What I do see is that I can create a PolicyDocument resource as an "Addon", where I guess it creates an inline policy for that running ECS user and, as I understand it, that should do the same. Is that right?

  1. In my /copilot/ directory I have /copilot/db-sanitization/manifest.json representing the Scheduled Job. And I created a /copilot/db-sanitization/addons/rds.yml to grant the permissions I think I need.

  2. I determined the permissions I needed by using the IAM Policy builder GUI and adding some RDS-specific permissions. The UI indicated I needed to also add some other other permissions (e.g. kms:Decrypt, kms:DescribeKey, secretsmanager:RotateSecret and a bunch of other seemingly random things), so I specified all of these.

Here is what my addons/rds.yml looks like:

# Your additional_policy.yml
Parameters:
  App:
    Type: String
  Env:
    Type: String
  Name:
    Type: String

Resources:
  RdsPolicy:
    Type: AWS::IAM::ManagedPolicy
    Properties:
      PolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Sid: AccessRds
            Effect: Allow
            Action:
                - rds:DescribeDBClusterSnapshotAttributes
                - kms:Decrypt
                - rds:DescribeDBSnapshots
                - secretsmanager:CreateSecret
                - rds:DescribeDBSnapshotAttributes
                - rds:RestoreDBInstanceFromDBSnapshot
                - rds:DescribeDBClusterSnapshots
                - kms:GenerateDataKey
                - rds:DescribeDBInstances
                - secretsmanager:RotateSecret
                - kms:DescribeKey
                - rds:ModifyDBInstance
                - kms:CreateGrant
                - rds:DescribeDBClusters
                - rds:DeleteDBInstance
                - secretsmanager:TagResource
            Resource: "*"

Outputs:
  RdsPolicyArn:
    Description: "The ARN of the ManagedPolicy to attach to the task role."
    Value: !Ref RdsPolicy

In my CloudWatch logs, however, I get access errors for each shell script aws tool call.

E.g. when I do aws rds restore-db-instance-from-db-snapshot ...{stuff}... the output is:

An error occurred (AccessDenied) when calling the RestoreDBInstanceFromDBSnapshot operation: User: arn:aws:sts::xxxxxxx:assumed-role/xxxxxxxx-TaskRole-xxxxxxxxx/xxxxxxxxxxxx is not authorized to perform: rds:AddTagsToResource on resource: arn:aws:rds:xxxxxx:xxxxxxx:db:xxxxxxxx because no identity-based policy allows the rds:AddTagsToResource action

I believe that my addon is being used, because when I had an issue in the syntax of the document, I couldn't deploy it at all. But I don't know how to check what actually is happening here to see if I screwed up the PolicyDocument or something else.

Thank you!

Offlein avatar Jan 25 '24 20:01 Offlein

Hello @Offlein Can you add this action rds:AddTagsToResource to the Policy document which is at this location copilot/db-sanitization/addons/rds.yml and deploy the service again so that TaskRole will have necessary permissions.

Let me know if this fix the above error!

KollaAdithya avatar Jan 29 '24 17:01 KollaAdithya

This issue is stale because it has been open 60 days with no response activity. Remove the stale label, add a comment, or this will be closed in 14 days.

github-actions[bot] avatar Apr 03 '24 00:04 github-actions[bot]

This issue is closed due to inactivity. Feel free to reopen the issue if you have any further questions!

github-actions[bot] avatar Apr 17 '24 00:04 github-actions[bot]