Skip to content

Latest commit

 

History

History
162 lines (129 loc) · 5.39 KB

File metadata and controls

162 lines (129 loc) · 5.39 KB

Secrets

In this section, we will take a look at secrets in kubernetes

Web-Mysql Application

web

  • One way is to move the app properties/envs into a configmap. But the configmap stores data into a plain text format. It is definitely not a right place to store a password.

    apiVersion: v1
    kind: ConfigMap
    metadata:
     name: app-config
    data:
      DB_Host: mysql
      DB_User: root
      DB_Password: paswrd
    

    web1

  • Secrets are used to store sensitive information. They are similar to configmaps but they are stored in an encrypted format or a hashed format.

There are 2 steps involved with secrets

  • First, Create a secret

  • Second, Inject the secret into a pod.

    sec

There are 2 ways of creating a secret

  • The Imperative way

    $ kubectl create secret generic app-secret --from-literal=DB_Host=mysql --from-literal=DB_User=root --from-literal=DB_Password=paswrd
    $ kubectl create secret generic app-secret --from-file=app_secret.properties
    

    csi

  • The Declarative way

    Generate a hash value of the password and pass it to secret-data.yaml definition value as a value to DB_Password variable.
    $ echo -n "mysql" | base64
    $ echo -n "root" | base64
    $ echo -n "paswrd"| base64
    

    Create a secret definition file and run kubectl create to deploy it

    apiVersion: v1
    kind: Secret
    metadata:
     name: app-secret
    data:
      DB_Host: bX1zcWw=
      DB_User: cm9vdA==
      DB_Password: cGFzd3Jk
    
    $ kubectl create -f secret-data.yaml
    

    csd

Encode Secrets

enc

View Secrets

  • To view secrets

    $ kubectl get secrets
    
  • To describe secret

    $ kubectl describe secret
    
  • To view the values of the secret

    $ kubectl get secret app-secret -o yaml
    

    secv

Decode Secrets

  • To decode secrets
    $ echo -n "bX1zcWw=" | base64 --decode
    $ echo -n "cm9vdA==" | base64 --decode
    $ echo -n "cGFzd3Jk" | base64 --decode
    
    secd

Configuring secret with a pod

  • To inject a secret to a pod add a new property envFrom followed by secretRef name and then create the pod-definition

    apiVersion: v1
    kind: Secret
    metadata:
     name: app-secret
    data:
      DB_Host: bX1zcWw=
      DB_User: cm9vdA==
      DB_Password: cGFzd3Jk
    
     apiVersion: v1
     kind: Pod
     metadata:
       name: simple-webapp-color
     spec:
      containers:
      - name: simple-webapp-color
        image: simple-webapp-color
        ports:
        - containerPort: 8080
        envFrom:
        - secretRef:
            name: app-secret
    
    $ kubectl create -f pod-definition.yaml
    

    secp

There are other ways to inject secrets into pods.

  • You can inject as Single ENV variable

  • You can inject as whole secret as files in a Volume

    seco

Secrets in pods as volume

  • Each attribute in the secret is created as a file with the value of the secret as its content.

    secpv

Additional Notes: A Note on Secrets

Remember that secrets encode data in base64 format. Anyone with the base64 encoded secret can easily decode it. As such the secrets can be considered not very safe.

The concept of safety of the Secrets is a bit confusing in Kubernetes. The kubernetes documentation page and a lot of blogs out there refer to secrets as a “safer option” to store sensitive data. They are safer than storing in plain text as they reduce the risk of accidentally exposing passwords and other sensitive data. In my opinion it’s not the secret itself that is safe, it is the practices around it.

Secrets are not encrypted, so it is not safer in that sense. However, some best practices around using secrets make it safer. As in best practices like:

  • Not checking-in secret object definition files to source code repositories.
  • Enabling Encryption at Rest for Secrets so they are stored encrypted in ETCD.

Also the way kubernetes handles secrets. Such as:

  • A secret is only sent to a node if a pod on that node requires it.
  • Kubelet stores the secret into a tmpfs so that the secret is not written to disk storage.
  • Once the Pod that depends on the secret is deleted, kubelet will delete its local copy of the secret data as well.

Read about the protections and risks of using secrets here

Having said that, there are other better ways of handling sensitive data like passwords in Kubernetes, such as using tools like Helm Secrets, HashiCorp Vault. I hope to make a lecture on these in the future.

K8s Reference Docs