AWS
The AWS provider configuration gives you the option to authenticate through OIDC, IAM Roles, or access keys as well as options for each authentication method:
The configuration can be set up in the UI, below you will find examples of how to do this with the Scalr provider.
OIDC
The OIDC authentication method will create temporary access keys for each run, which removes the need to store static credentials in Scalr. Unlike the IAM role method, it doesn't require trusting the Scalr-managed AWS account or an internal IAM user. The only thing you have to trust is the Scalr identity provider.
Also, it gives you the ability to configure in AWS trust policy which workspaces or environments are allowed to consume temporary keys based on their names.
AWS steps
Create the identity provider
As a first step, register Scalr as the identity provider in AWS. While adding the new provider you need to:
- Select the provider type: OIDC.
- Enter the provider URL: https://scalr.io (this must be an exact match).
- Click on the "Get thumbprint" button to verify the thumbprint.
- Set the Audience name. While creating it you can only set a single audience, but after the provider is created, you can add additional audiences to the list. Later, this audience will be used while creating a provider configuration in Scalr.
After the role is created, an additional assertion can be added to limit which environments can use the role. Follow these steps to add the assertion:
- Open the
Trust Relationships
tab in the IAM role dashboard and click theEdit trust policy
button - Then in the condition section, add the following snippet:
"StringLike": {
"scalr.io:sub": "account:<account-name>:environment:<environment-names-prefix>:workspace:<workspace-names-prefix>-prefix>"
}
Replace the <account-name>
, <environment-names-prefix>
, and <workspace-names-prefix>
with the actual names of the account, environment, and workspaces that will use the temporary credentials. Wildcards *
are supported.
Here's a full example of the trust policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::1111111111:oidc-provider/scalr.io"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"scalr.io:aud": "my-awesome-audience"
},
"StringLike": {
"scalr.io:sub": [
"account:mycorp:environment:development-*:workspace:*",
"account:mycorp:environment:qa-*:workspace:*",
]
}
}
}
]
}
Follow the documentation on how to complete the steps above using different interfaces (console, aws CLI, or API).
Create an IAM role
The next step is to create a new role and trust the created identity provider in the role's trust policies. To create the IAM role that allows creating temporary keys using OIDC, follow these steps:
- Select Trusted entity type: Web identity.
- Select the Identity provider: scalr.io
- Select the Audience from the list you configured in the previous step.
- Then assign the required permissions set and complete the role creation.
Follow the documentation on how to configure the IAM role with the OIDC trusted entity type.
Scalr steps
After the IAM role is created in AWS, navigate to the Account scope > Provider configurations. You can either create a new provider configuration or update an existing one. Please follow these steps to register an OIDC-trusted role in Scalr:
- Select the Authentication type: OIDC
- Enter the IAM role ARN of the created role.
- Enter the Audience you selected during the role creation.
After the provider configuration is created, share it with the environments and link it to workspaces.
Provider example
resource "scalr_provider_configuration" "aws-oidc" {
name = "aws_oidc_example"
account_id = "acc-sscctbisjk12345"
export_shell_variables = false
environments = ["*"]
aws {
credentials_type = "oidc"
role_arn = "arn:aws:iam::11111111111:role/test-oidc"
audience = "my-awesome-audience"
}
}
Service Trusted Entities
Service-trusted entities give you the ability to add roles with AWS service trusts. In this case, a role is added to a Scalr agent and no credentials are needed in Scalr at all. This allows using different roles for different workspaces on a single server used for the agent. This will not require wide permissions assigned to the VM instance profile.
For example:
resource "scalr_provider_configuration" "aws" {
name = "aws_service_example"
account_id = "acc-sscctbisjk12345"
export_shell_variables = false
environments = ["*"]
aws {
account_type = "regular"
credentials_type = "role_delegation"
trusted_entity_type = "aws_service"
role_arn = "arn:aws:iam::670025221234:role/service_agent"
}
}
Scalr Account Trusted Entity
Scalr account trusted entity credentials use IAM roles that have a trusted relation with
a Scalr AWS account, specifically 919814621061
. No keys are needed, just the trust.
resource "scalr_provider_configuration" "aws" {
name = "aws_account_example"
account_id = "acc-sscctbisjk13345"
export_shell_variables = false
environments = ["*"]
aws {
account_type = "regular"
credentials_type = "role_delegation"
trusted_entity_type = "aws_account"
role_arn = "arn:aws:iam::6700252123456:role/user"
external_id = "dOtbGEdaiXD12345"
}
}
The role must be created in AWS and the ARN of the role entered into
Scalr as seen above.
Please refer to IAM Role Delegation for details of setting up the role with a trusted relationship to the Principal account shown on the credentials screen. The external ID shown must be used in the role configuration.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::919814621061:user/scalr-saas"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "<external-id>"
}
}
}
]
}
Account Trusted Entity
Account trusted entities are different than the Scalr account trusted entities in that you are not adding the Scalr AWS account as the trusted entity. In this case, you are creating an AWS user, creating a new role, sharing the rule trust with the user and then adding the user with the credentials in Scalr. See more on IAM Role Delegation.
resource "scalr_provider_configuration" "aws" {
name = "aws_account_example"
account_id = "acc-sscctbisjk13345"
export_shell_variables = false
environments = ["*"]
aws {
account_type = "regular"
credentials_type = "role_delegation"
trusted_entity_type = "aws_account"
access_key = "<access-key>"
secret_key = "<secret-key>"
role_arn = "arn:aws:iam::6700252123456:role/user"
external_id = "dOtbGEdaiXD12345"
}
}
Review the full provider configuration documents on how to link the provider configuration to an environment and workspace here
Updated 20 days ago