Privilege escalation in codepipeline ecs deploy action
See original GitHub issueThe deploy action for ECS in a codepipeline attaches an iam:PassRole
action to the codepipeline role which allows it to pass any role to ec2 and ecs-tasks:
This opens a potential privilege escalation.
The resources section of the statement should instead reference the relevant role for the ECS deployment I believe.
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (1 by maintainers)
Top Results From Across the Web
Tutorial: Amazon ECS Standard Deployment with CodePipeline
This tutorial helps you to create a complete, end-to-end continuous deployment (CD) pipeline with Amazon ECS with CodePipeline.
Read more >The risk of CI/CD pipeline poisoning via CodeBuild
In this subsection, we describe the actions performed by the CPPT tool to demonstrate that a developer can poison a CodePipeline CI/CD pipeline...
Read more >AWS - DataPipeline, CodePipeline, CodeBuild & CodeCommit ...
CodePipeline automates the build, test, and deploy phases of your release ... you can check how to abuse codepipeline permissions to escalate privileges:....
Read more >Ensure containers do not run with AllowPrivilegeEscalation
Kubernetes. Resource: Container; Argument: allowPrivilegeEscalation (Optional) If false, the pod can not request to allow privilege escalation. Default to ...
Read more >Investigating Privilege Escalation Methods in AWS - Bishop Fox
To escalate privileges, the user creates a new policy document that permits all AWS actions: $ cat admin_policy.json { "Version": "2012-10-17", ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I am 99% sure I just don’t have the whole context or am misunderstanding, but is there a reason the condition check is a
StringEqualsIfExists
instead of aStringEquals
? I know this doesn’t address the*
resources issue, but why is this policy expected to still allowiam:PassRole
even when theiam:PassedToService
key is not present (which is whatStringEqualsIfExists
would allow for).This seems to imply that
iam:PassRole
is intended to be granted against all resources if theiam:PassedToService
key is not present OR, ifiam:PassedToService
is present, it is one of the two defined service values.^^^ @ericzbeard - Is my question re:
StringEqualsIfExists
even relevant, here?