Uncover hidden risks

Watch how the Wiz platform can expose unseen risks in your cloud environment without drowning your team in alerts.

Kubernetes secrets

A Kubernetes secret is an object in the Kubernetes ecosystem that contains sensitive information (think keys, passwords, and tokens)

6 min read

A Kubernetes secret is an object in the Kubernetes ecosystem that contains sensitive information (think keys, passwords, and tokens). Instead of including this data directly in a pod or a deployment, storing data you want to keep secure in a secret allows you to reduce your attack surface—and reduce the chance this critical information is altered during the software development life cycle. Secrets objects are a part of the Kubernetes v1 API and can be created by using the manifest below: 

apiVersion: v1

kind: Secret

metadata:

 name: file-credential

data:

 .secret-file: dmFsdWUtMg0KDQo=

Once you create a secret, you need to refer to that secret in your pod. The config file below gives your pod access to the Kubernetes secret we created in the manifest above:

apiVersion: v1


kind: Pod


metadata:


 name: secret-files-pod


spec:


 volumes:


   - name: secret-volume


     secret:


       secretName: file-secret


 containers:


   - name: dotfile-test-container


     image: registry.k8s.io/busybox


     command:


       - ls


       - "-l"


       - "/etc/secret-volume"


     volumeMounts:


       - name: secret-volume


         readOnly: true


         mountPath: "/etc/secret-volume"

In this example, your secrets file will be present in the /etc/secret-volume location in the file system for your application to access. (In the volume mount definition, you specify where the file path will be.) 

Use cases for Kubernetes secrets

Next, let’s take a look at specific scenarios where it’s best practice to leverage Kubernetes secrets:

  • Providing environment variables to containers: Some environment variables can be used to control the behavior of your application, so it’s a good idea to use secrets to provide those values. These container environment variables can also contain sensitive information like credentials, which are used to call third-party apps (for example, payment gateways). 

  • Providing credentials such as SSH keys and passwords to containers: Secrets can deliver SSH credentials, passwords, TLS certificates, and more to containers. SSH keys and TLS certificates are important security tokens that can be used in applications and via secrets delivered to them. 

  • Allowing container images to be pulled from the registry: Secrets are also used when allowing the image-pull step in nodes. You can provide Docker registry credentials in secrets, and those will be used by Kubelet to pull the container images stored in the registry. 

  • Storing extra information like Helm details: Just like Helm uses secrets, other applications can use secrets to carry out their functions.

Now let’s look at different kinds of secrets. 

Types of secrets

Based on specified secret values, secrets are divided into these types:

Opaque

Opaque secrets are generic secrets that anyone can create and use. These are basic key-value pairs and are the default type of secret, so if you don’t explicitly mention the type, an Opaque secret will be created (with opaque type defined). 

Service account tokens

These are the tokens that are used to identify the service accounts, which can be used to provide specified Kubernetes APIs with access to pods. This API uses the kubernetes.io/service-account-token type. 

SSH-auth

This type of secret is used to save data that’s used for SSH authentication purposes. SSH-auth uses the kubernetes.io/ssh-auth type.

TLS

Use these to store TLS certificates and the associated keys; kubernetes.io/tls is the type to define to leverage this form of secret.

Basic-auth

For basic authentication secrets, define the type as kubernetes.io/basic-auth.

Docker-cgf and Dockerconfigjson

Configurations related to Docker and registry secrets are generally stored in these two types of secrets. To use docker-cfg and dockerconfigjson, define the type as kubernetes.io/dockercfg or kubernetes.io/dockerconfigjson.

Token

This secrets type refers to the bootstrap tokens that are used to add new nodes to a Kubernetes cluster. To use this token in the node bootstrap process, define bootstrap.kubernetes.io/token.

Are Kubernetes secrets safe?

It’s important to remember that the way Kubernetes secrets are stored in etcd is not very secure because they aren’t encrypted. Instead, they’re stored as Base64-encoded objects. This means that if anyone gets their hands on the data, they can quickly decode the Base64 string and use all the secrets—all they need is access to see the Kubernetes secrets objects. (You can get around using Base64 by leveraging the stringData field.) Read on to learn more about how to manage secrets to prevent accidental exposure and unauthorized access. 

Configuring Kubernetes secrets to make them more secure 

Below are a few steps you can take to keep Kubernetes secrets secure: 

  • Implement role-based access control (RBAC) rules: Kubernetes has rich support for policy-based and role-based access control. You can very easily control who can access which components in Kubernetes, meaning you can restrict the usage of secrets APIs and remove access to secrets from all users. Making sure that no one can access secrets via the Kubectl command-line tool is the first step.

  • Allow only containers to access specific secrets: Just like controlling RBAC for users, you can restrict secrets access to a particular set of applications. This way, your secrets will be accessible only to applications that are authorized to use them. 

Enable encryption at rest: Encryption at rest is a feature that can be enabled on the API server using the flag --encryption-provider-config. In this flag, you’ll refer to a file that specifies the providers for which the encryption at rest will be enabled. The content of the YAML file will be something like this

apiVersion: apiserver.config.k8s.io/v1

kind: EncryptionConfiguration

resources:

 - resources:

     - events

   providers:

     - identity: {} # do not encrypt Events even though *.* is specified below

 - resources:

     - '*.apps' 

   providers:

     - aescbc:

         keys:

         - name: first_key

           secret: c2VlkansaklnsxlanslxHsa1hUndklMgaXQ/Cg==

 - resources:

     - '*.*' 
   providers:

     - aescbc:

         keys:

         - name: second_key

           secret: c2VjcmV12ds2JJklY3vyZSwgSSB0aGluaw==

If you look at this file, you’ll notice an array of resources we’re applying conditions to. The events resource has no encryption at rest because the provider identity is an empty array. Next, we’ve specified that resources under the apps API will be encrypted at rest. The last array shows that everything in Kubernetes will be encrypted. 

Tools for robust secrets management 

By following the configuration tips above, you can make sure that no unauthorized users or entities can access your secrets. However, actually delivering secrets to Kubernetes also presents security risks, which require role-based access control and other checks to mitigate. These features aren’t native to Kubernetes, but luckily, there are many effective tools to choose from. Let’s look at the third-party solutions first.

Third-party solutions

  • Vault: Vault is an industry standard and is used widely. By using the sidecar container, it provides functionalities like RBAC, auditing, secrets rotation, and a dynamic secrets engine. You can use Vault and deliver secrets to your containers without worrying about security. 

  • Secrets Manager from AWS: AWS Secrets Manager is a much more affordable solution, but it lacks many of Vault’s features, like dynamic secrets generation and an RBAC UI. That said, you can implement RBAC using AWS native IAM policies.

  • Key Vault in Azure: Key Vault is similar to AWS Secrets Manager and secures secrets, TLS certificates, SSH keys, and more. One big benefit? You can create vaults in Azure’s international data centers to keep your secrets safer and make them more efficient. 

Open-source solutions

  • Helm secrets: Helm is widely used to manage deployments in Kubernetes, and Helm secrets is an easy solution to integrate. Though it’s not as secure as a Vault, with proper privileges, Helm is a worthy open-source solution. 

  • Open-source Vault: Vault has an open-source distribution in addition to the paid version we’ve already discussed. You can deploy the open-source version of Vault in your Kubernetes clusters or on a native VM and utilize it to push secrets to your containers. This version of Vault provides almost all of the features of the upgraded version except for backup and restore.

Conclusion

Kubernetes secrets have some security gaps, but these can be handled by following the principle of least privilege and implementing encryption at rest. Auditing is also a key means of limiting your attack surface, and all the tools mentioned above have one or more ways to produce audit logs. 

On the other hand, it can be tricky to keep track of all of the essential data from these disparate logs. Enter Wiz. With our all-in-one platform, you get complete visibility across containers, Kubernetes, and cloud environments in minutes without agents, and you can leverage the power of the Wiz Security Graph to analyze and prioritize risk with complete context.  Ready to secure everything you build and run in the cloud? Schedule a free demo of Wiz today.

Empower your developers to be more productive, from code to production

Learn why the fastest growing companies choose Wiz to secure containers, Kubernetes, and cloud environments from build-time to real-time.

Get a demo

Continue reading

Azure Security Risks & Mitigation Steps

Wiz Experts Team

This article offers an extensive examination of Azure environments’ most pressing security risks along with suggested approaches for effectively mitigating these challenges.

Remote Code Execution Attacks Explained

Wiz Experts Team

Remote code execution refers to a security vulnerability through which malicious actors can remotely run code on your systems or servers.

Cloud Sprawl Explained

Wiz Experts Team

Cloud sprawl is a phenomenon that involves the unmanaged growth of cloud-based resources and services.

CSPM vs DSPM: Why You Need Both

Wiz Experts Team

Discover the similarities between CSPM and DSPM, what factors set them apart, and which one is the best choice for your organization’s needs.

Container monitoring explained

Container monitoring is the process of collecting, analyzing, and reporting metrics and data related to the performance and health of containerized applications and their hosting environments.

Data Exfiltration Explained

Wiz Experts Team

Data exfiltration is when sensitive data is accessed without authorization or stolen. Just like any data breach, it can lead to financial loss, reputational damage, and business disruptions.