-
Notifications
You must be signed in to change notification settings - Fork 486
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: added OIDC #262
feat: added OIDC #262
Changes from 1 commit
5e4f686
74ed23c
207a070
88e36ed
ef6880f
8d77d75
8c9da02
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -9,8 +9,8 @@ Configure AWS credential and region environment variables for use in other GitHu | |
- [Usage](#usage) | ||
- [Credentials](#credentials) | ||
- [Assuming a Role](#assuming-a-role) | ||
+ [Permissions for assuming a role](#permissions-for-assuming-a-role) | ||
+ [Session tagging](#session-tagging) | ||
+ [Sample IAM Role Permissions](#sample-iam-role-cloudformation-template) | ||
- [Self-Hosted Runners](#self-hosted-runners) | ||
- [License Summary](#license-summary) | ||
- [Security Disclosures](#security-disclosures) | ||
|
@@ -25,9 +25,7 @@ Add the following step to your workflow: | |
- name: Configure AWS Credentials | ||
uses: aws-actions/configure-aws-credentials@v1 | ||
with: | ||
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} | ||
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} | ||
# aws-session-token: ${{ secrets.AWS_SESSION_TOKEN }} # if you have/need it | ||
role-to-assume: arn:aws:iam::123456789100:role/my-github-actions-role | ||
aws-region: us-east-2 | ||
``` | ||
|
||
|
@@ -47,8 +45,7 @@ jobs: | |
- name: Configure AWS credentials from Test account | ||
uses: aws-actions/configure-aws-credentials@v1 | ||
with: | ||
aws-access-key-id: ${{ secrets.TEST_AWS_ACCESS_KEY_ID }} | ||
aws-secret-access-key: ${{ secrets.TEST_AWS_SECRET_ACCESS_KEY }} | ||
role-to-assume: arn:aws:iam::111111111111:role/my-github-actions-role-test | ||
aws-region: us-east-1 | ||
|
||
- name: Copy files to the test website with the AWS CLI | ||
|
@@ -58,8 +55,7 @@ jobs: | |
- name: Configure AWS credentials from Production account | ||
uses: aws-actions/configure-aws-credentials@v1 | ||
with: | ||
aws-access-key-id: ${{ secrets.PROD_AWS_ACCESS_KEY_ID }} | ||
aws-secret-access-key: ${{ secrets.PROD_AWS_SECRET_ACCESS_KEY }} | ||
role-to-assume: arn:aws:iam::222222222222:role/my-github-actions-role-prod | ||
aws-region: us-west-2 | ||
|
||
- name: Copy files to the production website with the AWS CLI | ||
|
@@ -72,19 +68,39 @@ See [action.yml](action.yml) for the full documentation for this action's inputs | |
## Credentials | ||
|
||
We recommend following [Amazon IAM best practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) for the AWS credentials used in GitHub Actions workflows, including: | ||
* Do not store credentials in your repository's code. You may use [GitHub Actions secrets](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets) to store credentials and redact credentials from GitHub Actions workflow logs. | ||
* [Create an individual IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#create-iam-users) with an access key for use in GitHub Actions workflows, preferably one per repository. Do not use the AWS account root user access key. | ||
* Do not store credentials in your repository's code. | ||
* [Grant least privilege](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) to the credentials used in GitHub Actions workflows. Grant only the permissions required to perform the actions in your GitHub Actions workflows. | ||
* [Rotate the credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials) used in GitHub Actions workflows regularly. | ||
* [Monitor the activity](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#keep-a-log) of the credentials used in GitHub Actions workflows. | ||
|
||
## Assuming a Role | ||
If you would like to use the static credentials you provide to this action to assume a role, you can do so by specifying the role ARN in `role-to-assume`. | ||
The role credentials will then be configured in the Actions environment instead of the static credentials you have provided. | ||
The default session duration is 6 hours, but if you would like to adjust this you can pass a duration to `role-duration-seconds`. | ||
We recommend using GitHub's OIDC provider to get short-lived credentials needed for your actions. | ||
Specifying `role-to-assume` without providing an `aws-access-key-id` or a `web-identity-token-file` will signal to the action that you wish to use the OIDC provider. | ||
The default session duration is 1 hour when using the OIDC provider to directly assume an IAM Role. | ||
The default session duration is 6 hours when using an IAM User to assume an IAM Role (by providing an `aws-access-key-id`, `aws-secret-access-key`, and a `role-to-assume`) . | ||
If you would like to adjust this you can pass a duration to `role-duration-seconds`, but the duration cannot exceed the maximum that was defined when the IAM Role was created. | ||
The default session name is GitHubActions, and you can modify it by specifying the desired name in `role-session-name`. | ||
|
||
Example: | ||
The following table describes which identity is used based on which values are supplied to the Action: | ||
|
||
| **Identity Used** | `aws-access-key-id` | `role-to-assume` | `web-identity-token-file` | | ||
|------------------------------------------------------------------|---------------------|------------------|---------------------------| | ||
| [✅ Recommended] Assume Role directly using GitHub OIDC provider | | ✔ | | | ||
| IAM User | ✔ | | | | ||
| Assume Role using IAM User credentials | ✔ | ✔ | | | ||
| Assume Role using WebIdentity Token File credentials | | ✔ | ✔ | | ||
|
||
### Examples | ||
|
||
```yaml | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have a general question I've been struggling to find documentation on from Github. What I'm seeing in my test pipelines is we need to set the permissions:
id-token: write
contents: read In order to both get the OIDC token and continue to be able to use the token for normal The google auth plugin did seem to allude to this setting when they updated for OIDC I noticed - https://github.com/google-github-actions/auth#usage I can't find any Github documentation around this, which I assume is because this actual feature is still beta? If AWS or anyone understands how this thing works, maybe it could be documented here :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. we're also still waiting on official documenation There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Awesome, thanks for verifying I'm not just missing something. |
||
- name: Configure AWS Credentials | ||
uses: aws-actions/configure-aws-credentials@v1 | ||
with: | ||
aws-region: us-east-2 | ||
role-to-assume: arn:aws:iam::123456789100:role/my-github-actions-role | ||
role-session-name: MySessionName | ||
``` | ||
In this example, the Action will load the OIDC token from the GitHub-provided environment variable and use it to assume the role `arn:aws:iam::123456789100:role/my-github-actions-role` with the session name `MySessionName`. | ||
|
||
```yaml | ||
richardhboyd marked this conversation as resolved.
Show resolved
Hide resolved
|
||
- name: Configure AWS Credentials | ||
uses: aws-actions/configure-aws-credentials@v1 | ||
|
@@ -99,48 +115,52 @@ Example: | |
``` | ||
In this example, the secret `AWS_ROLE_TO_ASSUME` contains a string like `arn:aws:iam::123456789100:role/my-github-actions-role`. To assume a role in the same account as the static credentials, you can simply specify the role name, like `role-to-assume: my-github-actions-role`. | ||
|
||
### Permissions for assuming a role | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we also remove permissions to assuming a role from the |
||
|
||
In order to assume a role, the IAM user for the static credentials must have the following permissions: | ||
```json | ||
{ | ||
"Version": "2012-10-17", | ||
"Statement": [ | ||
{ | ||
"Action": [ | ||
"sts:AssumeRole", | ||
"sts:TagSession" | ||
], | ||
"Resource": "arn:aws:iam::123456789012:role/my-github-actions-role", | ||
"Effect": "Allow" | ||
} | ||
] | ||
} | ||
### Sample IAM Role CloudFormation Template | ||
```yaml | ||
Parameters: | ||
GitHubOrg: | ||
Type: String | ||
RepositoryName: | ||
Type: String | ||
OIDCProviderArn: | ||
Description: Arn for the GitHub OIDC Provider. | ||
Default: "" | ||
Type: String | ||
|
||
Conditions: | ||
CreateOIDCProvider: !Equals | ||
- !Ref OIDCProviderArn | ||
- "" | ||
|
||
Resources: | ||
Role: | ||
Type: AWS::IAM::Role | ||
Properties: | ||
RoleName: ExampleGithubRole | ||
AssumeRolePolicyDocument: | ||
Statement: | ||
- Effect: Allow | ||
Action: sts:AssumeRoleWithWebIdentity | ||
Principal: | ||
Federated: !Ref GithubOidc | ||
Condition: | ||
StringLike: | ||
vstoken.actions.githubusercontent.com:sub: !Sub repo:${GitHubOrg}/${RepositoryName}:* | ||
|
||
GithubOidc: | ||
Type: AWS::IAM::OIDCProvider | ||
Condition: CreateOIDCProvider | ||
Properties: | ||
Url: https://vstoken.actions.githubusercontent.com | ||
ClientIdList: [sigstore] | ||
ThumbprintList: [a031c46782e6e6c662c2c87c76da9aa62ccabd8e] | ||
|
||
Outputs: | ||
Role: | ||
Value: !GetAtt Role.Arn | ||
``` | ||
|
||
The role's trust policy must allow the IAM user to assume the role: | ||
```json | ||
{ | ||
"Version": "2012-10-17", | ||
"Statement": [ | ||
{ | ||
"Sid": "AllowIamUserAssumeRole", | ||
"Effect": "Allow", | ||
"Action": "sts:AssumeRole", | ||
"Principal": {"AWS": "arn:aws:iam::123456789012:user/my-github-actions-user"}, | ||
"Condition": { | ||
"StringEquals": {"sts:ExternalId": "Example987"} | ||
} | ||
}, | ||
{ | ||
"Sid": "AllowPassSessionTags", | ||
"Effect": "Allow", | ||
"Action": "sts:TagSession", | ||
"Principal": {"AWS": "arn:aws:iam::123456789012:user/my-github-actions-user"} | ||
} | ||
] | ||
} | ||
``` | ||
The GitHub OIDC Provider only needs to be created once per account (i.e. multiple IAM Roles that can be assumed by the GitHub's OIDC can share a single OIDC Provider) | ||
|
||
### Session tagging | ||
The session will have the name "GitHubActions" and be tagged with the following tags: | ||
|
@@ -158,7 +178,10 @@ The session will have the name "GitHubActions" and be tagged with the following | |
|
||
_Note: all tag values must conform to [the requirements](https://docs.aws.amazon.com/STS/latest/APIReference/API_Tag.html). Particularly, `GITHUB_WORKFLOW` will be truncated if it's too long. If `GITHUB_ACTOR` or `GITHUB_WORKFLOW` contain invalid characters, the characters will be replaced with an '*'._ | ||
|
||
The action will use session tagging by default during role assumption. You can skip this session tagging by providing `role-skip-session-tagging` as true in the action's inputs: | ||
The action will use session tagging by default during role assumption. | ||
Note that for WebIdentity role assumption, the session tags have to be included in the encoded WebIdentity token. | ||
This means that Tags can only be supplied by the OIDC provider and not set during the AssumeRoleWithWebIdentity API call within the Action. | ||
You can skip this session tagging by providing `role-skip-session-tagging` as true in the action's inputs: | ||
|
||
```yaml | ||
uses: aws-actions/configure-aws-credentials@v1 | ||
|
@@ -189,7 +212,8 @@ with: | |
``` | ||
In this case, your runner's credentials must have permissions to assume the role. | ||
|
||
You can also assume a role using a web identity token file, such as if using [Amazon EKS IRSA](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-technical-overview.html). Pods running in EKS worker nodes that do not run as root can use this file to assume a role with a web identity. | ||
You can also assume a role using a web identity token file, such as if using [Amazon EKS IRSA](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-technical-overview.html). | ||
Pods running in EKS worker nodes that do not run as root can use this file to assume a role with a web identity. | ||
|
||
You can configure your workflow as follows in order to use this file: | ||
```yaml | ||
|
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -3,10 +3,12 @@ const aws = require('aws-sdk'); | |
const assert = require('assert'); | ||
const fs = require('fs'); | ||
const path = require('path'); | ||
const axios = require('axios'); | ||
|
||
// The max time that a GitHub action is allowed to run is 6 hours. | ||
// That seems like a reasonable default to use if no role duration is defined. | ||
const MAX_ACTION_RUNTIME = 6 * 3600; | ||
const DEFAULT_ROLE_DURATION_FOR_OIDC_ROLES = 3600; | ||
const USER_AGENT = 'configure-aws-credentials-for-github-actions'; | ||
const MAX_TAG_VALUE_LENGTH = 256; | ||
const SANITIZATION_CHARACTER = '_'; | ||
|
@@ -25,10 +27,11 @@ async function assumeRole(params) { | |
roleSessionName, | ||
region, | ||
roleSkipSessionTagging, | ||
webIdentityTokenFile | ||
webIdentityTokenFile, | ||
webIdentityToken | ||
} = params; | ||
assert( | ||
[sourceAccountId, roleToAssume, roleDurationSeconds, roleSessionName, region].every(isDefined), | ||
[roleToAssume, roleDurationSeconds, roleSessionName, region].every(isDefined), | ||
"Missing required input when assuming a Role." | ||
); | ||
|
||
|
@@ -43,6 +46,10 @@ async function assumeRole(params) { | |
let roleArn = roleToAssume; | ||
if (!roleArn.startsWith('arn:aws')) { | ||
// Supports only 'aws' partition. Customers in other partitions ('aws-cn') will need to provide full ARN | ||
assert( | ||
isDefined(sourceAccountId), | ||
"Source Account ID is needed if the Role Name is provided and not the Role Arn." | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can the user provide this information? I wonder if we can provide a suggested action here if we end up in this error scenario 🤔 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is what I was struggling with. It seems like we're trying to help the customer by saying "if you only provide a Role Name, we'll try our best to figure out which account you're talking about". Customers will encounter this exception if they supply a Role Name for use with the OIDC. Our current logic has the STS client call "get-caller-identity" and parse the response to get an account ID. I feel like this is a bit too much magic for customers who may be running this in a self-hosted runner with some limited permissions in AccountA and we might try to accidentally assume another role in accountA. I'd prefer that for the OIDC users we ask them to explicitly provide the Arn and we can relax it later. |
||
); | ||
roleArn = `arn:aws:iam::${sourceAccountId}:role/${roleArn}`; | ||
} | ||
|
||
|
@@ -79,9 +86,15 @@ async function assumeRole(params) { | |
} | ||
|
||
let assumeFunction = sts.assumeRole.bind(sts); | ||
|
||
// These are customizations needed for the GH OIDC Provider | ||
if(isDefined(webIdentityToken)) { | ||
delete assumeRoleRequest.Tags; | ||
|
||
if(isDefined(webIdentityTokenFile)) { | ||
core.debug("webIdentityTokenFile provided. Will call sts:AssumeRoleWithWebIdentity and take session tags from token contents.") | ||
assumeRoleRequest.WebIdentityToken = webIdentityToken; | ||
assumeFunction = sts.assumeRoleWithWebIdentity.bind(sts); | ||
} else if(isDefined(webIdentityTokenFile)) { | ||
core.debug("webIdentityTokenFile provided. Will call sts:AssumeRoleWithWebIdentity and take session tags from token contents."); | ||
delete assumeRoleRequest.Tags; | ||
|
||
const webIdentityTokenFilePath = path.isAbsolute(webIdentityTokenFile) ? | ||
|
@@ -172,6 +185,21 @@ async function exportAccountId(maskAccountId, region) { | |
return accountId; | ||
} | ||
|
||
async function getWebIdentityToken() { | ||
const isDefined = i => !!i; | ||
const {ACTIONS_ID_TOKEN_REQUEST_URL, ACTIONS_ID_TOKEN_REQUEST_TOKEN} = process.env; | ||
|
||
assert( | ||
[ACTIONS_ID_TOKEN_REQUEST_URL, ACTIONS_ID_TOKEN_REQUEST_TOKEN].every(isDefined), | ||
'Missing required environment value. Are you running in GitHub Actions?' | ||
); | ||
const { data } = await axios.get(`${ACTIONS_ID_TOKEN_REQUEST_URL}&audience=sigstore`, { | ||
headers: {"Authorization": `bearer ${ACTIONS_ID_TOKEN_REQUEST_TOKEN}`} | ||
} | ||
); | ||
return data.value; | ||
} | ||
|
||
function loadCredentials() { | ||
// Force the SDK to re-resolve credentials with the default provider chain. | ||
// | ||
|
@@ -234,18 +262,28 @@ async function run() { | |
const maskAccountId = core.getInput('mask-aws-account-id', { required: false }); | ||
const roleToAssume = core.getInput('role-to-assume', {required: false}); | ||
const roleExternalId = core.getInput('role-external-id', { required: false }); | ||
const roleDurationSeconds = core.getInput('role-duration-seconds', {required: false}) || MAX_ACTION_RUNTIME; | ||
let roleDurationSeconds = core.getInput('role-duration-seconds', {required: false}) || MAX_ACTION_RUNTIME; | ||
const roleSessionName = core.getInput('role-session-name', { required: false }) || ROLE_SESSION_NAME; | ||
const roleSkipSessionTaggingInput = core.getInput('role-skip-session-tagging', { required: false })|| 'false'; | ||
const roleSkipSessionTagging = roleSkipSessionTaggingInput.toLowerCase() === 'true'; | ||
const webIdentityTokenFile = core.getInput('web-identity-token-file', { required: false }) | ||
const webIdentityTokenFile = core.getInput('web-identity-token-file', { required: false }); | ||
|
||
if (!region.match(REGION_REGEX)) { | ||
throw new Error(`Region is not valid: ${region}`); | ||
} | ||
|
||
exportRegion(region); | ||
|
||
// This wraps the logic for deciding if we should rely on the GH OIDC provider since we may need to reference | ||
// the decision in a few differennt places. Consolidating it here makes the logic clearer elsewhere. | ||
const useGitHubOIDCProvider = () => { | ||
// The assumption here is that self-hosted runners won't be populating the `ACTIONS_ID_TOKEN_REQUEST_TOKEN` | ||
// environment variable and they won't be providing a web idenity token file or access key either. | ||
// V2 of the action might relax this a bit and create an explicit precedence for these so that customers | ||
// can provide as much info as they want and we will follow the established credential loading precedence. | ||
return roleToAssume && process.env.ACTIONS_ID_TOKEN_REQUEST_TOKEN && !accessKeyId && !webIdentityTokenFile | ||
} | ||
|
||
// Always export the source credentials and account ID. | ||
// The STS client for calling AssumeRole pulls creds from the environment. | ||
// Plus, in the assume role case, if the AssumeRole call fails, we want | ||
|
@@ -258,15 +296,26 @@ async function run() { | |
|
||
exportCredentials({accessKeyId, secretAccessKey, sessionToken}); | ||
} | ||
|
||
// Regardless of whether any source credentials were provided as inputs, | ||
// validate that the SDK can actually pick up credentials. This validates | ||
// cases where this action is on a self-hosted runner that doesn't have credentials | ||
// configured correctly, and cases where the user intended to provide input | ||
// credentials but the secrets inputs resolved to empty strings. | ||
await validateCredentials(accessKeyId); | ||
|
||
const sourceAccountId = await exportAccountId(maskAccountId, region); | ||
|
||
// Attempt to load credentials from the GitHub OIDC provider. | ||
// If a user provides an IAM Role Arn and DOESN'T provide an Access Key Id | ||
// The only way to assume the role is via GitHub's OIDC provider. | ||
let sourceAccountId; | ||
let webIdentityToken; | ||
if(useGitHubOIDCProvider()) { | ||
webIdentityToken = await getWebIdentityToken(); | ||
roleDurationSeconds = core.getInput('role-duration-seconds', {required: false}) || DEFAULT_ROLE_DURATION_FOR_OIDC_ROLES; | ||
// We don't validate the credentials here because we don't have them yet when using OIDC. | ||
} else { | ||
// Regardless of whether any source credentials were provided as inputs, | ||
// validate that the SDK can actually pick up credentials. This validates | ||
// cases where this action is on a self-hosted runner that doesn't have credentials | ||
// configured correctly, and cases where the user intended to provide input | ||
// credentials but the secrets inputs resolved to empty strings. | ||
await validateCredentials(accessKeyId); | ||
|
||
sourceAccountId = await exportAccountId(maskAccountId, region); | ||
} | ||
|
||
// Get role credentials if configured to do so | ||
if (roleToAssume) { | ||
|
@@ -278,10 +327,19 @@ async function run() { | |
roleDurationSeconds, | ||
roleSessionName, | ||
roleSkipSessionTagging, | ||
webIdentityTokenFile | ||
webIdentityTokenFile, | ||
webIdentityToken | ||
}); | ||
exportCredentials(roleCredentials); | ||
await validateCredentials(roleCredentials.accessKeyId); | ||
// I don't know a good workaround for this. I'm not sure why we're validating the credentials | ||
// so frequently inside the action. The approach I've taken here is that if the GH OIDC token | ||
// isn't set, then we're in a self-hosted runner and we need to validate the credentials for | ||
// some mysterious reason that wasn't explained by whoever wrote this aciton. | ||
// | ||
// It's gross but it works so ... ¯\_(ツ)_/¯ | ||
if (!process.env.ACTIONS_ID_TOKEN_REQUEST_TOKEN) { | ||
await validateCredentials(roleCredentials.accessKeyId); | ||
} | ||
await exportAccountId(maskAccountId, region); | ||
} | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I may be misunderstanding this documentation, but it doesn't look like this logic was implemented in the PR and the default is still using
MAX_ACTION_RUNTIME
regardless of method. I think 3600 seconds is the default on new roles and that would mean we'd need to setrole-duration-seconds
on every use of the plugin or change the maximum session duration on our roles. I like the 1 hour default if using OIDC.I'm really excited for this to land and it's been working great in testing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was a really good catch! Thank you! I'm fixing it now. It'll default to 3600 for GH OIDC provider Roles and remain 6hrs (for backwards compatibility reasons) for the rest.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds perfect, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed, and I updated the test to validate it.