Jump right into Kubernetes development with career-focused lessons and hands-on practice.

DevOps for Developers

Kubernetes is a powerful container management tool that's taking the world by storm. This detailed course will help you master it.

In this course, you'll start with the fundamentals of Kubernetes and what the main components of a cluster look like. You'll then learn how to use those components to build, test, deploy, and upgrade applications, as well as how to achieve state persistence once your application is deployed. You'll also learn how to secure your deployments and manage resources, which are crucial DevOps skills.

By the time you're done, you'll have a firm grasp on what Kubernetes is, as well as the skills to deploy your own clusters and applications with confidence.

A Practical Guide to Kubernetes

# Insecure configurations

Almost everything Kubernetes needs is stored in [etcd](https://github.com/coreos/etcd). This includes Secrets. The problem is that they are stored as plain text. Anyone with access to etcd has access to Kubernetes Secrets. We can limit access to etcd, but that’s not the end of our troubles.

etcd stores data to disk as plain text. Restricting the access to etcd still leaves the Secrets vulnerable to anyone who has access to the file system. That, in a way, diminishes the advantage of storing Secrets in containers in tmpfs. There aren’t manybenefits of having them in tmpfs used by containers if those same Secrets are stored on disk by etcd.

Even after securing access to etcd and making sure that unauthorized users do not have access to the file system partition used by etcd, we are still at risk. When multiple replicas of etcd are running, data is synchronized between them. By default, etcd communication between replicas is not secure. Anyone sniffing that communication could get a hold of our Secrets.

Kubernetes Secrets are a step in the right direction. It is, without a doubt, better to use Secrets than to expose confidential information as environment variables or other less secure methods. Still, Secrets can give us a false sense of security.


Kubernetes Secrets are a step in the right direction. It is, without a doubt, better to use Secrets than to expose confidential information as environment variables or other less secure methods. Still, Secrets can give us a false sense of security.

# The way to secure Secrets

We need to take additional precautions to protect ourselves. This includes, but is not limited to, the following actions:

* Secure the communication between etcd instances with SSL/TLS.
* Limit access to etcd and wipe the disk or partitions that were used by it.

* Do _not_ define Secrets in YAML files stored in a repository. Create Secrets through ad-hoc `kubectl create secret` commands. If possible, delete commands history afterward.
* Make sure that the applications using Secrets do not accidentally output them to logs or transmit them to other applications.
* Create policies that allow only trusted users to retrieve Secrets. However, you should be aware that even with proper policies in place, any user with permissions to run a Pod could mount a Secret and read it.

We did not yet explored etcd configuration, nor did we learn how to set up authorization policies. For now, just remember that Secrets are not as secure as we might think, at least not the ones provided by the Kubernetes community. We do, however, encourage you to use them as long as you’re aware of their shortcomings.


Explore the insecurities associated with using Secrets and discuss the actions we can perform to secure the environment.

Not so Secretive Secrets

Insecure