Skip to main content

K8s Secrets Explained.

 What is Secrets in K8s?

Secrets are used to store sensitive information like Authentication Token, Passwords, SSH Keys and  Certificates.

It is stored in etcd, datastore of k8s.

The main advantage of the secret is that it can be updated dynamically , so if we want to change the username or password or ssh key of any of the containers inside the pod, then just changing the secret will dynamically update the existing and newely created POD's env values and ssh-key (mount as volume) .

jinojosep@cloudshell:~ (boreal-physics-256910)$ kubectl create secret generic secret-demo --from-literal=username=jinouname --from-literal=password=jinomypassword

secret/secret-demo created

################################

jinojosep@cloudshell:~ (boreal-physics-256910)$ kg secret

NAME                  TYPE                                  DATA   AGE

default-token-l5tmg   kubernetes.io/service-account-token   3      14m

secret-demo           Opaque                                2      8s

################################

jinojosep@cloudshell:~ (boreal-physics-256910)$ cat > 5-pod-secret-env.yaml

apiVersion: v1

kind: Pod

metadata:

  name: busybox

spec:

  containers:

  - image: busybox

    name: busybox

    command: ["/bin/sh"]

    args: ["-c", "sleep 600"]

    env:

    - name: myusername

      valueFrom:

        secretKeyRef:

          name: secret-demo

          key: username

################################

In normal case we there will be a "value: " parameter below the env: > -name : paramter. We need to replace the value: with the valueFrom: > secretKeyRef: >  name: > and key: fields.

Here key: username is the value that we added as data: when creating the secret .

  ################################

jinojosep@cloudshell:~ (boreal-physics-256910)$ k create -f 5-pod-secret-env.yaml

pod/busybox created

################################

jinojosep@cloudshell:~ (boreal-physics-256910)$ kg pods

NAME      READY   STATUS    RESTARTS   AGE

busybox   1/1     Running   0          4s

################################

jinojosep@cloudshell:~ (boreal-physics-256910)$ k exec -it busybox -- sh

/ # env

/ # env | grep myusername

myusername=jinouname

################################

This is an example where secret is mounted as files to a volume which is perfect for the ssh keys 

jinojosep@cloudshell:~ (boreal-physics-256910)$ cat > 5-pod-secretsshkey.yaml

kind: Secret

apiVersion: v1

metadata:

  name: ssh-key-secret

data:

  id-rsa: dmFsdWUtMg0KDQo=

  id-rsa.pub: dmFsdWUtMQ0K

################################

jinojosep@cloudshell:~ (boreal-physics-256910)$ cat > 5-pod-secret-volume.yaml

kind: Pod

apiVersion: v1

metadata:

  name: secret-test-pod

spec:

  volumes:

  - name: secret-volume

    secret:

      secretName: ssh-key-secret

  containers:

  - name: ssh-test-container

    image: busybox

    command: ["/bin/sh"]

    args: ["-c", "sleep 600"]

    volumeMounts:

    - name: secret-volume

      readOnly: true

      mountPath: "/etc/secret-volume"      

################################

Here the volumes: > name: and the volumeMounts: > name: should be same.

 

jinojosep@cloudshell:~ (boreal-physics-256910)$ k apply -f 5-pod-secret-volume.yaml

pod/busybox created

################################

jinojosep@cloudshell:~ (boreal-physics-256910)$ kg pod

NAME      READY   STATUS    RESTARTS   AGE

busybox   1/1     Running   0          15s

################################

jinojosep@cloudshell:~ (boreal-physics-256910)$ k exec -it busybox -- sh

/ # cd /etc/secret-volume

/secret-volume # ls -l

total 0

lrwxrwxrwx    1 root     root            15 Aug 11 11:44 id-rsa -> ..data/id-rsa

lrwxrwxrwx    1 root     root            15 Aug 11 11:44 id-rsa.pub -> ..data/id-rsa.pub

/secret-volume # cat id-rsa ; echo

dmFsdWUtMg0KDQo=

/secret-volume # cat id-rsa.pub ; echo

dmFsdWUtMQ0K

/secret-volume #

Comments

Popular posts from this blog

Password reset too simplistic/systematic issue

Some time when we try to reset the password of our user in linux it will show as simple and systematic as below: BAD PASSWORD: it is too simplistic/systematic no matter how hard password you give it will show the same. Solution: ######### Check if your password is Ok with the below command, jino@ndz~$ echo 'D7y8HK#56r89lj&8*&^%&^%#56rlKJ!789l' | cracklib-check D7y8HK#56r89lj&8*&^%&^%#56rlKJ!789l: it is too simplistic/systematic Now Create a password with the below command : jino@ndz~$ echo $(tr -dc '[:graph:]' 7\xi%!W[y*S}g-H7W~gbEB4cv,9:E:K; You can see that this password will be ok with the cracklib-check. jino@ndz~$ echo '7\xi%!W[y*S}g-H7W~gbEB4cv,9:E:K;' | cracklib-check                 7\xi%!W[y*S}g-H7W~gbEB4cv,9:E:K;: OK Thats all, Thanks.

K8s External Secrets integration between AWS EKS and Secrets Manager(SM) using IAM Role.

What is K8s External Secrets and how it will make your life easier? Before saying about External Secrets we will say about k8s secrets and how it will work. In k8s secrets we will create key value pairs of the secrets and set this as either pod env variables or mount them as volumes to pods. For more details about k8s secrets you can check my blog http://jinojoseph.blogspot.com/2020/08/k8s-secrets-explained.html   So in this case if developers wants to change the ENV variables , then we have to edit the k8s manifest yaml file, then we have to apply the new files to the deployment. This is a tiresome process and also chances of applying to the wrong context is high if you have multiple k8s clusters for dev / stage and Prod deployments. So in-order to make this easy , we can add all the secrets that is needed in the deployment, in the AWS Secret Manager and with the help of External secrets we can fetch and create those secrets in the k8s cluster. So what is K8s external Secret? It is an

Setting /etc/hosts entries during the initial deployment of an Application using k8s yaml file

Some times we have to enter specific hosts file entries to the container running inside the POD of a kubernetes deployment during the initial deployment stage itself. If these entries are not in place, the application env variables mentioned in the yaml file , as hostnames , will not resolve to the IP address and the application will not start properly. So to make sure the /etc/hosts file entries are already there after the spin up of the POD you can add the below entries in your yaml file. cat > api-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: spec:   template:     metadata:     spec:       volumes:       containers:       - image: registryserver.jinojoseph.com:5000/jinojosephimage:v1.13         lifecycle:           postStart:             exec:               command: ["/bin/sh", "-c", "echo 10.0.1.10 namenode.jinojoseph.com >> /etc/hosts && echo 10.0.1.8 dn1.jinojoseph.com >> /etc/hosts &&