Secrets are stored in the only datastore a kubernetes cluster has: etcd.

As all other resources, they're retrieved when needed by the kubelet executable (that runs in every node) by querying k8s' API server

If you are wandering how to actually access the secrets (the stored files),

kubectl -n kube-system exec -it <etcd-pod-name> ls -l /etc/kubernetes/pki/etcd

You will get a list of all keys (system default keys). you can simply view them using cat command (if they are encrypted you won't see much)

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.