LogoLogo
  • Welcome to Release
  • Getting started
    • Quickstart
    • Create an account
    • Prepare to use Release
    • Create an application
      • Create custom application
      • Create from template
      • Servers vs runnables
    • Create an environment
  • Guides and examples
    • Domains and DNS
      • Manage domains
      • DNS and nameservers
        • Configure GoDaddy
        • Configure Cloudflare
        • Configure Namecheap
        • Other DNS hosts
      • Routing traffic
    • Example applications
      • Full stack voting app
      • Flask and RDS counter app
      • Static site with Gatsby
      • Golang with Postgres and Nginx
      • WordPress with MySQL
      • Spring and PostgreSQL
      • Terraform and Flask
      • OpenTelemetry demo
      • Load balancer with hostname
      • Static JavaScript service
      • SSH bastion access to services
      • ngrok and OAuth for private tunnels
      • Using OAuth Proxy
      • Hybrid Docker and static site
      • App Imports: Connecting two applications
      • Example library
    • Running instances
      • Cron jobs
      • Jobs
      • Using Helm charts
      • Using terminal
      • Viewing logs
      • Troubleshooting
        • ImagePullBackoff error
        • CrashLoopBackoff error
        • Exit codes
        • OOM: out of memory
    • Advanced guides
      • Containers guide
      • Application guide
      • Kubernetes guide
      • Create a cluster
      • Upgrade a cluster
      • Managing node groups
      • Patch node groups
      • Hostnames and rules
      • Serve traffic on multiple ports
      • Configure access to your K8s cluster
      • Designing for multiple environments
      • Microservices architecture
      • Monitoring your clusters
      • Performance tuning
      • Visibility and monitoring
      • Working with data
        • Container-based data
        • Seeding and migration
        • Cloud-provided data
        • Golden images
        • Third party
      • Pausing Instant Datasets
        • Application pausing schedules
        • Pause/resume environments
      • Infrastructure as code
        • Terraform
  • Reference documentation
    • Account settings
      • Account info
      • Managing users
      • Build settings
        • Build arguments
        • Build SSH keys
      • Add integrations
      • View clusters and cloud integrations
      • Add datasets
      • Environment handles
    • Workflows in Release
      • Stages of workflows
      • Serial deployments
      • Parallel deployments
      • Rolling deployments
      • Rainbow deployments
    • Networking
      • Network architecture (AWS)
      • Network architecture (GCP)
      • Ingresses
      • IP addresses
      • Cloud-provided services
      • Third-party services
    • Release environment versioning
    • Application settings
      • Application Template
        • Schema definition
      • Default environment variables
      • GitHub
      • Pull requests
      • GitOps
      • Just-in-time file mounts
      • Primary App Link
      • Create application FAQ
      • App-level build arguments
      • Parameters
      • Workspaces
    • End-to-end testing
    • Environment settings
      • Environment configuration
      • Environment variables
        • Environment variable mappings
        • Secrets vaults
        • Using Secrets with GitOps
        • Kubernetes Secrets as environment variables
        • Managing legacy Release Secrets
    • Environment expiration
    • Environment presets
    • Instant datasets on AWS
    • Instant datasets on GCP
    • Instant dataset tasks
      • Tonic Cloud
      • Tonic On-Premise
    • Cloud resources
    • Static service deployment
    • Helm
      • Getting started
      • Version-controlled Helm charts
      • Open-source charts
      • Building Docker images
      • Ingress and networking
      • Configuration
    • GitOps
    • The .release.yaml file
    • Docker Compose conversion support
    • Reference examples
      • Adding and removing services
      • Managing service resources
      • Adding database containers to the Application Template
      • Stock Off-The-Shelf Examples
    • Release API
      • Account Authentication
      • Environments API
        • Create
        • Get
        • Setup
        • Patch
      • User Authentication
      • Environment Presets API
        • Get Environment Preset List
        • Get Environment Preset
        • Put Environment Preset
  • Background concepts
    • How Release works
  • Frequently asked questions
    • Release FAQ
    • AWS FAQ
    • Docker FAQ
    • JavaScript FAQ
  • Integrations
    • Integrations overview
      • Artifactory integration
      • Cloud integrations (AWS)
        • AWS guides
        • Grant access to AWS resources
        • AWS how to increase EIP quota
        • Control your EKS fleet with systems manager
        • Managing STS access
        • AWS Permissions Boundaries
        • Private ECR Repositories
        • Using an Existing AWS VPC
        • Using an Existing EKS Cluster
      • Docker Hub integration
      • LaunchDarkly integration
      • Private registries
      • Slack integration
      • Cloud integrations (GCP)
        • GCP Permissions Boundary
      • Datadog Agent
      • Doppler Secrets Manager
      • AWS Secrets Management
    • Source control integrations
      • GitHub
        • Pull request comments
        • Pull request labels
        • GitHub deployments
        • GitHub statuses
        • Remove GitHub integration
      • Bitbucket
      • GitLab
    • Monitoring and logging add-ons
      • Datadog
      • New Relic
      • ELK (Elasticsearch, Logstash, and Kibana)
  • Release Delivery
    • Create new customer integration
    • Delivery guide
    • Release to customer account access controls
    • Delivery FAQs
  • Release Instant Datasets
    • Introduction
    • Quickstart
    • Security
      • AWS Instant Dataset security
    • FAQ
    • API
  • CLI
    • Getting started
    • Installation
    • Configuration
    • CLI usage example
    • Remote development environments
    • Command reference
      • release accounts
        • release accounts list
        • release accounts select
      • release ai
        • release ai chat
        • release ai config-delete
        • release ai config-init
        • release ai config-select
        • release ai config-upsert
      • release apps
        • release apps list
        • release apps select
      • release auth
        • release auth login
        • release auth logout
      • release builds
        • release builds create
      • release clusters
        • release clusters exec
        • release clusters kubeconfig
        • release clusters shell
      • release datasets
        • release datasets list
        • release datasets refresh
      • release deploys
        • release deploys create
        • release deploys list
      • release development
        • release development logs
        • release development start
      • release environments
        • release environments config-get
        • release environments config-set
        • release environments create
        • release environments delete
        • release environments get
        • release environments list
        • release environments vars-get
      • release gitops
        • release gitops init
        • release gitops validate
      • release instances
        • release instances exec
        • release instances logs
        • release instances terminal
  • Release.ai
    • Release.ai Introduction
    • Getting Started
    • Release.ai Templates
    • Template Configuration Basics
    • Using GPU Resources
    • Custom Workflows
    • Fine Tuning LlamaX
    • Serving Inference
