-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Open
Labels
area: integration/cdkIssues related to AWS Cloud Development KitIssues related to AWS Cloud Development Kitaws:cloudformationAWS CloudFormationAWS CloudFormationstatus: backlogTriaged but not yet being worked onTriaged but not yet being worked ontype: bugBug reportBug report
Description
Is there an existing issue for this?
- I have searched the existing issues
Current Behavior
Hello, I am reporting two issues that I've encountered re: cdk deploy
.
- User-defined policies do not appear to be created (and therefore cannot be attached) to their target IAM Role.
- Providing a
--cloudformation-execution-policies
ARN on the CLI appears to fail because the value is being processes as a string rather than list.
Problem 1: User defined policies missing
- My localstack instance is configured to enforce IAM (via
ENFORCE_IAM=1
in my docker-compose.yml) - I am using the default
sample-app
configuration provided by CDK. - I generated the Cloudformation template that will be executed by localstack with this command:
cdklocal bootstrap --cloudformation-execution-policies 'arn:aws:iam::aws:policy/AdministratorAccess' aws://000000000000/us-east-1 --show-template > bootstrap-template.yaml
- The template has 5
AWS::IAM::Role
entries. Of these, the LookupRole and DeploymentActionRole entries have associated Policies. - I execute the
cdklocal bootstrap
command successfully. - Subsequent attempts to
cdklocal deploy
fail due to IAM rejection: e.g.2022-02-07T12:34:02.805:DEBUG:localstack_ext.services.edge: Denying request for API "cloudformation" due to IAM enforcement: POST / - Access denied
- When I check which Policies are attached to the Roles which need to interact with localstack during a CDK deploy, I see that the policies aren't attached, nor do they even exist in IAM. The Managed Policy, however, is successfully attached.
- I can successfully deploy once I manually attach permissions to these two Roles (I used AdministratorAccess for convenience while debugging the issue).
Problem 2: CDK CLI-passed argument parses as string
- I tried to manually specify the execution policy that the CDK's
...cfn-exec-role...
Role should use when deploying. - I used the following command:
cdklocal bootstrap --cloudformation-execution-policies 'arn:aws:iam::aws:policy/AdministratorAccess,arn:aws:iam::aws:policy/AWSLambda_FullAccess' --trust 000000000000 aws://000000000000/us-east-1
- This resulted in a Parameter validation error (see screenshot).
- With additional logging and investigation, I isolated the problem to here - the arn was being processed character-by-character rather than as a single list entry.
- I fixed the problem by adding some hacky code into a custom copy of the
iam.py
file mounted directly into my docker-compose.yaml
Expected Behavior
- I expect user-defined policies passed in through the CDK Cloudformation to be created and attached to their associated Roles.
- I expect an ARN passed in via the CDK CLI to be parsed as a single object, not individual characters.
How are you starting LocalStack?
With a docker-compose file
Steps To Reproduce
Problem 1:
docker-compose up --build
- <install CDK & CDKLocal>
mkdir myFirstCDK && cd myFirstCDK
cdklocal init app --language python
cdklocal bootstrap aws://000000000000/us-east-1
Problem 2:
docker-compose up --build
- <install CDK & CDKLocal>
mkdir myFirstCDK && cd myFirstCDK
cdklocal init app --language python
cdklocal bootstrap --cloudformation-execution-policies 'arn:aws:iam::aws:policy/AdministratorAccess,arn:aws:iam::aws:policy/AWSLambda_FullAccess' --trust 000000000000 aws://000000000000/us-east-1
Environment
- OS: Ubuntu 20.04 on Windows 10
- LocalStack: latest (Feb 5th 2022 pull)
Anything else?
No response
umairyounus, mcolombosperoni and MathiasKoch
Metadata
Metadata
Assignees
Labels
area: integration/cdkIssues related to AWS Cloud Development KitIssues related to AWS Cloud Development Kitaws:cloudformationAWS CloudFormationAWS CloudFormationstatus: backlogTriaged but not yet being worked onTriaged but not yet being worked ontype: bugBug reportBug report