Document listSecrets access granted by Container Apps built-in roles - #128755
Conversation
Several Container Apps built-in roles define permissions with wildcard patterns that match the listSecrets action, so they grant read access to secret values in plain text even when the role name or description suggests narrower access. - manage-secrets.md: add a 'Permissions for managing secrets' section listing the built-in roles that grant listSecrets, plus a custom role example that omits it. - jobs.md: correct the Permissions section to name the Jobs Contributor and Jobs Operator roles, call out that both grant listSecrets, and fix the custom role action list (executions/read, stop/action, managedEnvironments/read). - security.md: add secrets management best practices covering role review and custom roles. Roles verified against live ARM role definitions and articles/role-based-access-control/built-in-roles/containers.md. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
Tiago Alves Macambira (@tmacam) : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change. |
|
Tiago Alves Macambira (@tmacam) : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change. |
|
Learn Build status updates of commit dbcb039: ✅ Validation status: passed
For more details, please refer to the build report. |
…cess The job start API accepts a template override that replaces the container image, command, and environment variables for the execution. An identity holding only Microsoft.App/jobs/start/action can therefore run an arbitrary container with the job's secrets injected and read the values from inside it. Omitting listSecrets from a custom role does not prevent this, so the previous guidance was misleading. - jobs.md: replace the vague 'you get access to all the secrets' note with an IMPORTANT callout explaining the override mechanism, and stop presenting the custom role action list as a way to run jobs without secret access. - manage-secrets.md: change the custom role example to a monitor-only role that omits start/action, and add a WARNING covering the start/action escalation path. Verified against the job start REST contract documented in jobs.md and the --image/--command/--env-vars parameters of 'az containerapp job start'. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
Correcting an inaccuracy I introduced in the initial commit, raised in review. The earlier revision framed a custom role that omits
POST .../providers/Microsoft.App/jobs/my-job/start?api-version=2023-05-01
{
"containers": [
{ "image": "...", "name": "main", "command": ["echo", "..."] }
]
}
So an identity holding only Changes in
Net guidance: treat permission to start a job as equivalent to permission to read that job's secrets. |
|
Learn Build status updates of commit ca961a5: ✅ Validation status: passed
For more details, please refer to the build report. |
|
Craig Shoemaker (@craigshoemaker) Can you review the proposed changes? IMPORTANT: When the changes are ready for publication, adding a #label:"aq-pr-triaged" |
prmerger-automator
Bot
added
the
aq-pr-triaged
There was a problem hiding this comment.
Note
Copilot was unable to run its full agentic suite in this review.
Pull request overview
Documents that certain Azure Container Apps built-in roles grant access to secret values via wildcard */action permissions (matching listSecrets), and guides readers toward custom roles for narrower access.
Changes:
- Adds a new secrets-permissions section listing built-in roles whose wildcards match
listSecrets, plus guidance and a custom-role example. - Corrects Container Apps Jobs role recommendations and updates the custom-role action list for job scenarios.
- Adds security best practices and cross-links to the new secrets-permissions documentation.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| articles/container-apps/security.md | Adds best-practice bullets and links to the new secrets permissions guidance. |
| articles/container-apps/manage-secrets.md | Adds a roles/permissions table for listSecrets, callouts, and a narrower custom-role example. |
| articles/container-apps/jobs.md | Updates recommended built-in roles for jobs, clarifies listSecrets wildcard impact, and corrects custom-role action guidance. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Refine the role guidance after review: - explain that job start can reference retained secrets rather than implying all secrets are injected automatically - qualify managed identity access by container identity availability - link directly to the Jobs - Start REST API - replace Contributor requirements with jobs/start/action - add individual execution read and stop operations to custom roles - correct wildcard and ConnectedEnvironments role descriptions - normalize the permissions table and scope the jobs-specific warning Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
Learn Build status updates of commit 6674a33: ✅ Validation status: passed
For more details, please refer to the build report. |
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
Learn Build status updates of commit d195673: ❌ Validation status: errorsPlease follow instructions here which may help to resolve issue.
For more details, please refer to the build report. Note: Your PR may contain errors or warnings or suggestions unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them. |
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
Learn Build status updates of commit 133252d: ✅ Validation status: passed
For more details, please refer to the build report. |
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
Learn Build status updates of commit 8f9388f: ✅ Validation status: passed
For more details, please refer to the build report. |
Summary
Several Azure Container Apps built-in roles grant
listSecretsoperations through wildcard or explicit permissions. This PR documents which roles can read container app, job, and Dapr component secret values, clarifies that assignment scope determines the affected resources, and advises customers to create custom roles when built-in roles are broader than required.It also documents an important jobs-specific boundary:
Microsoft.App/jobs/start/actiondoesn't grantlistSecrets, but the Jobs - Start API accepts an execution-template override. A caller who can start a job and knows a secret name can run a container of their choosing, reference that secret, and use managed identities configured to be available to the container.Changes
manage-secrets.md, separates app and job secret permissions from Dapr component secret permissions, and includes a narrow execution viewer/stopper example.jobs.mdwith job-specific roles, exact permissions, a warning beside the execution-template override examples, and links to managed identity availability controls.security.mdandsecure-deployment.md.dapr-component-connect-services.mddocuments platform-managed Dapr component secrets.relocate-region.mdand documents its secret-access implications.Verification
Role claims were checked against live ARM role definitions and
articles/role-based-access-control/built-in-roles/containers.md. Operation names were confirmed through the Microsoft.App provider operations.The Jobs - Start behavior was verified against the stable ARM OpenAPI contract and the Container Apps RP implementation:
Jobs_Startis gated byMicrosoft.App/jobs/start/actionand accepts an optionalJobExecutionTemplatebody.secretRef.secretRefagainst the stored job secrets.Reader roles are intentionally not listed because their
*/readpermissions don't match.../listSecrets/actionoperations.