In this lecture we will talk about securing images.
We will start with the basics of image names and then work our way towards secure image repositories
and how to configure your pods to use images from secure repositories we deployed a number of different
kinds of pods hosting different kinds of applications throughout this course like web apps and databases
and redis cache etc.
Let's start with a simple pod definition file.
Here we have used the nginx image to deploy an nginx container.
Let's take a closer look at this image.
The name is nginx. But what is this image and where is this image pulled from? This name follows
Docker’s image naming convention. NGINX
Here is the image or the repository name.
When you say nginx, its actually nginx/nginx.
The first part stands for the user or account name.
Like if you created an account on Docker Hub yourself then the user account that you would get is the
first part if you don't provide an account name here it assumes it to be the same as the repository
name.
Which in this case is nginx if you were to create your own account and create your own repositories
or images under it then you would use a similar pattern now where are these images stored and pulled
from since we have not specified the location where these images are to be pulled from.
it is assumed to be on docker’s default registry – dockerhub. The dns name for which is docker.io.
The registry is where all the images are stored whenever you create a new image or update an existing
image you push it to the registry and every time anyone deploys this application it is pulled from that
registry.
There are many other popular registries as well.
Google’s registry is at gcr.io, where a lot of Kubernetes related images are stored.
These are all publicly accessible images that anyone can download and access when you have applications
built in-house that shouldn’t be made available to the public,
Hosting an internal private registry may be a good solution.
Many cloud service providers such as AWS, Azure or GCP provide a private regist for your cloud account
by default. On any of these solutions
be it on Docker hub or googles registry, or your internal private registry,
You may choose to make a repository private so that it can be accessed using a set of credentials from
a Docker perspective to run a container using a private image, you first login to your private-registry
Using the docker log in command input your credentials one successful run the application using the
image from the private registry
Going back to our pod definition file, to use an image from our private registry
We replace the image name with the full path to the one in the private registry.
But how do we implement the authentication log in part.
How does Kubernetes get the credentials to access the private registry within kubernetes
We know that the images are pulled and run by the docker runtime on the worker node.
How do you pass the credentials to the docker untamed on the worker node for that
We first create a secret object with the credentials in it.
The secret is of type Docker registry and we name it Regcred Docker registry is a built in secret
type that was built for storing Docker credentials.
We then specify the registry server name the user name to access the registry the password and the email
address of the user.
We then specify the secret inside our pod definition file under the image Pull secret section when
the pod created kubernetes or the kubelets on the worker node uses the credentials from the secret
to pull images well that's it for this lecture.
Head over to the practice exercises section and practice working with secure images.