Create image pull secrets for VKE and mint short-lived Vultr Container Registry credentials at the start of a CI/CD job.
Vultr Container Registry integrates with IAM, so registry access follows least-privilege policies instead of account-wide API keys. Because Vultr Container Registry mints credentials on demand per IAM policy, the same mechanism applies to the systems that use your images most often. Vultr Kubernetes Engine clusters pull them, and CI/CD pipelines build and push them.
Follow this guide to create an image pull secret for a Vultr Kubernetes Engine (VKE) cluster, keep it up to date, and mint credentials at the start of a CI/CD job 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.
To pull private images in a VKE cluster, create an image pull secret from minted credentials, then reference it in your workload. A cluster only pulls images, so use an identity with container.registry.Pull and mint read-only credentials.
Mint read-only credentials scoped to the registry and store them as a Kubernetes secret.
Set your kubeconfig so that kubectl targets the cluster, then send a POST request to the Kubernetes-specific credential endpoint and pipe the response to kubectl. Replace REGISTRY_ID with your registry's id.
The endpoint returns raw YAML that kubectl apply accepts as input. It creates a secret named vultr-cr-credentials, valid for the expiry_seconds you set. If your pipeline expects the YAML base64-encoded, add the query parameter ?base64_encode=true to the URL.
Verify that the secret exists.
A Kubernetes secret belongs to a namespace. Apply it in the same namespace as the workloads that use it.
Add the secret to imagePullSecrets in your pod template. The following example is a patch for a Deployment.
Kubernetes then uses the credentials to pull images from your registry. The existing per-registry Kubernetes YAML generation flow, described in Generate Docker Config, also remains available.
Use a service user for each pipeline. Give it a narrow policy, such as push and pull on a single build registry, and mint short-lived credentials at the start of each job. The job logs in, builds and pushes, and the credentials expire shortly afterward.
Give the pipeline its own identity so it can mint credentials independently of any individual user.
Create a service user for the pipeline in your IAM organization. See Identity and Access Management for details.
Attach a policy that grants GetCredentials on * and Pull and Push on the build registry. Replace REGISTRY_ID with your registry's id.
Store the service user's API key in your pipeline's secret store as VULTR_API_KEY.
Add the following steps to your pipeline runner before any step that uses the registry.
Mint short-lived push credentials for the build registry. Replace REGISTRY_ID with your registry's id.
Extract the auth value for your registry host from creds.json. Replace REGISTRY_HOST with your registry host.
Decode the value.
Log in to the registry. Replace REGISTRY_HOST with the same registry host. Passing the password over stdin keeps it out of your shell history.
Remove the credentials file.
A successful login returns Login Succeeded.
0 Comments
Be the first to comment and share your perspective with the community.