Architecture and operating model
Workload identity federation lets a CI/CD job use a short-lived OIDC identity token instead of storing a long-lived cloud key. The cloud STS or identity platform validates issuer, audience, subject and selected claims, then issues temporary access. This removes key rotation work, but an overbroad trust relationship or IAM role can still create broad access.
Google Cloud uses workload identity pools, providers, attribute mappings and conditions. AWS IAM treats an OIDC provider as a principal in a role trust policy and constrains AssumeRoleWithWebIdentity through claims. Microsoft Entra adds a federated identity credential to an app registration or user-assigned managed identity; issuer, subject and audience must match case-sensitively. Claim boundaries are common despite different product names.
Trusting only an issuer is unsafe when many organizations share it. Select stable claims for organization, repository, branch, environment and workflow identity. Allowing `main` alone may be insufficient if pull-request code can modify the trusted workflow. Set an audience for the target cloud and attach only the resource actions needed by the deployment.
Start with a read-only pilot role. Observe ID-token claims without logging the token, encode exact trust conditions and choose a short session lifetime. Prove that wrong repository, branch, audience and fork contexts are rejected. Remove the secret-based identity after validation; leaving it active preserves the older access path.
- 1OIDC token from CI/CD job
- 2Issuer, audience and subject validation
- 3Short-lived cloud identity from STS
- 4Scoped IAM action and audit
Design parameters
- Issuer and audience
- Pin the actual issuer URL and expected audience for the target cloud.
- Subject boundary
- Choose a stable combination of organization, repository, branch or environment and workflow claims.
- IAM scope
- Bind federation to a resource- and action-specific deployment role, not a broad administrator role.
- Session lifetime
- Use a short duration that covers the pipeline and test renewal or interrupted-job behavior.
- Audit
- Join issuer, subject, role, session and cloud audit event with a run ID without storing tokens.
Worked example
If a production deployment takes 18 minutes with a P95 of 24 minutes, a 30-minute session may provide a reasonable initial margin. A two-hour token is easier but expands the exposure window. Test whether a long step can re-authenticate, and measure instead of assuming a provider default.
For 40 repositories, one organization-wide trust condition creates unnecessary reach. Constrain the production role to verified claims such as `org/app`, `refs/heads/main` and `environment=production`; keep test separate. Provider syntax differs, so validate the same policy intent in three native rule systems.
Example commands: replace lab values and confirm permissions and software versions before use.
claims=$(cat oidc-claims.json)
jq '{iss,aud,sub,repository,ref,environment}' oidc-claims.json
# iss == EXPECTED_ISSUER
# aud == CLOUD_STS_AUDIENCE
# repository == 'org/app'
# ref == 'refs/heads/main'
# environment == 'production'Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Token exchange reports audience mismatch | The token aud may differ from the provider configuration. | Decode claims safely and compare aud with the provider or federated credential. |
| Unexpected branches obtain access | Subject or attribute conditions may not constrain repository and branch enough. | Match the successful audit subject with the trust-policy condition. |
| Federation succeeds but deployment returns 403 | Trust succeeded, while resource permission is missing or scoped elsewhere. | Separate STS success from the denied API action and inspect the IAM decision. |
Acceptance checks
- Validate issuer, audience and subject with a real pilot token.
- Test rejection for other repositories, branches, environments and forks.
- Limit the cloud role to required resources and actions.
- Test session lifetime against P95 duration and renewal behavior.
- Correlate CI/CD and cloud audit events with one run ID.
- Disable the old long-lived secret after validation.
Related concepts
Authentication and sessions
Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new access attempts are denied when the identity provider becomes unavailable.
Least privilege and separation of duties
Least privilege limits the permissions needed for a task to specific resources and time periods. Giving everyone the same administrator role complicates access reviews and investigations. Separate daily-use identities from privileged accounts, and restrict interactive use and unnecessary network access for service identities. An access matrix should show which operation an identity may perform on each resource. Test whether an application keeps working after a permission is removed: unnecessary privileges sometimes become visible only during controlled reduction.
Trust boundary and failure domain
A trust boundary separates components governed by different access decisions; a failure domain groups resources that one event can affect together. Two VLANs do not create a strong trust boundary when routing between them is unrestricted. Backups in different folders still share a failure domain if one administrator can delete both. Assess physical location, identity provider, management account, network path and power source separately. Test which access paths and recovery options remain available when a component is lost.
File permissions and service identities
File access combines users/groups, permission bits, ACLs and security policies. Running an application as root can hide permission problems; prefer a justified, restricted service identity in production. Directory traversal permission differs from file-read permission. Sharing permissions do not necessarily override filesystem restrictions. Identify the account actually running the application, directory chain and ACLs when troubleshooting. Test narrowly required access rather than opening permissions globally.
Version and support lifecycle
Installability does not prove production support. Review the compatibility chain across OS, application, drivers, extensions and management tools. Update plans should record version, support end, restart needs and rollback methods. A test environment that does not reflect production can produce misleading results. Validate service health and existing workflows after a change, not just version numbers. Remember that pinning a version can also prevent future security fixes.
Telemetry and time correlation
Telemetry combines logs, metrics and events that explain system behavior. A log describes an event, a metric shows behavior over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.