Easily Delegate Responsibilities Using AWS Permissions Boundaries and Kion

By Joseph Spurrier, CTO at Kion

Kion

In many organizations, it’s often a long time between when you request more identity and access management (IAM) permissions and when you get those permissions.

Cloud teams can easily get overwhelmed in highly regulated environments because every permission request is reviewed and approved. The cloud is designed to allow engineers to rapidly build and innovate, but those benefits can diminish if it takes days to get access to what you need.

On Amazon Web Services (AWS), it’s easy to generate access keys for your users and then throw them into an application to have your Amazon Elastic Compute Cloud (Amazon EC2) instance interact with Amazon Simple Storage Service (Amazon S3).

However, the recommended approach is to create an instance profile (basically an IAM role) so access keys aren’t around for extended periods of time.

Before permissions boundaries, cloud teams typically created instance profiles for users on request. This was done because if users had the ability to create instance profiles themselves, they could create one with high-level permissions that would allow them to elevate their own permissions.

Now, with AWS permissions boundaries, cloud teams can allow users to create their own instance roles, but require them to attach specific IAM policies to prevent elevation.

Permissions boundaries allow admins to delegate permissions to users so they can create new AWS service roles (for use with services like Amazon EC2 and AWS Lambda) without elevating their own permissions.

This removes the need for admins to field requests for these role creations and promotes self-service for users. The ultimate goal is to remove blockers for enhanced productivity.

In this post, I will show you how you can pair permissions boundaries with Kion (formerly cloudtamer.io) for increased automation and delegation. An AWS Partner with the AWS Government Competency, Kion allows your team to easily request and manage cloud resources that are aligned with your budget, security, and compliance policies.

Introduction to Kion

A comprehensive cloud governance software, Kion allows you to manage your cloud presence at scale. With Kion, organizations get visibility and control across the complete cloud lifecycle.

Benefits of Kion include:

• Account management features allow users to create and control access to their own AWS accounts through a self-service workflow, and automatically align accounts to the broader organization structure.
• Budget enforcement features allow budgets to be set per AWS account based on allocations and funding sources available within the organization. Enforcement actions are managed to ensure budgets can’t be exceeded.
• Continuous compliance features allow organizations to hierarchically enforce policies that restrict access to cloud services and configurations based on compliance frameworks. This ensures AWS accounts stay within established frameworks based on their mission.

Applying Permissions Boundaries Using Kion

Permissions boundaries require two components: an IAM policy that users can apply when creating roles, and the IAM policy that allows the users to create the roles with the permissions boundary.

With Kion, you can create a “cloud rule” and then apply it to all of your desired AWS accounts. A cloud rule is a Kion construct that groups native cloud objects together (like IAM policies and AWS CloudFormation templates) and then deploys them consistently to your AWS accounts.

Here are two great use cases for cloud rules:

• Sharing service catalog portfolios with launch constraints: Requires both an AWS Service Catalog portfolio and an IAM role that will be used when launching the portfolio product.
• Applying permissions boundaries: Requires both the permissions to create IAM roles as well as an IAM policy that can be attached to the IAM role when it’s created. The permissions to create the IAM roles are applied to “cloud access roles,” which is how Kion federates users into the AWS console. Let’s look at this use case in more detail.

Figure 1 – Using cloud rules to apply an AWS permissions boundary.

Add a New CloudFormation Template

In Kion, add a new CloudFormation template by pasting in the JSON template below.

This template creates the IAM policy (permissions boundary) that users must attach when creating an IAM role. A permissions boundary acts as a whitelist: even if the “AdministratorAccess” IAM policy is attached as a policy, when you attach the “boundary-s3” IAM policy as a permissions boundary, the only permissions the user will have are: “s3:*” (the ability to read and write to Amazon S3).

{ 
   "AWSTemplateFormatVersion":"2010-09-09",
   "Description":"Creates an IAM policy that can be used as a permissions boundary.",
   "Resources":{ 
      "PermissionBoundaryPolicy":{ 
         "Type":"AWS::IAM::ManagedPolicy",
         "Properties":{ 
            "ManagedPolicyName":"boundary-s3",
            "Description":"Policy only allows access to S3.",
            "Path":"/",
            "PolicyDocument":{ 
               "Version":"2012-10-17",
               "Statement":[ 
                  { 
                     "Effect":"Allow",
                     "Action":[ 
                        "s3:*"
                     ],
                     "Resource":"*"
                  }
               ]
            }
         }
      }
   }
}

Add a New IAM Policy

Next, in Kion, add a new IAM policy by pasting in the JSON policy at the end of this section.

This IAM policy allows users to create an IAM role, but requires them to attach the IAM policy (created above by the CloudFormation template) to the IAM role to limit the role’s permissions.

This is a sample IAM policy that allows a user to:

