> For the complete documentation index, see [llms.txt](https://docs.release.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.release.com/integrations/integrations-overview/aws-integration/how-to-use-the-permissions-boundary-to-restrict-release-access.md). # AWS Permissions Boundaries How to restrict Release permissions for fine-grained control Release has [power user](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_developer-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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) 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. {% hint style="info" %} 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. {% endhint %} 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: ```json { "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: ```json { "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](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-2ffaf2e73a80f581405872469cbb8e8615ae7fcc%2FCloudformation-Edit-Stack.png?alt=media) Select **Replace current template** and **Amazon S3 URL** and enter [`https://release-template.s3-us-west-2.amazonaws.com/integration.yml`](https://release-template.s3-us-west-2.amazonaws.com/integration.yml) in the "Amazon S3 URL" field. Click **Next**. ![Replace the existing template](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-cfb8f3f473c28f4486c2f80b558277a9348d8fd4%2FCloudformation-Edit-Stack-2.png?alt=media) {% hint style="info" %} 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. {% endhint %} {% hint style="warning" %} DO NOT use the "Edit Template in Designer" option! {% endhint %} 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](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-896fa63d38e778872e98fc0b01436a111d0db77b%2Faws-launch-stack.png?alt=media) {% hint style="info" %} 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. {% endhint %} 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](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-5216bc7f4765d4c891937ef4d6e061c617eb378a%2FCloudformation-Edit-Stack-3.png?alt=media) #### 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. {% hint style="info" %} Make sure you fill in the actual values for your account, not the example values shown below. {% endhint %} ```bash #!/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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.release.com/integrations/integrations-overview/aws-integration/how-to-use-the-permissions-boundary-to-restrict-release-access.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.