Write IAM policies for pull-only or push/pull access to Vultr Container Registry, limited to specific registries.
Vultr Container Registry integrates with IAM, so registry access follows least-privilege policies instead of account-wide API keys. The policies you attach to an identity control its access, so the way you write them determines whether it can only pull images, push and pull, or perform narrower operations such as tagging.
Follow this guide to write IAM policies for pull-only and push/pull registry access, limit them to specific registries, and mint credentials with fine-grained scope using the Vultr API.
This guide assumes you have already enabled IAM authentication for your registry. See How to Enable IAM Authentication for Vultr Container Registry for the setup steps.
A pull-only policy works well for identities that only deploy or run images, such as a CI runner that pulls a base image or a cluster node that pulls application images.
The following policy lets an identity mint pull-only credentials for every registry. To limit the identity to one registry, replace registry:* with registry:REGISTRY_ID.
A push/pull policy works well for identities that build and publish images, such as a build worker. Limiting it to one registry keeps the identity from publishing anywhere else.
The following policy lets an identity mint push and pull credentials for one registry. Replace REGISTRY_ID with your registry's id.
A single policy can grant different levels of access to different registries. The following policy grants an identity pull access to a shared base image registry and push and pull access to a build registry. Replace BASE_REGISTRY_ID and BUILD_REGISTRY_ID with your registry IDs.
When this identity mints credentials for both registries, Vultr Container Registry authorizes each registry independently. The identity receives pull-only credentials for the base registry and push/pull credentials for the build registry.
After attaching a policy, confirm the result by sending a GET request to the credential endpoint with that identity.
The response lists each registry the identity can mint credentials for, with the scope granted on it.
Use the API key of the identity you are testing, not your own.
For narrower access than pull or push and pull, use the optional scope parameter in the mint request. It takes a list of verbs, and each verb requires the corresponding IAM action on the registry.
Each verb in scope requires the corresponding IAM action on the registry. If you use verbs beyond pull and push, update the identity's policy to grant the matching actions. For example, tag:create requires container.registry.TagCreate. If the policy is missing an action for any verb, the request returns 403.
0 Comments
Be the first to comment and share your perspective with the community.