Powered by GitBook
On this page
  • Using Kubernetes service accounts and OIDC roles with policies
  • Using static access key credentials
  • Using AWS metadata
  • Using assumed roles
  • Default node instance role (source role)
  • Create an elevated permissions role (target role)
  • Release-supplied elevated permissions role

Was this helpful?

  1. Integrations
  2. Integrations overview
  3. Cloud integrations (AWS)

Grant access to AWS resources

Allow self-hosted clusters to access AWS resources

PreviousAWS guidesNextAWS how to increase EIP quota

Last updated 1 year ago

Was this helpful?

You can gain access to AWS resources from your Release self-hosted cluster by using:

  • Kubernetes Service Accounts and OIDC role-policies

  • Static access key credentials

  • AWS metadata

  • Assumed roles

Using Kubernetes service accounts and OIDC roles with policies

OIDC providers are created automatically on all clusters and we recommend you use this method for pod access to cloud-native resources.

A Release service or job (also known as a Kubernetes pod) can be associated with a service account that will be given a role that has a particular policy attached to it. This allows the pod to access cloud-native services using only the permissions granted to it via the role policy. The identity of the pod is established by a service account that Release will create and is trusted via the OIDC provider attached to the cluster.

Here are the steps to create and use a service account:

  • Create a service_accounts: entry in your Application Template following the documentation . You will need to specify a cloud_role, which is the ARN to a role that is outlined in the next steps.

  • Create a policy that contains the resources and actions you wish to allow the service or job to have and attach it to a role. You can follow the AWS documentation or use a standard Terraform script. This happens outside the scope of Release for now, but you can use a separate application to create the role and policy before adding the cloud_role ARN to your service or job.

  • The role trust policy must link to the OIDC providers for the clusters that you are deploying to. You can read the or view a demonstration we have created for examples.

Using static access key credentials

The simplest way to access resources is to generate user credentials and add them to in your application.

We discourage customers from using static keys due to security risks.

When using static access key credentials, ensure that you use secret: true to hide the values.

User credentials will work for the AWS account they were generated in, for as long as they are valid. The user must have a restrictive policy that allows least privileges to the resources required. Typically, this means not using an account created for a human user, which may have elevated, broad privileges to lots of resources.

Adding the credentials to environment variables is straightforward and can be encrypted at rest. Using static credentials in an environment does not require any code changes to be supported. However, this method of accessing resources is insecure, as the credentials can be exposed in the environment.

Here is an example of how you could add static keys to an application:

---
services:
  myapp:
  - key: AWS_ACCESS_KEY_ID
    value: AKIASOMETHING
    secret: false # Or true!
  - key: AWS_SECRET_ACCESS_KEY
    value: abcdefghijklmnopqrstuvwxyz
    secret: true

Using AWS metadata

The AWS metadata service runs on each Kubernetes node and allows a pod or application to assume temporary credentials that are refreshed automatically when accessed in the metadata. These temporary credentials can be used to access resources that have a trust relationship with the account the nodes run in. No credentials are stored in the environment, and in general, no changes are required for code or SDK calls to access credentials.

