Lab — Azure DevOps least access and secure files

Outcome

Configure a disposable Azure DevOps project so a contributor can use a pipeline and one approved sensitive file, while a reader cannot. Diagnose whether a failure comes from portal access level, Azure DevOps permission, or secure-file authorization. Delete every training artifact afterward.

Safety and prerequisites

Use a personal/disposable Azure DevOps organization and project. You need permission to manage project users/groups, Library items, and pipelines. Use a generated dummy text certificate/key file that has no value outside this lab—never upload a real secret, production signing certificate, SSH private key, or customer data.

Read azure-devops-security-groups, azure-devops-access-levels, and azure-pipelines-secure-files first. Record the project URL and the identities you use for the test; do not grant Project Administrator merely to make a test pass.

Learn and plan

1. State the boundary before changing anything: access level controls portal feature availability; a security group/object permission controls an Azure DevOps action; secure-file authorization controls whether a particular pipeline may download that sensitive file.
2. Create or choose two disposable test identities if your organization policy permits: lab-contributor and lab-reader. If you cannot create identities, perform the configuration and inspect the effective permission views without impersonation; mark the behavioral verification as unavailable rather than guessing.
3. Give the contributor the minimum access level that permits the intended pipeline work (normally Basic) and add it to the project’s Contributors group. Give the reader the lowest appropriate level and Readers group. Do not change organization defaults for this exercise.

Do — configure a permission boundary

1. In Project settings → Permissions, inspect the inherited permissions for Readers and Contributors. Record one action the reader should not perform, such as editing pipeline definition or queueing a protected deployment.
2. Create a project-level custom group named Lab secure-file consumers; add only lab-contributor. Do not make the group a Project Administrator.
3. Create a minimal YAML pipeline in a disposable repository that checks out the repository and has a single job. Commit it through a pull request so the pipeline definition has source traceability.
4. Queue the pipeline as the contributor. Verify the expected successful run and record its URL/run number.
5. From the reader identity (or by inspecting the permission trace), attempt the intended restricted action. Verify it is denied or unavailable. Record whether the reason is the access level, group/object permission, or both.

Do — manage a secure file

1. Create a harmless local training file, for example LAB-NOT-A-SECRET.txt, containing only the current date and a random label. Keep a copy locally so you can compare it after download.
2. In Pipelines → Library → Secure files, upload that file. Confirm it appears in the list. Secure files are encrypted at rest and are not editable or replaceable in place; treat a replacement as a new controlled artifact.
3. In the file’s security settings, grant use to Lab secure-file consumers or the narrowly scoped pipeline identity path supported by your organization. Do not authorize all pipelines.
4. Add the Azure Pipelines DownloadSecureFile task to the YAML, referring to the training file by name. Run it as the contributor and verify the task succeeds and the downloaded file has the expected harmless content. Do not print real secrets in logs.
5. Remove the pipeline’s authorization for the secure file (or remove the contributor from the allowed group), then run again. Verify a controlled authorization failure. Restore only the minimal authorization and verify the run succeeds again.

Verify

Record all of the following before moving on:

1. The contributor’s effective access level and project-group membership, plus the reader’s denied or unavailable action.
2. A successful pipeline run that downloads only LAB-NOT-A-SECRET.txt and proves its expected harmless content without printing it to logs.
3. The secure file’s narrow authorization list, the denied run after authorization is removed, and the successful run after the same minimum authorization is restored.

You should now understand: access level, Azure DevOps object permission, and secure-file authorization are separate gates. Passing one does not imply passing either of the others.

Break, diagnose, and fix

Deliberately perform one safe failure at a time. Do not compensate by granting Project Administrator or authorizing all pipelines.

Safe failure	Diagnosis and minimum fix
Remove the contributor from the secure-file consumer group.	Inspect the failed DownloadSecureFile task and restore only that membership or the equivalent narrow authorization.
Keep Basic access but deny the pipeline action through its project/repository permission.	Inspect the object permission trace; remove the explicit Deny or grant only the required Allow.
Use a reader account for a protected pipeline action.	Identify whether the visible limitation is access level or permission, then return the account to its original training boundary.

Symptom	First boundary to inspect	Why
A user cannot access a portal feature even after joining Contributors	azure-devops-access-levels	Group membership does not increase the portal feature entitlement.
A Basic user can open the project but cannot edit a repository or queue a pipeline	azure-devops-security-groups and object permission trace	Basic access does not override a group restriction or explicit Deny.
The pipeline runs but DownloadSecureFile is unauthorized	azure-pipelines-secure-files	The file is a separately authorized pipeline resource.
Azure deployment fails after this lab	service-connection and Azure rbac	Azure DevOps project permissions do not grant rights to an Azure subscription.

Scenario practice

You should now be able to answer all three without looking up the terms:

1. Configuration: Which minimum Azure DevOps group, access level, and secure-file authorization would you set for a developer who needs one pipeline but no project administration?
2. Diagnosis: A user has Basic access and still cannot download the secure file. Which two independent permissions can be wrong?
3. Distinction: Why is changing a service connection’s Azure RBAC role not the fix for a secure-file authorization failure?

Cleanup

1. Delete the secure file from Library after confirming no other pipeline references it.
2. Delete the training pipeline/repository or remove the DownloadSecureFile step and its authorization.
3. Remove the custom group and test identities/memberships you created. Restore original access levels.
4. Delete the local dummy file. Do not delete or rotate unrelated credentials.

Evidence to retain

Keep screenshots or URLs for: group membership/permission trace, the successful run, the deliberate secure-file denial, the restored successful run, and the cleanup state. Those are observable evidence—not merely a claim that a YAML file exists.

Related

azure-devops-security-groups · azure-devops-access-levels · azure-pipelines-secure-files · service-connection · pipeline-security

Source: Azure DevOps permissions and security groups · Access levels · Secure files

Re-audit when Azure DevOps access-level, permission-inheritance, secure-file authorization, or pipeline-resource behavior changes.