What are secrets in Kubernetes & how do you use it ?

  • A Secret object in kubernetes contains sensitive data such as client secret, password, token or a key.
  • Secrets provide a way to store these sensitive informations separately from Pod definitions or container images.
  • Since these secret objects can be created independently from Pod, there is a less risk of these information being exposed during the workflow of creating, viewing, and editing Pods.
  • By default all the secrets are stored unencrypted in the API server’s underlying data store (etcd).
  • Anyone with API access or access to etcd can retrieve or modify a Secret
  • Additionally, anyone who is authorized to create a Pod in a namespace can use that access to read any Secret in that namespace; this includes indirect access such as the ability to create a Deployment.
  • Therefore , the recommended steps to safely use the secrets are
    • Enable Encryption at Rest for Secrets.
    • Enable or configure RBAC rules with least-privilege access to Secrets.
    • Restrict Secret access to specific containers.
    • Consider using external Secret store providers (AWS Secret Manager, Vault etc.)
  • Secrets in Kubernetes are, at their most basic form, a collection of keys and values.
  • Example of a secret object
apiVersion: v1
kind: Secret
metadata:
         name: redis-credsyaml
type: Opaque
data:
         password: cEBzc3cwcmQ=
         username: cmVkaXMtYWRtaW4=
  • The above yaml when applied will create a secret object with name redis-credsyaml with two secret keys: username and password.
  • The values of the username and password are encoded as base64. It is an encoding algorithm, not an encryption algorithm. This is done to help facilitate data that may not be entirely alpha-numeric, and instead could include binary data, non-ASCII data, etc
  • To create the above given secret object use the command – kubectl apply -f redis-cred.yaml
  • To use these secrets in a POD,  you can mount is as data volumes or exposed as environment variables to be used by a container in a Pod
  • Secret volume sources are validated to ensure that the specified object reference actually points to an object of type Secret. Therefore, a Secret needs to be created before any Pods that depend on it.
  • The below example , will create a Redis pod and will use the secrets created above as an environment variable
apiVersion: v1
kind: Pod
metadata:
  name: redis-k8
spec:
  containers:
  - name: redis-k8
    image: redis
    env:
      - name: SECRET_USERNAME
        valueFrom:
          secretKeyRef:
            name: redis-credsyaml
            key: username
      - name: SECRET_PASSWORD
        valueFrom:
          secretKeyRef:
            name: redis-credsyaml
            key: password
  restartPolicy: Never
  • Note, the env section in spec . it fetches the value from redis-credsyaml obejct’s username and password key.
  • Process followed in this article, can be summarized as below

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s