GitHub Action OIDC
You set up github action oidc by linking your repo to a cloud role. Your runner then gets a short-lived token to log in without stored keys. Many teams set this up to get rid of old static secrets. Still, teams often grant broad permissions to that cloud role to avoid broken builds. When a job runs with wide role permissions, any bad script can change production data. How github action oidc works in your workflow In the past, teams saved static cloud keys inside their repo settings. Anyone wi
GitHub Actions Security + K8s OIDC Authentication: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up github action oidc by linking your repo to a cloud role. Your runner then gets a short-lived token to log in without stored keys. Many teams set this up to get rid of old static secrets. Still, teams often grant broad permissions to that cloud role to avoid broken builds. When a job runs with wide role permissions, any bad script can change production data.
How github action oidc works in your workflow
In the past, teams saved static cloud keys inside their repo settings. Anyone with repo write rights could read or steal those long-lived keys. Rotating those secrets took hours of manual work across many projects.
With OpenID Connect, your workflow runner asks the platform for a signed token. This token holds facts about the repo, the branch, and the job run. Next, the runner sends this signed token to your cloud provider.
Your cloud provider checks the token against a trust rule you wrote earlier. That trust rule checks if the repo name and branch match your list. If the facts match, the cloud returns a temporary credential for one role. The credential expires soon after the build job finishes its work. No human ever has to create, save, or rotate a long-lived secret key.
Why role trust rules need tight scope
A common mistake happens when teams write the cloud trust rule too broadly. If you only check the repo owner, any repo in your account can log in. A test repo could then assume a role meant for production systems.
You must lock the trust rule down to one repo and one branch. Some teams also lock the rule to a specific workflow file or tag. Even with a tight trust rule, the cloud role itself often holds huge power. Build jobs often need rights to change databases, read buckets, and run scripts.
Once the runner gets the temporary credential, the cloud trusts every command it sends. A bad third-party step in your workflow can use that exact same role. The cloud log will only show that the build role ran the command.
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 login solves and what it leaves open
Native token login solves the problem of leaked static keys sitting in repos. It proves which repo and branch started the cloud session at login time. That is a big step forward for any engineering team running cloud builds.
Still, login trust only decides who gets into the cloud account at the start. It does not check what individual SQL queries or shell commands do in flight. If a migration job runs a drop table statement, the cloud role allows it. If a script reads customer emails or card numbers, the role allows that too.
Teams also struggle to link a database query back to the human who approved it. And if a job queries production data, raw phone numbers or national IDs can leak into build logs. Data masking is needed to rewrite matched fields in results before logs save them.
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
Does github action oidc work with major cloud providers?
Yes, major clouds like AWS, Google Cloud, and Azure support this login method. Each cloud lets you set up a trust rule that accepts the workflow token.
What happens if I leave the branch check out of my trust rule?
Any branch or pull request in your repo will be able to assume the role. A developer could open a pull request that runs commands against your production systems.
Can OpenID Connect stop a build job from running a bad database query?
No, OpenID Connect only handles the initial login step to get a role token. Once the job logs in, the database allows any query that the role permits.