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.
\nThe Configure OIDC rulesets and subject claims documentation is the primary reference.
\nDocker 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.
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.
\nDSE 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.
\nObtain 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.
\nFor 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.
\nUse 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.
\nProposed 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.
\nExercise 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.
\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: documented behavior\nThe Configure OIDC rulesets and subject claims documentation is the primary reference.\nDocker 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhat actual approved subject string will the workflow present?\nWhich rulesets match that whole string?\nWhich resource and scope does each match contribute?\nWhat effective access should remain after a proposed rule change?\n\nDSE recommendation: calculate the match set before editing a rule\nDSE 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.\nObtain 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.\nFor 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.\nUse 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.\nVerification and evidence\nProposed 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.\nExercise 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.\nOfficial references\n\nConfigure OIDC rulesets and subject claims — Docker Docs.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: documented behavior\n\nThe [Configure OIDC rulesets and subject claims](https://docs.docker.com/security/authentication/oidc-connections/rulesets-claims/) documentation is the primary reference.\n\nDocker 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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- What actual approved subject string will the workflow present?\n\n- Which rulesets match that whole string?\n\n- Which resource and scope does each match contribute?\n\n- What effective access should remain after a proposed rule change?\n\n## DSE recommendation: calculate the match set before editing a rule\n\nDSE 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.\n\nObtain 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.\n\nFor 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.\n\nUse 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.\n\n## Verification and evidence\n\nProposed 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.\n\nExercise 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.\n\n## Official references\n\n- [Configure OIDC rulesets and subject claims](https://docs.docker.com/security/authentication/oidc-connections/rulesets-claims/) — Docker Docs.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/combine-every-matching-docker-oidc-ruleset-when-reviewing-access/", "url": "https://update.dsesecurity.com/updates/combine-every-matching-docker-oidc-ruleset-when-reviewing-access/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-30" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/combine-every-matching-docker-oidc-ruleset-when-reviewing-access/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Combine every matching Docker OIDC ruleset when reviewing access", "item": "https://update.dsesecurity.com/updates/combine-every-matching-docker-oidc-ruleset-when-reviewing-access/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/combine-every-matching-docker-oidc-ruleset-when-reviewing-access/#article", "identifier": "https://update.dsesecurity.com/updates/combine-every-matching-docker-oidc-ruleset-when-reviewing-access/", "url": "https://update.dsesecurity.com/updates/combine-every-matching-docker-oidc-ruleset-when-reviewing-access/", "headline": "Combine every matching Docker OIDC ruleset when reviewing access", "description": "Docker grants the union of resources and scopes from matching OIDC rulesets; review the complete match set for the actual subject claim.", "abstract": "Docker grants the union of resources and scopes from matching OIDC rulesets; review the complete match set for the actual subject claim.", "articleBody": "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.\nSource fact: documented behavior\nThe Configure OIDC rulesets and subject claims documentation is the primary reference.\nDocker 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhat actual approved subject string will the workflow present?\nWhich rulesets match that whole string?\nWhich resource and scope does each match contribute?\nWhat effective access should remain after a proposed rule change?\n\nDSE recommendation: calculate the match set before editing a rule\nDSE 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.\nObtain 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.\nFor 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.\nUse 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.\nVerification and evidence\nProposed 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.\nExercise 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.\nOfficial references\n\nConfigure OIDC rulesets and subject claims — Docker Docs.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-30T06:46:40+00:00", "dateModified": "2026-10-30T06:47:30+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/combine-every-matching-docker-oidc-ruleset-when-reviewing-access/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/combine-every-matching-docker-oidc-ruleset-when-reviewing-access/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Combine every matching Docker OIDC ruleset when reviewing access" }, "articleSection": [ "Cybersecurity", "IT" ], "keywords": [ "Cybersecurity", "IT", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 495, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Docker Docs — Configure OIDC rulesets and subject claims", "url": "https://docs.docker.com/security/authentication/oidc-connections/rulesets-claims/" } } ] } }