Kubernetes – Secrets

Kubernetes is an open-source container orchestration system mainly used for automated software deployment, management, and scaling. Kubernetes is also known as K8s. Kubernetes was originally developed by Google but it is now being maintained by Cloud Native Computing Foundation. It was originally designed to be interfaced with only Docker runtime but it now works with containers and CRI-O also. The main purpose of Kubernetes is to automate the operational tasks of container management. It is included with built-in commands for the deployment of applications and rolling out the required changes in the application. It is currently being used by companies like Google, Spotify, and capital one.

A secret in Kubernetes can be defined as an object that contains a small quantity of sensitive data like a password, a token, or a key. It contains information that is otherwise stored in a container image or pod specification. The main advantage of a secret is that we will not have to include sensitive or confidential data in the application code. There is less risk of losing or exposing secrete during the workflow of creating viewing, and editing Pods because they can be and are created independently of the pods in which they are being used. Secretes can be considered similar to ConfigMaps but the main difference between them is that they are specially designed to store and hold confidential data.

The following are the uses of Kubernetes Secrets:

• Secrets can be used as a container environment variable.
• As a file in a volume mounted on at least one of its containers.
• It can be used by Kubelet when pulling images from the pod.
• Secretes are also used by the Kubernetes control plane.

• Secretes can be exposed as environment variables to be used by a container in a Pod or can be mounted as data volumes. It can even be used directly by other parts of the system without being directly exposed to the pods. If we consider an example a secret can store credentials that other parts of the system should use to interact with the external systems at the pace ourselves.
• The secret volume sources are validated to ensure that the specific object’s reference actually points to an object of a particular object of secret type. Due to this, the secrete should be created before any pods that depend on it.  If the required secrete cannot be fetched due to its non-existence or due to the temporary lack of connection to the AOI server the kubelet periodically retires running that specific Pod. Kubelet also reports the event for that Pod including all the details of the problems fetching the secret.  
• When we are defining a container environment variable based on a Secret we can make it optional. The default setting is that a secrete is required. None of the Pod Containers will start working until all the non-optional Secrete are available. That means if a pod references a specific key in a Secrete and it exists but it is missing the name key then the pod fails startup.  

For increasing the confidentiality of our data we can use dotfiles within the kubernetes secrets. Here the dotfiles are the hidden files that begin filename with ( . ) Ex: .api_key1 , .api_key2. By using these files inside the secrets we can store our sensitive keys and information safely. The following yaml code illustrates clearly.

In this example, the dotfiles .api_key1 and .api_key2 stores the sensitive API keys within api-keys-secret secret. These keys remains hidden and secured when mounted with api-keys-container ensuring only authorized processes can access them.

apiVersion: v1
kind: Secret
metadata:
  name: api-keys-secrets
type: Opaque
data:
  api_key1: YWJjZGVmZw==
  api_key2: ZGVmZ2hpamtsbQ==
---
apiVersion: v1
kind: Pod
metadata:
  name: api-keys-pod
spec:
  volumes:
  - name: secret-volume
    secret:
      secretName: api-keys-secrets
  containers:
  - name: api-keys-container
    image: registry.k8s.io/busybox
    command:
    - ls
    - "-la"
    - "/etc/secret-volume"
    volumeMounts:
    - name: secret-volume
      readOnly: true
      mountPath: "/etc/secret-volume"

We can enhance the security for the senstive information within a pod by making it visible to only one container that is needed. For example take this secenario they are front and backend applications, front end application container is responsible for user interaction and complex business logic. Other backend application container will handle the message signing responsibility using private key that is stored securely in kubernetes secrets. Here the front end application doesn’t have expose to view the private key and see the sensitive data. The following yaml code illustrates it clearly.

apiVersion: v1
kind: Secret
metadata:
  name: signing-secret
data:
  .private-key: cGFzc3dvcmQ=
---
apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  containers:
    - name: frontend-container
      image: myregistry.io/frontend-app
      # Configuration for frontend container...

    - name: signer-container
      image: myregistry.io/signer-app
      command:
        - ls
        - "-la"
        - "/etc/signing"
      volumeMounts:
        - name: signing-volume
          readOnly: true
          mountPath: "/etc/signing"

  volumes:
    - name: signing-volume
      secret:
        secretName: signing-secret

The following are the types of kubernetes Secrets and Its Usage inshort:

1. Opaque Secrets

