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=Kubernetes Security For Dummies
Implement and run secure container-based applications a whole lot easier.
Download now
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.
Kubernetes Security Best Practices [Cheat Sheet]
This 6 page cheat sheet goes beyond the basics and covers security best practices for Kubernetes pods, components, and network security.
Download Cheat Sheet
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.
