Not really a programming question but quite curious to know how does Kubernetes or Minikube manage secrets & uses it on multiple nodes/pods?
Let's say if I create a secret to pull image with kubectl
as below -
$ kubectl create secret docker-registry regsecret --docker-server=https://index.docker.io/v1/ --docker-username=$USERNM --docker-password=$PASSWD [email protected]
What processes will occur in the backend and how will k8s or Minikube use those on multiple nodes/pods?
Kubernetes Secrets are secure objects which store sensitive data, such as passwords, OAuth tokens, and SSH keys, etc. with encryption in your clusters. Using Secrets gives you more flexibility in a Pod Life cycle definition and control over how sensitive data is used.
Kubernetes offers envelope encryption of Secrets with a KMS provider, meaning that a local key, commonly called a data encryption key (DEK), is used to encrypt the Secrets. The DEK itself is encrypted with another key called the key encryption key (KEK).
As we know containerized applications running in Kubernetes almost always need some access to external resources like secrets, passwords, keys, or tokens to gain access. Kubernetes Secrets lets you securely store these items, by removing the need to store them in pod definitions or container images.
All data in Kubernetes is managed by the API Server
component that performs CRUD operations on the data store (current only option is etcd
).
When you submit a secret
with kubectl
to the API Server
it stores the resource and data in etcd
. It is recommended to enable encryption for secrets in in the API Server (through setting the right flags) so that the data is encrypted at rest, otherwise anyone with access to etcd
will be able to read your secrets
in plain text.
When the secret
is needed for either mounting in a Pod
or in your example for pulling a Docker image from a private registry, it is requested from the API Server
by the node-local kubelet
and kept in tmpfs
so it never touches any hard disk unencrypted.
Here another security recommendation comes into play, which is called Node Authorization (again set up by setting the right flags and distributing certificates to API Server and Kubelets). With Node Authorization enabled you can make sure that a kubelet
can only request resources (incl. secrets
) that are meant to be run on that specific node, so a hacked node just exposes the resources on that single node and not everything.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With