Question
By supporting OIDC in GitHub Actions, we eliminate the need for credentials such as secret keys or service account JSON files. This advantage is crucial for many companies.
Conclusion
The conclusion is GitHub actions.
I’d like to write down how I reached this conclusion in this article. Initially, I misunderstood that Cloud Provider issued the ID token.
What is the ID token & access token?
This section is just a recap part of Open ID Connect.
The ID token is for authentication, Access token is for authorization.
Finally, we want to obtain an Access token.
Workflow
- Register OIDC in the Cloud Provider
- Request ID token to Github OIDC Provider
- Request ID token issued by Github OIDC Provider and role or service account to Cloud Provider
- Get the Access token and use it in the GitHub actions workflow
General workflow
Generally, the client requests an ID token from the OpenID Provider. In the workflow described above, GitHub Actions (as the client) requests an ID token from the GitHub OpenID Provider.
How do we authenticate
The target URL on GitHub can be registered as a provider URL and authenticated by sending an ID token that meets the required format. After authentication, you can obtain an access token.
Register the provider URL in each provider
The target URL is https://token.actions.githubusercontent.com.
Issue ID token in Github Actions
This implementation means Github actions workflow requests the ID token to the Github OIDC Provider. This is the ID token I expected.
jobs:
hoge:
runs-on: ubuntu-latest
permissions:
id-token: writehttps://token.actions.githubusercontent.com/.well-known/openid-configuration
How do we authorize?
In both AWS and GCP, we specify the role or service account. Authorization is required to obtain access tokens with short validity periods. In AWS, the 「sts:AssumeRoleWithWebIdentity」 action is applicable. In GCP, the 「roles/iam.workloadIdentityUser」 role is applicable.