This method works well enough inside the same account where trust can be relaxed to a source account where the cluster lives. It is not well suited for regulated, secret, cross-account, or third-party access.

The downside of a trust relationship is especially apparent in cross-account or third-party access because the trust relationship usually traces back to unknown applications in another account. However, the policy that is applied to the trust relationship can be tailored to the exact permissions required by the application, so this is typically a better security posture than using static keys. Given the low effort to implement metadata identity, this is a good middle ground to use for access.

Here is an example of a document used in creating a policy:

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "S3BucketAccess",
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::${AWS-account-ID}:root"
    },
    "Action": "s3:*",
    "Resource": [
      "arn:aws:s3:::mybucket",
      "arn:aws:s3:::mybucket/*"
    ]
  }
}

Using assumed roles

An assumed role allows your application to request credentials for a predefined role that has a policy and trust relationship to the application. If access is granted, a session token is issued that is valid for a short time (usually one hour, but it can be configured to be valid for 15 minutes to more than a day).

In most cases, accessing resources using an assumed role requires you to write code to request the credentials, store them in your application or in memory, and then use them. You will also need to create a role, trust policy, and policy document in your account or another account.

No credentials are added to the environment or checked into your version control, and credentials eventually expire so they cannot be compromised later.

The role policy is not used for humans and can be tailored to the exact minimum access needed by the application, which is especially useful in cross-account or third-party access. A trust relationship can be granted to a very specific level of detail, making remote and third-party requests easy. However, the code changes and coordination with cross-account or third-party accounts involved in this method require some effort.

Using AWS assumed roles is the preferred and most secure way to access resources.

Related documentation:

Default node instance role (source role)

The node instance role is the default role assigned to a pod at execution in AWS using EKS. This role can be examined in a running container by using the aws sts get-caller-identity call on a container with the AWS CLI installed. You can see an example here:

# aws sts get-caller-identity
{
    "UserId": "AROxxxx:i-00xxxx",
    "Account": "123456789",
    "Arn": "arn:aws:sts::123456789:assumed-role/eksctl-test-release-prod-us-e-NodeInstanceRole-xxxx/i-00xxx"
}

This is the default role for all pods running in the cluster, so the role is restricted to only a very common set of tasks, like accessing read and write S3 buckets. This role is not granted more permissions to avoid giving any pod deployed to the account more privileges than it needs.

The default node instance role can assume the role of another target role in the account or organization below the /role/release/ path namespace. For example, you can confirm the permissions created for the node instance role in the AWS console:

        {
            "Sid": "SessionTokenServiceAssumeRole",
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole"
            ],
            "Resource": "arn:aws:iam::123456789:role/release/*"
        },

Create an elevated permissions role (target role)

A pod may need higher permissions than those included in the default node instance role to perform certain functions, for example, if the pod needs to access a Kinesis stream or a Dynamo DB table.

To create an elevated permissions role for the pod, first create a role under the /role/release/ path with a trust relationship from the source role:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ElevatedRoleTrustPolicy",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Principal": {
              "AWS": "arn:aws:iam::111111111111"
            },
            "Condition": {
              "ArnLike": {
                "iam:AssociatedResourceARN": "arn:aws:iam::111111111111:assumed-role/role-name/*"
              }
            }
        }
    ]
}

Note that wildcards are not allowed in assumed role session principals.

This policy will need access to Kinesis and perhaps DynamoDB, so when you create the target role, you can use an example policy like the following:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:PutItem*",
                "dynamodb:GetItem*"
            ],
            "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Music"
        },
        {
            "Effect": "Allow",
            "Action": [
                "kinesis:PutItem"
            ],
            "Resource": "arn:aws:kinesis:us-west-2:123456789012:stream/Orders"
        }
        
    ]
}

Release-supplied elevated permissions role

Release provides a default elevated permissions role that can be used to assume elevated permissions above what the normal node instance role allows. This can be used, for example, to run administrative services. Contact us to find out the details of what permissions are supplied in the elevated role permissions and how to access the ARN for assuming that role.

To improve our security posture, IMDSv1 is disabled by default on all new EC2 nodegroups as of October 2022. You should check the from version 1 to version 2 if you currently rely on IMDSv1.

Find the AWS-account-ID account number required for this policy on the page or get in touch with Release support to help you find the account ID.

You can find more in the AWS documentation.

Using assumed roles requires more advanced code integration and using the AWS SDK v3 for your programming language of choice. Read the for details.

requirements and guide for transitioning
View Clusters
examples of policies for delegating access
documentation
Using IAM roles
How to use trust policies with IAM roles
Specifying principals in trust relationships
IAM and AWS STS condition context keys
How do I assume an IAM role using the AWS CLI?
Switching to an IAM role (AWS CLI)
Using AWS AssumeRole with the AWS Terraform Provider
Running Pulumi with an assumed role
IAM roles for service accounts (ISRA)
AWS documentation
Terraform repository
environment variables
Terraform runner
here