• Read all information under the IAM service like roles, users, and policies.
• Create an IAM role whose name must be prefixed with service- and must have the boundary-s3 IAM policy attached during creation.
• Attach or detach an IAM policy to any role with a name that is prefixed with service- and has the boundary-s3 IAM policy already applied.
• Create or delete an instance profile (for use with Amazon EC2 instances) whose name must be prefixed with service-.
• Add or remove a role to an instance profile where the instance profile’s name must be prefixed with service-.
• Pass an IAM role whose name must be prefixed with service- to an EC2 instance or Lambda function.
• Delete an IAM role whose name must be prefixed with service-.

I recommend using the service-* prefix to make it easy to see which roles are user-created, and to give the users the ability to delete their roles when they are done. It’s currently not possible to only allow users to delete roles with a certain permission boundary, so forcing users to use a prefix is a good method for controlling these roles.

Since IAM does not support a variable for the AWS account number, there is a built-in Kion variable, {{CT::AWSAccountId}}, that will be replaced prior to Kion creating the IAM policy in AWS.

{ 
   "Version":"2012-10-17",
   "Statement":[ 
      { 
         "Sid":"BasicPermissions",
         "Effect":"Allow",
         "Action":[ 
            "iam:GenerateServiceLastAccessedDetails",
            "iam:Get*",
            "iam:List*"
         ],
         "Resource":"*"
      },
      { 
         "Sid":"PermissionsBoundary",
         "Effect":"Allow",
         "Action":[ 
            "iam:CreateRole",
            "iam:AttachRolePolicy",
            "iam:DetachRolePolicy"
         ],
         "Resource":"arn:aws:iam::{{CT::AWSAccountId}}:role/service-*",
         "Condition":{ 
            "StringEquals":{ 
               "iam:PermissionsBoundary":"arn:aws:iam::{{CT::AWSAccountId}}:policy/boundary-s3"
            }
         }
      },
      { 
         "Sid":"InstanceProfileCreation",
         "Effect":"Allow",
         "Action":[ 
            "iam:CreateInstanceProfile",
            "iam:AddRoleToInstanceProfile",
            "iam:RemoveRoleFromInstanceProfile",
            "iam:DeleteInstanceProfile"
         ],
         "Resource":"arn:aws:iam::{{CT::AWSAccountId}}:instance-profile/service-*"
      },
      { 
         "Sid":"Cleanup",
         "Effect":"Allow",
         "Action":[ 
            "iam:PassRole",
            "iam:DeleteRole"
         ],
         "Resource":"arn:aws:iam::{{CT::AWSAccountId}}:role/service-*"
      }
   ]
}

Attach the Template and Policy to a Cloud Rule

You should attach both the AWS CloudFormation template and IAM policy to a cloud rule in Kion. Then, attach the cloud rule to the desired organization units or projects in Kion.

Users will now be granted the permissions to create the IAM roles as long as they attach the IAM policy during creation.

Figure 2 – Attaching a cloud rule to an organization unit.

Customer Success: Applied Insight

Applied Insight uses permissions boundaries to manage a large AWS environment with 1,000+ users at a federal government agency. These users have a broad set of engineering needs, including web application development, machine learning, and web hosting.

Before permissions boundaries, all requests for new service roles came through a ticketing system. The support team would have the security engineers build the IAM policy and then validate it with the requesting user. Once validated, the security engineers would use automation to create the service role via a CloudFormation template.

If there were any further changes, the user would submit another ticket to the support team and the request and the process would repeat.

The size of the agency’s user base and sheer number of use cases required Applied Insight to develop a solution to allow users to handle their own application security. Working with Kion, the Applied Insight team identified permissions boundaries as an AWS feature that could be used to implement least privilege.

With this feature, users can create their own IAM roles while staying within the boundaries defined for their AWS privileges. Combining permissions boundaries and Kion functionality, Applied Insight has developed a working, widely-used production capability that allows users to create their own IAM roles in a safe and user friendly manner.

This has greatly increased the velocity by which users can build infrastructure using AWS best practices, and has cut down on the time spent coordinating between teams to perform tasks.

Conclusion

With AWS permissions boundaries, cloud teams can allow users to create their own instance roles without the ability to elevate access. This removes blockers and enhances productivity by promoting self-service for users.

In this post, I shared how you can pair AWS permissions boundaries with Kion to further increase automation and delegation. One customer with 1,000+ accounts has seen a substantial increase in development velocity and corresponding decrease in time spent coordinating between teams.

If you’re a current Kion customer, reach out to our team if you need help applying permissions boundaries. Want to get started with Kion? Contact us.

The content and opinions in this blog are those of the third party author and AWS is not responsible for the content or accuracy of this post.

.

.

Kion – APN Partner Spotlight

Kion is an AWS Competency Partner that allows teams to easily request and manage cloud resources that are aligned with budget, security, and compliance policies.

Contact Kion | Partner Overview | AWS Marketplace

*Already worked with Kion? Rate the Partner

*To review an AWS Partner, you must be a customer that has worked with them directly on a project.