Baeldung Pro – Ops – NPI EA (cat = Baeldung on Ops)
announcement - icon

Learn through the super-clean Baeldung Pro experience:

>> Membership and Baeldung Pro.

No ads, dark-mode and 6 months free of IntelliJ Idea Ultimate to start with.

Partner – Orkes – NPI EA (cat=Kubernetes)
announcement - icon

Modern software architecture is often broken. Slow delivery leads to missed opportunities, innovation is stalled due to architectural complexities, and engineering resources are exceedingly expensive.

Orkes is the leading workflow orchestration platform built to enable teams to transform the way they develop, connect, and deploy applications, microservices, AI agents, and more.

With Orkes Conductor managed through Orkes Cloud, developers can focus on building mission critical applications without worrying about infrastructure maintenance to meet goals and, simply put, taking new products live faster and reducing total cost of ownership.

Try a 14-Day Free Trial of Orkes Conductor today.

1. Overview

Pulling Docker images from a private registry in Kubernetes requires a proper authentication setup. Private registries offer enhanced security by controlling who can access the Docker images. In Kubernetes, this involves creating a Docker Registry Secret and configuring Pods to use it.

In this tutorial, we’ll provide a step-by-step approach to configuring Kubernetes to pull images from a private Docker registry securely. This approach will ensure that the cluster is properly set up to authenticate and access private images, enhancing security and efficiency.

2. Prerequisites

Before we begin, it’s essential to ensure we have the proper setup:

3. Generating a Docker Registry Secret

Kubernetes manages sensitive information, such as Docker registry credentials, through Secrets. These Secrets authenticate with the private registry when pulling images. Let’s explore the two methods for creating and configuring a Docker registry Secret.

3.1. Generate a Secret from Existing Credentials

If Docker login has already been executed, it’s possible to directly copy the credentials into Kubernetes. In this scenario, since the Docker registry credentials are already stored in the ~/.docker/config.json file, a Kubernetes Secret can be easily created from this file:

$ kubectl create secret generic <secret-name> --from-file=.dockerconfigjson=~/.docker/config.json --type=kubernetes.io/dockerconfigjson --namespace=<namespace>

This command creates a Kubernetes Secret using the existing Docker credentials from ~/.docker/config.json. It then directly applies the Secret to the specified namespace. This approach is particularly convenient, as it leverages the existing configuration and eliminates the need to manually enter credentials.

3.2. Generate a Secret by Entering Credentials via the Command Line

Alternatively, we can enter credentials manually using the command line. This method is useful for initial setup or when credentials are not stored in ~/.docker/config.json:

$ kubectl create secret docker-registry <secret-name> --docker-server=<registry-server> --docker-username=<username> --docker-password=<password> --docker-email=<email> --namespace=<namespace>

Typing secrets directly into the command line presents security risks because they can be stored unprotected in the shell history. Additionally, other users on the system might see these secrets while the kubectl command is executing.

4. Configuring Pods to Use the Secret

Once we have created the Docker Registry Secret, it’s necessary to configure the Pods to use this Secret for image pulls. Kubernetes offers two main methods for linking the Secret to the Pods.

4.1.  Using imagePullSecrets Directly in the Container Spec

The simplest way to configure Pods is by specifying the Secret in the imagePullSecrets field within the Pod specification.

Here’s an example YAML configuration:

apiVersion: v1
kind: Pod
metadata:
  namespace: <namespace>
  name: <pod_name>
spec:
  containers:
  - name: <container_name>
    image: <registry-server>/<image-name>:<tag>
  imagePullSecrets:
  - name: <secret-name>

The imagePullSecrets field tells Kubernetes to use the specified Secret when pulling images for the container.

4.2. Using a Service Account

For a more scalable solution, especially when multiple Pods need access to the private registry, we can link the Secret to a Service Account. This way, any Pod using the Service Account will inherit the registry access permissions. This method scales better and is easier to manage in larger environments.

First, we create a Service Account and associate it with the Secret:

$ kubectl create serviceaccount <sa-name> -n <namespace>

Next, we associate it with the Secret using the following command:

$ kubectl patch serviceaccount <sa-name> -p '{"secrets":[{"name":"<secret-name>"}]}' -n <namespace>

By linking the Service Account to the Secret, we allow all Pods using this account to pull images from the private registry automatically.

Finally, we create a Pod configuration, for example, pod.yaml, to use the Service Account:

apiVersion: v1
kind: Pod
metadata:
  namespace: <namespace>
  name: <pod-name>
spec:
  serviceAccountName: <sa-name>
  containers:
  - name: <conatainer-name>
    image: <registry-server>/<image-name>:<tag>

 5. Deployment and Verification

After setting up the Secret and configuring the Pods, we can deploy the configuration to Kubernetes using the following command:

$ kubectl apply -f pod.yaml

To confirm that the Pod successfully pulls the image from the private registry, we can examine the Pod’s events by running the following command:

$ kubectl describe pod <pod-name>

We can check for events related to image pulling. If no errors appear, the Pod will likely use the images from the private registry as intended.

6. Conclusion

In this article, Pulling Images from a Private Registry in Kubernetes involves creating a Docker Registry Secret and configuring Pods to use it.

This setup ensures secure access to images and enhances container management. Utilizing imagePullSecrets or a Service Account provides flexibility for different deployment needs.