AWSPowerUserAccess permission set is insufficient for dev team members

[ckamps]

We initially directed the customer to use the AWSPowerUserAccess permission set when associating their development team groups in AWS SSO with the development team AWS accounts.

However, since the underlying AWS-managed permission PowerUser doesn't allow for IAM access, it's not sufficient to meet the requirements.

Background

See where the doc currently suggests using this AWS-managed permission set:

https://github.com/ckamps/aws-foundation-journey/blob/master/1-dev-environments/2-8-onboard-dev-teams.md

For example, it does not enable dev team members to create IAM roles associated with typical application level deployments.

Reproduce

As a dev team member, access your team AWS account. In the AWS Management Console attempt to view IAM resources and create an IAM role.

Requirements

Requirements have been moved to a reference doc:

https://github.com/ckamps/aws-foundation-journey/blob/master/1-dev-environments/3-3-controlling-dev-team-access.md

[ckamps]

A walkthrough of the early draft sample policy has been created. As we rapidly iterate on the sample policy, we'll need to keep the walkthrough doc in sync.

https://github.com/ckamps/aws-foundation-journey/blob/master/1-dev-environments/3-3-iam-policy-infra-dev-team.md#policy-walkthrough

[ckamps]

OK, so an initial rough customer permission set has been added and incorporated in the guide to align with most of the requirements listed here in this issue. The remaining task is to address the privilege escalation gap via IAM boundary permissions.

[ckamps]

We moved to a NotAction approach in both the SAML and PB policies to make it more of a least privileged approach where access to specific IAM permissions needs to be explicitly allowed.

[ckamps]

Out of the many resources/examples for permissions boundaries, this one has stood out in my mind:

https://identity-round-robin.awssecworkshops.com/permission-boundaries/build/

Demo using with Lambda:

https://www.youtube.com/watch?v=eVNvjQ0wr84&feature=youtu.be

[ckamps]

The initial draft form of the SAML policy and Permissions Boundary (PB) policy have been integrated and are undergoing initial testing and review.

[ckamps]

Our next step is to move the VPC deny permissions that are currently both the SAML and PB policies up to SCPs that get applied to the Development OU so that:

• we avoid violating the DRY principle.
• simplify the SAML and PB policies.

[ckamps]

A few considerations based on initial review and testing:

• To control access to IAM actions and resources, should we move from the current black list approach to a white list of explicitly allowed IAM actions? What are the pros and cons?

  • Potential Pros
  • More of a sense of least privilege based authorization compared to the black list approach.
  • More explicit whitelist of allowance of IAM actions.
  • As new IAM actions and resource types emerge, they won't be automatically allowed for dev team members until someone explicitly adds them to the white list.
  • Potential cons:
  • Might make the SAML and PB policies longer and bump up against the 6K characters per managed policy limit.

• Which, if any, of the permissions could be moved to Service Control Policies (SCPs) in an effort to simplify the dev team SAML and PB policies?

  • For example, would it make sense to move the VPC write deny permissions to an SCP and associate that SCP with the development OU? One implication is that even Cloud Admins would not be able to perform VPC write actions in development OU AWS accounts. Perhaps that's OK given that we're using a shared VPC in the Network AWS account and foundation team members might warrant use of a different development OU for their day-to-day foundation development that will include iterating on VPC configurations.

[ckamps]

Sample SCPs have been merged along with updated docs and IAM policy samples.