GitHub OIDC Issuer Url
The github oidc issuer url lets your workflows log in to cloud accounts without static keys. You add this web address to your cloud identity provider to check signed workflow tokens. Teams often start by trusting every repo or branch in their account to save time. Broad trust rules let any workflow assume high-level roles and run risky commands in production. How the github oidc issuer url works in workflows GitHub Actions includes a built-in token service that signs identity tokens for each
GitHub Actions Security + K8s OIDC Authentication: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
The github oidc issuer url lets your workflows log in to cloud accounts without static keys. You add this web address to your cloud identity provider to check signed workflow tokens. Teams often start by trusting every repo or branch in their account to save time. Broad trust rules let any workflow assume high-level roles and run risky commands in production.
How the github oidc issuer url works in workflows
GitHub Actions includes a built-in token service that signs identity tokens for each workflow job. The github oidc issuer url tells your cloud provider where to find the public signing keys. When a workflow runs, it asks the GitHub token service for a signed JSON web token. This token holds claims about the repo name, branch, actor, and workflow file path.
Your workflow then sends this signed token to your cloud account to request a role. The cloud provider visits the issuer web address and reads the public key list. It checks the token signature and compares the token claims against your trust rules. If the repo and branch match your rule, the cloud returns a temporary role token.
Teams on enterprise cloud plans can also turn on a custom issuer web address. That option adds your enterprise slug to the address so other tenants cannot match your trust rules. Both standard and custom addresses expose a discovery file that lists all valid claim fields.
How to scope trust rules on your cloud roles
Relying only on the issuer address is not enough to keep your cloud account safe. Every workflow on GitHub shares the same default issuer address across all public and private repos. You must also check the subject and audience claims inside your cloud role trust policy.
A strict subject rule checks the exact owner, repo name, and branch or tag name. You should tie production roles to a protected main branch or a specific release tag. Pull request workflows from forks or feature branches should only receive read-only roles in test accounts. You should also set a short token lifetime so temporary keys expire as soon as jobs finish.
GitHub Actions Security + K8s OIDC Authentication: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native token setup solves and what it leaves open
Using OpenID Connect removes long-lived cloud keys from your repo secrets and build settings. You no longer need to rotate static keys by hand or worry about leaked secret values. Cloud audit logs also show which workflow job assumed the role and when it logged in.
Still, the issuer trust check only decides whether a workflow job can log in. Once the job receives a cloud role, it gets every permission attached to that role. Native role trust cannot inspect the actual database queries or shell commands that run inside the job. A bad script or broken dependency in a trusted branch can still drop tables or read raw customer emails.
Cloud role policies also do not mask sensitive fields like phone numbers or card numbers in query results. If a build log prints query output, those raw values can end up in plain text. Teams need runtime controls that check each command and rewrite sensitive data fields in results.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Why does my cloud role reject the workflow token?
Most failures happen when the subject claim in the token does not match your role trust rule. Check that the repo name, branch name, and audience string match the exact case in your policy.
Do I need to add a Trailing Slash to the issuer address?
Most cloud providers expect the exact issuer address without a trailing slash at the end. Check the discovery document from the token service to see the exact string inside the issuer field.
Can a pull request from a fork use my cloud role?
By default, workflows from forked repos do not get write permissions to request an identity token. If you change workflow settings, a strict branch check in your cloud role will still block forks.