rssite.blogg.se - That escalated quickly template

THAT ESCALATED QUICKLY TEMPLATE CODE

Another condition is that roles can only be created and passed to roles and policies that are prefixed with certain "prefixes" (as explained above). An example of a condition is that roles can only be created if the new role has an AWS Permissions Boundaries attached to it, to restrict what actions that new role can perform. Therefore, the current Cloud Cover base roles can only create machine roles under certain conditions. However, the principle of least privilege should not only apply to "human" IAM roles, but should also be applied to service roles created by these human roles. The roles and policies managed by Cloud Cover are to a great extent only applicable to roles humans federate into. only secrets for certain services can be accessed by engineers in a given AWS account).

An example where this may be useful is to have more granular control over what secrets in AWS Secrets Manager can be accessed by different IAM roles within an AWS account, based on the services deployed there (i.e. To further enforce the principle of least privilege, some role policies are constrained to prefixes of services that are deployed in an AWS account. The creation and attachment of "custom" policies requires approval, via a pull request in the Cloud Cover GitHub repo, before additional permissions can be granted. These policies are defined in the Cloud Cover Github repo in the AWS account folder of the team owning that particular AWS account. "Custom" policies can be created by individual teams when no endorsed policies fit their use case. It is our intent that these policies can be attached to any role definition without requiring approval through pull requests. "Endorsed" policies are policies that are endorsed by the Security Team and are deemed secure enough to be used freely. To allow engineers to request additional IAM permissions and attach these to their base roles, Cloud Cover makes a distinction between "endorsed" and "custom" policies in its GitHub repo. Additional permissions can be requested by creating a pull request in Cloud Cover"s Github repo. As this base set of roles will not fit all use cases, individual teams can attach missing permissions to roles in their AWS accounts.

The goal was to capture 90% of the use cases for engineers who work with AWS with these base roles. We developed a set of AWS IAM base roles that users can federate into using Okta, which ensure least-privilege permissions.

IAM roles deployed by Cloud Cover are mapped to Okta groups, and engineers are assigned to these groups based on their team and responsibilities.

THAT ESCALATED QUICKLY TEMPLATE CODE

IAM roles and policies are defined by Cloud Cover as infrastructure as code (IAC), and are deployed into our AWS accounts using a CI/CD pipeline. We use AWS roles that can be assumed, rather than users, to prevent the use of long-lived static credentials.

Introduce the ability to provide automatic, day one access (birthright) to the AWS accounts, and make it easy for IT support staff to process access requests quicklyĬloud Cover is a tool that provides employees access to our AWS accounts through the use of temporary IAM role credentials.

This includes keeping an audit trail to see who requested certain permissions and when these were deployed

Have a central place where we can keep track of, and control permissions.

Leverage Okta (our single sign-on solution) as the source of truth for IAM role federation (i.e.

Part of this requirement for us is to allow engineers to request additional IAM permissions in a self-service, but safe and governed, way

Ensure engineers get their work done securely, but without unnecessarily compromising their efficiency.

Integrate well-known security best practices, such as the principle of least privilege, into our IAM model.

When we designed Cloud Cover, a few things were important to us: Cloud Cover was born to reduce the chance of IAM misconfigurations in our AWS environments. One of the most common tactics attackers use to escalate privileges in cloud environments is to abuse overly permissive identity and access policies. MotivationĪWS IAM is at the heart of AWS Security, and as our organisation scales, we need to ensure a robust and consistent IAM model across our AWS accounts. To tackle this (not-so-easy) problem, we have developed an automated and scalable solution to consistently and flexibly manage IAM in our AWS accounts. It’s the task of the Security Team at Afterpay to manage this risk, while at the same time making sure that engineers are not slowed down in their everyday tasks. We know that a single Identity and Access Management (IAM) misconfiguration in our AWS environment can lead to compromise of our entire cloud environment. Just like the cliché says, security is only as strong as the weakest link.