The Secret: Kubernetes Edition
September 09, 2019

Ranny Nachmias
Alcide

So you think your K8s cluster is configured correctly?

Well … think again.

How do we know? Alcide just completed an analysis of Kubernetes multi-cluster vulnerabilities, and the results are not good. It turns out that in 89% of deployments, companies are not using Kubernetes' Secrets resources, with sensitive information wired in the open. Moreover, 75% of the deployments studied use workloads which mount high-vulnerability host file systems such as /proc and none of the deployments showed segmentation implementation using Kubernetes' network policies.

Secrets are a crucial functionality in Kubernetes that everyone should be using, so it's disheartening to learn that so many aren't taking advantage of the security benefits Secrets provide, and leaving themselves unnecessarily vulnerable.

Why You Need to be Using Secrets

Kubernetes users and/or administrators sometimes include sensitive information, such as usernames, passwords, and SSH keys, in their pods. But when credentials that grant access to systems that are critical to business functions (databases, web hosting accounts, encrypted email, various applications, etc.) are inserted verbatim into pod specs or container images, there is a very real risk of security breaches if anyone manages to hack into your code.

Secrets are essentially API objects that encode sensitive data, then expose it to your pods in a controlled way. This enables encapsulating Secrets by specific containers, or sharing them. A Secret stores the information and cloaks it from the pod so that it is black-boxed; all the pod knows is that it has permission to use this Secret, but it can't see the information contained within (and neither can anyone who hacks into your code).

How Secrets Work in Kubernetes Deployments

There are two ways in which a Secret can be used with a pod: as files in a volume mounted on one or more of its containers, or as environment variables. Pods do not have access to each other's Secrets, which further facilitates encapsulating sensitive data across multiple pods. Secrets are stored in tmpfs — not written to disk — and they are only sent to nodes that need them. When the pod containing the Secret is deleted, the Secret is deleted too. SSL/TLS protects communication between users and the API server. Containers in pods must request a Secret volume in its volumeMounts in order for it to be visible in the container. This enables constructing security partitions at the pod level.

How to Make Sure You're Using Secrets

Hopefully you're going to use Secrets from now on. The best way to ensure you're using Secrets the right way is to use a monitoring tool that can not only assess if Secrets are being used, but can also detect where sensitive information is exposed or not secured and needs to be using Secrets. You should know what workloads are allowed to access and communicate with what data. If communication between apps deviates outside their prescribed lines, those deviations should be flagged for DevOps and security teams to investigate. 

As new, data-intensive systems are spun up to keep pace with business needs, maintaining security should be a top concern for everyone. Gartner's report on cloud security asserts that through 2022, 95% of security failures will be the result of unintentional errors on the customer's part. 

In other words, if you're not using Secrets and your data gets compromised, you have no one to blame but yourself.

Ranny Nachmias is CEO and Co-Founder of Alcide
Share this

Industry News

November 21, 2019

PASS, the global community of data professionals, has become one of the first major users of a new solution from Redgate that automatically discovers and classifies sensitive data in SQL Server.

November 21, 2019

OutSystems has embedded AI and machine learning in its software to make building applications even easier and faster for everyone.

November 21, 2019

Fugue announced Fugue Developer, a free tier that puts engineers in command of cloud security through the entire software development lifecycle (SDLC).

November 20, 2019

JFrog announced the launch of JFrog Container Registry - powered by JFrog Artifactory - as an advanced Docker container registry.

November 20, 2019

CloudBees introduced a graphical user interface (GUI) for Jenkins X.

November 20, 2019

Portworx announced an update to Portworx Enterprise, its container-native storage platform, to enable companies to run, scale, backup, and recover mission-critical applications on Kubernetes: PX-Backup and PX-Autopilot for Capacity Management.

November 19, 2019

Parasoft announced complete support for the newly updated 2019 Common Weakness Enumeration (CWE) Top 25 and "On the Cusp" (an additional 15 weaknesses) for C, C++, Java, and .NET languages.

November 19, 2019

Red Hat announced the release of Red Hat CodeReady Workspaces 2, a cloud-native development workflow for developers.

November 19, 2019

Postman has introduced Postman Visualizer, a two-fold feature that offers benefits for both API consumers and API developers.

November 18, 2019

Hewlett Packard Enterprise (HPE) announced the HPE Container Platform, an enterprise-grade Kubernetes-based container platform designed for both cloud-native applications and monolithic applications with persistent storage.

November 18, 2019

Lacework announced its integration with Datadog, a monitoring and analytics platform.

November 18, 2019

Codefresh is introducing a live CI/CD debugging tool.

November 14, 2019

Raytheon Company is collaborating with Red Hat to develop a new, security-focused software development solution, known as DevSecOps, for enterprise environments.

November 14, 2019

Fugue has open sourced the Fugue Rego Toolkit (Fregot) to enhance the experience working with the Rego policy language.

November 14, 2019

Sysdig announced Sysdig Secure 3.0 to provide enterprises with threat prevention at runtime using Kubernetes-native Pod Security Policies (PSP).