Secret resources are very similar to ConfigMap but they were introduced later, with the goal to store sensitive informations and you should consider this feature still a work in progress, at least in vanilla instance of Kubernetes. In fact at this time Kubernetes secrets are stored in plain-text, base64 encoded format.
It's important to stress the fact that Encoding is not Encryption: despite the name and the original design, Kubernetes' secrets can't be trusted to store sensitive informations without providing some kind of encryption on top of them. Some cloud providers encrypt Kubernetes secrets at the application layer, see for example GKE.
Exercise n.1: create a secret with kubectl
Same as config maps, there are several options to create a secret, for brevity
we'll pass our secret strings to
$ kubectl create secret generic my-secret --from-literal=username=superuser --from-literal=password=topsecret secret/my-secret created
You can see what's in your secret by running:
$ kubectl describe secret my-secret Name: my-secret <snuip> Data ==== username: 9 bytes password: 9 bytes
As you can see, differently from a config map we can't see the plain text version of our data
kubectl encoded the literals in base64 on the fly.
Exercise n.2: create a secret manually
If we want to manually create a secret, we have to handle encoding ourselves:
$ echo -n 'admin' | base64 YWRtaW4=
Then we can use the encoded value (e.g.) in a yaml definition like this:
apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque data: username: YWRtaW4=
And create the object:
$ cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque data: username: YWRtaW4= EOF secret/mysecret created