• These are the default secret types i.e., if don’t specify any type while creating, this Opaque secrets type is used default. It is used for storing general user-defined data values. We have to generic as subcommand to use this type, if want to specify. The following is an empty
• Example: Used for storing API keys or database passwords
• The following command creates a empty secret type Opaque:

kubect create secret generic mysecret

2. ServiceAccount Token Secrets

• This type of secret type is used to identify the serviceAccount It is used for storing credentials that are used by pods to authenitcate with the kubernetes API Server.
• Example: Used for storing Access Tokens for communicating with kubernetes resources.
• The following yaml code illustrates it clearly:

apiVersion: v1
kind: Secret
metadata:
  name: sa-token-secret
  annotations:
    kubernetes.io/service-account.name: "sa-name"
type: kubernetes.io/service-account-token
data:
  token: <base64-encoded-token>

3.Docker Config Secrets

• It used for serializing the docker configuration files that are used for authenticating with docker registries.
• Example: Used for storing credentials for accessing private docker repositories.
• The following yaml code helps in you better understanding of docker config secrets:

apiVersion: v1
kind: Secret
metadata:
  name: docker-config-secret
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: <base64-encoded-config-json>

4. Basic Authentication Secrets

• It is used for storing credentials of basic HTTP authentication. The following yaml code illustrates you clearly about creating basic Authentication secrets types with yaml code:
• Example: It is used for storing Username and Password for accesing a web service.

apiVersion: v1
kind: Secret
metadata:
  name: ssh-auth-secret
type: kubernetes.io/ssh-auth
data:
  ssh-privatekey: UG91cmluZzYlRW1vdGljb24lU2N1YmE= # base64 encoded private key

5. SSH Authentication Secrets

• It is used for storing credentials for SSH Authentication.The following yaml code helps you in better understanding the ssh Authentication secrets creation.
• Example: Used for storing Username and passwords for accessing a web service.

apiVersion: v1
kind: Secret
metadata:
  name: ssh-auth-secret
type: kubernetes.io/ssh-auth
data:
  ssh-privatekey: UG91cmluZzYlRW1vdGljb24lU2N1YmE= # base64 encoded private key 

6. TLS Secrets

• It is used for storing data that is used for TLS encryption and decryption. The following yaml code helps you in better understanding of creating TLS secrets type:
• Example: Stores TLS certificates and keys for securing communication between services.

apiVersion: v1
kind: Secret
metadata:
  name: tls-secret
type: kubernetes.io/tls
data:
  tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNVakNDQWJzQ0FnMytNQTBHQ1NxR1NJYjNE
    # base64 encoded certificate
  tls.key: RXhhbXBsZSBkYXRhIGZvciB0aGUgVExTIGNydCBmaWVsZA== # base64 encoded private key

7. BootStrap Token Secrets

• This secret type is used for storing tokens that are used during the node bootstrap process to sign. The following yaml code helps in understanding and creating the bootstrap token secrets:

apiVersion: v1
kind: Secret
metadata:
  name: tls-secret
type: kubernetes.io/tls
data:
  tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNVakNDQWJzQ0FnMytNQTBHQ1NxR1NJYjNE
    # base64 encoded certificate
  tls.key: RXhhbXBsZSBkYXRhIGZvciB0aGUgVExTIGNydCBmaWVsZA== # base64 encoded private key

When we working with kubernetes, the management of passwords, tokens and certificaties are important. Kubernetes comes up with multi mode of solutions for securly store and access the data. Here, lets discuss the 3 general methods for creating kubernetes secrets.

1. Create kubernetes secrets using kubectl

2. Create kubernetes secrets using A manifest file

3. Create kubernetes secrets using A Generator like Kustomize

• It is a quick and straightforward way of creating kubernetes secrets from command line. It is suitable for creating secrets on the fly during development or testing phases.
• In this secrets creation, it supports accessing data from literals, files offering flexibility of handling sensitive data. The following command is used for creating secrets with string literals:

kubectl create secret generic my-secret --from-literal=username=admin --from-literal=password=secretpassword

• The following command is used for creating secrets from one or more files:

kubectl create secret generic my-secret --from-file=ssh-privatekey=~/.ssh/id_rsa

• It comes with facilitating a declarative way of defining secrets using YAML or JSON manifest files. It facilitates with easy sharing and replication of secrets configurations on different environments.
• The following is the simple Yaml file for creating kubernetes secrets.

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  username: YWRtaW4= # base64 encoded username
  password: cGFzc3dvcmQ= # base64 encoded password

• After the saving the above file code as mysecret-file.yaml execute the file and create secrets using following command:

kubectl apply -f mysecret-file.yaml

• This type of method supports seamless integration with Kustomize ( a K8s native configuration management tool ). It facilitates with generating and customizing secrets dynamically based on overlays or patches.
• It offers enhanced flexibility and scalability for managing complex secret configurations across mutliple developments.

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  api-key: <base64-encoded-api-key>

• After saving the above code file as base-secret.yaml and then execute it with following command:

kustomize build overlays/ | kubectl apply -f -

The following are the differences between Kubernetes Secrets and Kubernetes Configmap:

The following are the difference between Kubernetes Secrets and Vault:

Management of kubernetes secrets involves steps for securly handing sensitive data within the kubernetes cluster. Some of the managing kubernetes secrets are discussed as follows:

• Creation: On using kubectl commands create secrets for storing sentive data such as passwords, tokens or certificates.
• Access Control: Implement Role Based Access Control ( RBAC ) to restrict the access of secrets based on users.
• Encryption: Consider on using external solutions like Hashicorp Vault for enhancing security of secret data at rest and in transist.
• Rotation: Regularly rotating the secrets helps in minimizing the risk of unauthorization and maintaining the security policies.

To know more about this, refer this – Article

On using Kubernetes secrets as files we can provide a convenient way of securly accessing sensitive data within pods. The following are some of the uses of kubernetes secrets as files in containers:

• Mounting Secrets: Mount the secrets as volumes or individual files in a pod containers using volume mounts or environment variables.
• Files Access: Try on accessing the secret data within containers as files from specific directories or as environment variables.
• Security: Ensure to maintain proper permissions and access controls that are configured to restrict access of secret files within containers.
• Integration: The seamless integration of secret files into the application workflows facilitates secure retrival and utilization of sensitive information during runtime.

To know more about this, refer this – Article

Working with kubernetes involves better understanding of its core concepts and effective management of resources within the cluster. The following are some of the points suggested for working with kubernetes:

• Resource Management: We can deploy and manage the resources such as Pods, deployments, services and other resources using declarative YAML manifests or using imperative kubectl commands.
• Scaling: The scaling of applications horizantally or vertically to meet the changes as per demand can be done using k8s scaling features such asHorizontal Pod Autoscaler (HPA) or Vertical Pod Autoscaler ( VPA ).
• Monitoring: On monitoring the resource utilization, cluster health and application performance with the help of bult-in kubernetes monitoring tools or third party solutions.
• Maintenance: Try on performing routine maintenance tasks such as upgrades, patches and backups for ensuring stability, reliability of kubernetes cluster.

To know more about this, refer this – Article

If there is a need to protect your data then Secrete is not the only option available. There are some other alternatives available.

• We can use ServiceAccount and its tokens to identify the cluster if the cloud native component has the need for authentication to another application that is also running within the same Kubernetes Cluster.
• We can use third-party tools that can be run by us either outside or from within the cluster that provides secrets management. 
• If we need authentication we can implement a custom signer for X.509 certificates and then use CertificateSigningRequests to let that custom signer issue certificates to Pods that required them.
• We can use a device plugin to expose node local encryption hardware to a specific Pod.

There is no compulsion to use only services or one of these options. We can even combine two or more options based on our requirements. 

Does Kubernetes encrypt Secrets?

Kubernetes by default hasn’t encrypt secrets. They just encoded into base64 and stored in etcd data store. For enhanced security providing encryption try on using external solutions like HashiCorp Vault.

Why to use Secrets In Kubernetes?

Secrets in kubernetes are used for storing senstive information such as password, tokens and certifications for providing data integrity and confidentiality.

What is an example of a Secret?

The example of secret in kubernetes could be a database password, an API token or a TLS certificate. These are used for securely communicating between services.

What Is Etcd In Kubernetes?

etcd is a distributed key value storing database kind of software that is in kubernetes cluster. It stores the information such as configuration settings, secrets and metadata about pods, services and other objects.

Can I edit A Secret In Kubernetes?

Yes, you can edit a secret in kubernetes using the command `kubectl edit secret <secret_name>` or by modying the secret manefist file and then applying the changes using kubectl aply -f <manefist_file>