Anatomy of a typical problem
A scenario that plays out in most technology organizations: a developer configures a pipeline for deployment. They need access to AWS, Azure or GCP. They create a service account with appropriate permissions, generate a static access key, paste it as a repository secret. The pipeline works. Job done.
A year later: the developer who configured it left the company. The service account still exists. The key is still valid. Nobody knows it exists — because there is no secret inventory. Permissions are broader than needed — because “it was faster” at the time. The key was never rotated — because there is no rotation process.
This is not an exception. This is the state that audits reveal in the vast majority of organizations that have not previously had a formal secret management process in CI/CD.
Why this is a structural problem
Long-lived tokens are a problem not because developers are irresponsible. They are a problem because the architecture of accessing external systems in the traditional model requires it. For a pipeline to deploy an application to the cloud, it needs credentials — and for years the only way was to maintain static keys.
The consequence is inevitable: a key that must exist for a long time becomes a risk in itself. The longer it exists — the more places it could have been copied, exported, appended to a log, scraped by a third-party tool. The broader the permissions — the greater the potential impact of compromise.
Identity federation as a paradigm shift
Mechanisms like OIDC (OpenID Connect) change the fundamental assumption. Instead of “the pipeline has a key that lets it prove its identity,” the identity federation approach says: “the pipeline proves its identity through an external, trusted entity, and receives temporary credentials valid for minutes.”
In this model there is nothing to steal. A token that expired 15 minutes after the pipeline ran is useless to an attacker. Even if it leaked to logs, was copied by a malicious action, intercepted by monitoring — its value is zero after a very short time.
All major cloud providers (AWS, Azure, GCP) and popular CI/CD platforms (GitHub Actions, GitLab CI, CircleCI) support identity federation via OIDC. This is not experimental technology — it is a mature standard available for several years.
Managing the secret lifecycle
Identity federation eliminates the problem for new integrations — but in most organizations there is a legacy of dozens or hundreds of long-lived tokens from various eras. Their inventory, risk assessment and migration to safer mechanisms is a project in itself.
The key questions of this project are: what exists, what it gives access to, who needs it, how often it is used. Without answers to these questions, it is impossible to make rational decisions about what to rotate, what to eliminate, and what to migrate to OIDC.
Read also: