Secrets
1. Secrets
Similar to ConfigMaps, Secrets pass information to Pods. However, the difference is that Kubernetes applications use Secrets to store sensitive information like passwords, tokens, and SSH keys. This lets users manage sensitive information in their own control plane. Secrets also help to ensure Kubernetes doesn't accidentally output this data to logs. That being said, if an application is managing high-value assets or requires stringent regulatory requirements, key management systems like Cloud Key Management Service, also referred to as Cloud KMS, should be used for full secret management. There are three types of Secrets: generic, TLS, and Docker-Registry. Generic Secrets are used for creating Secrets from files, directories, or literal values. TLS Secrets are designed to securely store transport layer security (TLS) certificates and their associated private keys. These are the digital credentials used to establish encrypted communication between different components in a cluster. And Docker-Registry Secrets are designed to store the credentials needed to authenticate with private Docker registries. However, in GKE, Artifact Registry integrates with Cloud Identity and Access Management, so this Secret type is not needed. Let’s explore the generic Secret type in some more detail. Just like ConfigMaps, generic Secrets are stored in key-value pairs. However, in Secrets, values are base-64–encoded strings. Base-64 encoding is a way of representing binary data–like images, audio, or code–using text characters. Now it’s important to note that base-64 encoding is not a form of encryption. If encryption is required, please use an encryption key management system like Cloud KMS. Any encoded strings produced can then be used in the Secret manifest. But how exactly do you create a Secret? The answer is by using the kubectl create secret command. One option is to create a Secret using files, which means populating the Secret object with data sourced directly from files on your local system. A second option is to create a Secret using literal values, which means defining the secret data directly within the Secret manifest file itself. And a third option is to create a Secret using naming keys, which means using the default key name as the file name. For all three options, the syntax is similar. The differences come from the Secrets entry details. There are separate control planes for Configmaps and Secrets. Control planes provide a mechanism to create a secure storage that can be used to store and protect Secrets. Let’s say a Secret Volume named storagesecrets is created and refers to a Secret named demo-secret. This Volume is mounted to the container with read-only access. This Volume can be used by multiple containers within the Pod. Which allows for better latency, because Pods do not need to wait to gain access to the secret. A password key for the Secret will not be displayed. If a password key is required, it must be listed under the items field. Just like ConfigMaps, kubelet periodically syncs with Secrets to keep a Secret Volume updated. If a Secret that is already attached as a Volume has changed, the keys and values will eventually be updated.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.