SAML.to
Search…
Assume AWS Role Action
https://github.com/saml-to/assume-aws-role-action

For many, having a saml-to.yml configuration file per-repository won't scale. There is the ability to assign a single repository to define providers and role permissions for many downstream repositories.
A non-centralized configuration can be identified by self: true in the saml-to.yml configuration file within permissions for a role.
The configuration effectively needs to be "merged" or "copied" to the centralized repository. For example:
For example: the non-centralized saml-to.yml in "REPOSITORY-A":
version: "20220101"
variables:
awsProviderArn: "PROVIDER_ARN"
awsRoleArn: "ROLE_ARN"
providers:
aws:
entityId: https://signin.aws.amazon.com/saml
acsUrl: https://signin.aws.amazon.com/saml
attributes:
https://aws.amazon.com/SAML/Attributes/RoleSessionName: "<#= repo.name #>"
https://aws.amazon.com/SAML/Attributes/SessionDuration: "3600"
https://aws.amazon.com/SAML/Attributes/Role: "<#= repo.selectedRole #>,<$= awsProviderArn gt;"
permissions:
aws:
roles:
- name: <$= awsRoleArn gt;
self: true
Would be added to the centralized saml-to.yml , while removing self: true:
version: "20220101"
variables:
# ... other variables ...
awsProviderArn: "PROVIDER_ARN"
awsRoleArn: "ROLE_ARN"
providers:
# ... other providers ...
aws:
entityId: https://signin.aws.amazon.com/saml
acsUrl: https://signin.aws.amazon.com/saml
attributes:
https://aws.amazon.com/SAML/Attributes/RoleSessionName: "<#= repo.name #>"
https://aws.amazon.com/SAML/Attributes/SessionDuration: "3600"
https://aws.amazon.com/SAML/Attributes/Role: "<#= repo.selectedRole #>,<$= awsProviderArn gt;"
permissions:
# ... other permissions ...
aws:
roles:
- name: <$= awsRoleArn gt;
repos:
- name: REPOSITORY_A
As you can see, self: true was replaced with an explicit list of one or more repositories that can be allowed to access the aforementioned role.
NOTE: Be diligent to ensure variables, providers, and permissions are correct in the new merged configuration. Provider key names (aws in this example) need to be unique across the entire configuration file.
If a specific provider needs to be specified in the GitHub Action, it can be specified with the provider key in the Workflow.

If you haven't already, run the following command to inform SAML.to that the configuration is now in a separate repository:
npx saml-to init
Which will prompt you for the organization and repository that has the centralized configuration.

Copy link
On this page
Centrally Managed Configuration
Enabling a Centrally Managed Configuration
Questions / Problems?