Skip to main content
In this lesson we cover how container image names work, how to use secure/private registries, and how to configure Kubernetes pods to pull images that require authentication.
A presentation slide titled "Image Security" with a dark-blue curved panel on the right containing an icon of a photo and a shield with a checkmark. The lower-left corner shows a small "© Copyright KodeKloud" notice.

​
Image name format (Docker/OCI naming convention)

Container image names follow the general pattern: [registry-host[:port]/][namespace/]repository[:tag] Breakdown: Examples:
  • nginx
    Equivalent to docker.io/library/nginx:latest
  • myorg/webapp:1.0
    Pulls webapp from docker.io/myorg with tag 1.0
  • gcr.io/my-project/my-image:stable
    Pulls from Google Container Registry
Why this matters: omitting parts of the name triggers defaults (Docker Hub + library namespace + latest tag), so being explicit improves reproducibility and security.

​
Common registries

Public registries provide easy access, but for proprietary or internal images prefer a private registry with access control.

​
Pulling private images with Docker (local)

Before running an image from a private registry with Docker locally, authenticate:
This stores credentials in your local Docker config so the Docker client can authenticate when pulling.

​
Kubernetes: pulling images from a private registry

The kubelet running on worker nodes must authenticate to the registry to pull private images. Kubernetes supports this via a secret of type kubernetes.io/dockerconfigjson (created with kubectl create secret docker-registry) and referencing that secret from Pod specs using imagePullSecrets. Create the registry secret (replace server/username/password/email with real values):
Reference that secret from a Pod manifest:
When Kubernetes creates this Pod, the kubelet on the node will use the credentials in regcred to authenticate to private-registry.io and pull the specified image.
Make sure the docker-registry secret exists in the same namespace as the Pod. If you don’t create the secret in the Pod’s namespace, Kubernetes cannot find it to use for image pulls.

​
Best practices for image security

  • Use explicit fully qualified image names (registry + namespace + tag or digest) to avoid unintended pulls from public registries.
  • Prefer immutable references (image digests, e.g. @sha256:...) for production to ensure exact image content.
  • Restrict registry access using strong credentials or IAM-based authentication (e.g., AWS IAM for ECR, GCP IAM for GCR).
  • Scan images for vulnerabilities before deploying (CI/CD integration).
  • Keep secrets scoped to the namespace that needs them and follow least privilege.

​
References and further reading

That concludes this lesson. Practice exercises are available to reinforce these concepts.

Watch Video

Practice Lab