Combine every matching Docker OIDC ruleset when reviewing access

Bottom line: Review every ruleset that matches an intended workflow subject. Write the combined authorization result before approving a new rule or removing an existing one.

Source fact: documented behavior

The Configure OIDC rulesets and subject claims documentation is the primary reference.

Docker compares the token’s subject claim with every ruleset on an OIDC connection and grants the resources and scopes from matching rulesets. When several rulesets match, the effective grant is the union of their resources and scopes. The subject claim is the JWT’s single sub string, rather than separate repository, branch and environment input fields.

What the source does not establish

This article addresses Docker connection authorization, not GitHub repository protection rules or a general cloud-provider trust policy. It does not approve a wildcard, presume the subject format of an existing repository or establish the permissions of a token before its actual claim and rules have been reviewed.

Applicability questions

• What actual approved subject string will the workflow present?
• Which rulesets match that whole string?
• Which resource and scope does each match contribute?
• What effective access should remain after a proposed rule change?

DSE recommendation: calculate the match set before editing a rule

DSE recommends a worksheet with one row per matching ruleset. Record its subject pattern, resources and scopes, then write the intended combined grant in plain language. Include rules that appear broader or older than the proposed change; do not stop at the first plausible match.

Obtain the actual subject through the approved identity-review workflow. Retain only the nonsecret claim information needed for comparison, rather than a reusable token. Keep assumptions about repository naming, branch context and environment identity visible until the workflow owner confirms them.

For a proposed new rule, compare the resulting union with the existing grant. Identify any newly reachable resource or additional operation before approval. For removal, explain which access should disappear and which access another matching rule is expected to retain. Avoid evaluating one ruleset in isolation from the connection.

Use exact, reviewed patterns wherever practical and require a stated operational reason for broader matching. Have both the registry resource owner and workflow owner accept the effective access. Keep connection lifecycle, token-exchange troubleshooting and repository protections under their separate procedures.

Verification and evidence

Proposed verification: prepare an isolated connection and harmless repository resources. Create a controlled subject case with two matching rules contributing different approved operations, plus a nonmatching case. Predict the complete allowed and denied operation set before exchanging a test identity.

Exercise only harmless operations within the approved scope and compare the actual results with the worksheet. Then remove one test rule and repeat the relevant cases to inspect the changed grant. Retain sanitized claim, ruleset revisions and actual operation results. Do not infer the combined permission result solely from a successful sign-in or one allowed pull.

Official references

• Configure OIDC rulesets and subject claims — Docker Docs.

Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.