Search
K
Links

AWS Permissions Boundaries

How to restrict Release permissions for fine-grained control
Release has power user access to your AWS account to create and deploy infrastructure and code there. This gives Release sufficient permissions to spin up clusters, load balancers, RDS databases, and snapshots, configure DNS, and more. However, you may want to restrict the level of access Release is granted to your account.
AWS supports permissions boundaries to restrict an IAM entity's access to services and resources in your account. A permissions boundary binds an access policy to a role or user that limits the permissions of the entity. For example, while Release's power user access allows it to request full access to all S3 buckets, you can apply a boundary policy that restricts Release's access to buckets with specific names or prefixes, or allows Release read-only permissions and not delete permissions.
You can apply a permissions boundary to Release's default console role. A permissions boundary will only restrict access to the subset of activities you define and will not impact the functionality of Release. During the course of normal operations, for example, it might not be necessary to provision any infrastructure or create DNS zones in the customer account—this level of access is only required during upgrades or when building a new cluster. In such a case, the normal day-to-day operations of the default Release role can be restricted by a permissions boundary, which can be temporarily expanded or removed when more access is required.

Prerequisites

These are the prerequisites for configuring and applying a permissions boundary:
  • A Release-provisioned cluster in your account or subaccount that you have access to.
  • The Release-created console role ARN in your account, which you'll find in the /release/ namespace in IAM. Here is an example: arn:aws:iam::99999999999:role/release/releasehub-integration-ConsoleRole-1ABCDE2345.
  • The Release-created CloudFormation stack ARN in your account, which you can find in the stacks listed in the region the CloudFormation stack was built (the default region is us-west-2, but you may have chosen a different region). Here is an example: arn:aws:cloudformation:us-west-2:9999999999:stack/releaseStack/1111-111-2222-2222222.
  • A suitable policy ARN that restricts Release's access to the services and resources you specify. You can find a starter template with the minimum permissions required for most use cases in your account under the /release/ namespace. The example we provide is similar to arn:aws:iam::99999999999:policy/release/releasehub-integration-ReleaseMinimalPolicy-1ABCDE2345.
  • Login credentials to either the AWS console or CLI.

Creating a reduced permissions boundary policy

Release provides a "Minimal Access Policy" that includes the standard access required for Release in the regular operations of deploying and updating code. This minimum-access policy may suit your needs as-is, and we recommend you start with it to test the permissions boundary.
You can create a policy from scratch, but it might be more convenient to use the provided policy as a template and remove permissions according to your needs.
You can also contact the Release support team to help you develop an access policy.
Note that by setting "Effect" to "Deny" or by removing the allowed reference, you will be restricting access with an implicit "Deny" for any privileges not listed in the policy. Use "Deny" policies to exclude resources and permissions precisely as detailed below.
For example, suppose the existing minimal-access policy is mostly suitable for your needs, but the permissions applied in the following stanza are too broad:
{
"Action": [
"rds:Create*",
"rds:DeleteDBCluster",
"rds:DeleteDBInstance",
"rds:ModifyDBCluster",
"rds:ModifyDBInstance",
"rds:ModifyDBClusterParameterGroup",
"rds:ModifyDBParameterGroup",
"rds:ModifyDBSubnetGroup",
"rds:StartDBCluster",
"rds:StartDBInstance",
"rds:StopDBCluster",
"rds:StopDBInstance"
],
"Resource": [
"arn:aws:rds:*:999999999:cluster:*",
"arn:aws:rds:*:999999999:cluster-pg:*",
"arn:aws:rds:*:999999999:cluster-snapshot:*",
"arn:aws:rds:*:999999999:db:*",
"arn:aws:rds:*:999999999:pg:release-*",
"arn:aws:rds:*:999999999:og:release-*",
"arn:aws:rds:*:999999999:secgrp:release-*",
"arn:aws:rds:*:999999999:snapshot:*",
"arn:aws:rds:*:999999999:subgrp:*"
],
"Effect": "Allow"
}
This is the set of permissions that Release requests, but you can go ahead and restrict them with the following:
{
"Action": [
"rds:DeleteDBCluster",
"rds:DeleteDBInstance",
"rds:ModifyDBCluster",
"rds:ModifyDBInstance",
"rds:ModifyDBClusterParameterGroup",
"rds:ModifyDBParameterGroup",
"rds:ModifyDBSubnetGroup"
],
"Resource": [
"arn:aws:rds:*:999999999:db:production-*"
],
"Effect": "Deny"
}
This code blocks Release from accessing databases with names prefixed with production-. Note that Release would still be able to use StartDBInstance with production databases, because the original policy permits that Action.
You can repeat this process for any services, APIs, actions, and resources. We recommend you share your policy with Release for review so that potential problems can be identified before they interrupt your deployments.

Using the AWS CloudFormation Console

Navigate to the AWS Cloudformation Console, find the Release-created stack in the region you created it, and click the Update button.
Update the Cloudformation stack
Select Replace current template and Amazon S3 URL and enter https://release-template.s3-us-west-2.amazonaws.com/integration.yml in the "Amazon S3 URL" field. Click Next.
Replace the existing template
Whether you choose Replace current template or Use current template is up to you, but we recommend you update to the latest version of our template by downloading the newest S3 location.
DO NOT use the "Edit Template in Designer" option!
On the next page, add the ARN to the managed policy you will use as the permissions boundary. The defaults in the other fields don't need to be changed. Click Next.
Fill in the permissions boundary policy ARN
The permissions boundary ARN is just a policy ARN, but it must be fully qualified as a complete ARN, not just the policy name or path.
Review all the tags, rollback policies, and so on. The settings here should not need any adjustment, but you can change them if you would like to. Click Next.
On the next page, review your edits, check the acknowledgement box, and click Update stack.
Acknowledge the Notes, Review the Settings, and Update the Stack

Using the CLI

Your account administrator or security team can set up the permissions boundary to update automatically. We don't provide the exact set-up steps here, but if the following example is not sufficient, get in touch with the Release support team.
Make sure you fill in the actual values for your account, not the example values shown below.
#!/bin/sh
AWS_PROFILE=production
AWS_REGION=us-west-2
CF_STACK_ARN="arn:aws:cloudformation:${AWS_REGION}:9999999999:stack/releaseStack/1111-111-2222-2222222"
BOUNDARY_ARN="arn:aws:iam::99999999999:policy/release/releasehub-integration-ReleaseMinimalPolicy-1ABCDE2345"
aws cloudformation update-stack --stack-name $CF_STACK_ARN \
--template-url 'https://release-template.s3-us-west-2.amazonaws.com/integration.yml' \
--no-use-previous-template \
--parameters ParameterKey=AccountId,UsePreviousValue=true \
ParameterKey=ExternalId,UsePreviousValue=true \
ParameterKey=IntegrationUrl,UsePreviousValue=true \
ParameterKey=PermissionsBoundaryArn,ParameterValue=${BOUNDARY_ARN} \
--capabilities CAPABILITY_IAM

Restoring Normal Permissions

To restore normal operations, use the provided "Minimal Access Policy" created by the CloudFormation template as the permissions boundary. If you need to allow elevated permissions, such as during cluster upgrades or when provisioning new clusters, you can remove the permissions boundary. Consult with the Release support team if you would like assistance with creating a policy that meets your specific needs.