Get Started

• Documentation
• Blog
• Partners
• Community
• Case Studies

Get Started

Ready to get your hands dirty? Build a simple Kubernetes cluster that runs “Hello World” for Node.js.

Documentation

Learn how to use Kubernetes with the use of walkthroughs, samples, and reference documentation. You can even help contribute to the docs!

Community

If you need help, you can connect with other Kubernetes users and the Kubernetes authors, attend community events, and watch video presentations from around the web.

Blog

Read the latest news for Kubernetes and the containers space in general, and get technical how-tos hot off the presses.

Interested in hacking on the core Kubernetes code base?

View On Github

Explore the community

Twitter Github Slack Stack Overflow Mailing List Events Calendar

Tasks

• HOME
• SETUP
• CONCEPTS
• TASKS
• TUTORIALS
• REFERENCE

Tasks

Install Tools

Install and Set Up kubectlInstall MinikubeInstalling kubeadm

Configure Pods and Containers

Assign CPU and RAM Resources to a ContainerConfigure a Pod to Use a Volume for StorageConfigure a Pod to Use a PersistentVolume for StorageConfigure a Pod to Use a Projected Volume for StorageConfigure a Security Context for a Pod or ContainerConfigure Service Accounts for PodsPull an Image from a Private RegistryConfigure Liveness and Readiness ProbesAssign Pods to NodesConfigure Pod InitialisationAttach Handlers to Container Lifecycle EventsConfigure Containers Using a ConfigMapUse ConfigMap Data in PodsTranslate a Docker Compose File to Kubernetes Resources

Inject Data Into Applications

Define a Command and Arguments for a ContainerDefine Environment Variables for a ContainerExpose Pod Information to Containers Through Environment VariablesExpose Pod Information to Containers Through FilesDistribute Credentials Securely Using SecretsInject Information into Pods Using a PodPreset

Run Applications

Run a Stateless Application Using a DeploymentRun a Single-Instance Stateful ApplicationRun a Replicated Stateful ApplicationUpgrade from PetSets to StatefulSetsScale a StatefulSetDelete a Stateful SetForce Delete StatefulSet PodsPerform Rolling Update Using a Replication ControllerHorizontal Pod AutoscalingHorizontal Pod Autoscaling WalkthroughSpecifying a Disruption Budget for your Application

Run Jobs

Parallel Processing using ExpansionsCoarse Parallel Processing Using a Work QueueFine Parallel Processing Using a Work Queue

Access Applications in a Cluster

Web UI (Dashboard)Accessing ClustersAuthenticate across clusters with kubeconfigUse Port Forwarding to Access Applications in a ClusterProvide Load-Balanced Access to an Application in a ClusterUse a Service to Access an Application in a ClusterConnect a Front End to a Back End Using a ServiceCreate an External Load BalancerConfigure Your Cloud Provider’s FirewallsList All Container Images Running in a ClusterCommunicate Between Containers in the Same Pod Using a Shared VolumeConfiguring DNS for a Cluster

Monitor, Log, and Debug

Tools for Monitoring Compute, Storage, and Network ResourcesGet a Shell to a Running ContainerMonitor Node HealthLogging Using StackdriverEvents in StackdriverLogging Using Elasticsearch and KibanaDetermine the Reason for Pod FailureDebug Init ContainersDebug Pods and Replication ControllersDebug ServicesTroubleshoot ClustersTroubleshoot ApplicationsDebug a StatefulSetApplication Introspection and DebuggingAuditingUse Explorer to Examine the Runtime Environment

Access and Extend the Kubernetes API

Use an HTTP Proxy to Access the Kubernetes APIExtend the Kubernetes API with CustomResourceDefinitionsExtend the Kubernetes API with ThirdPartyResourcesMigrate a ThirdPartyResource to CustomResourceDefinitionConfigure the aggregation layerSetup an extension API server

TLS

Manage TLS Certificates in a Cluster

Administer a Cluster

Access Clusters Using the Kubernetes APIAccess Services Running on ClustersSecuring a ClusterEncrypting data at restOperating etcd clusters for KubernetesApply Resource Quotas and LimitsConfigure Out Of Resource HandlingSet Pod CPU and Memory LimitsReserve Compute Resources for System DaemonsStatic PodsGuaranteed Scheduling For Critical Add-On PodsCluster ManagementCluster Management Guide for Version 1.6Upgrading kubeadm clusters from 1.6 to 1.7Share a Cluster with NamespacesNamespaces WalkthroughAutoscale the DNS Service in a ClusterSafely Drain a Node while Respecting Application SLOsDeclare Network Policy

Install Network Policy Provider

Use Calico for NetworkPolicyRomana for NetworkPolicyWeave Net for NetworkPolicy

Change the Reclaim Policy of a PersistentVolumeLimit Storage ConsumptionChange the default StorageClassShare Cluster Access with kubeconfigBuild and Run cloud-controller-managerSet up High-Availability Kubernetes MastersConfigure Multiple SchedulersIP Masquerade Agent User GuideConfigure private DNS zones and upstream nameservers in KubernetesChange Cluster Sise

Federation - Run an App on Multiple Clusters

Cross-cluster Service Discovery using Federated ServicesSet up Cluster Federation with KubefedSet up CoreDNS as DNS provider for Cluster FederationSet up placement policies in FederationFederated ClusterFederated ConfigMapFederated DaemonSetFederated DeploymentFederated EventsFederated IngressFederated NamespacesFederated ReplicaSetsFederated Secrets

Manage Cluster Daemons

Perform a Rolling Update on a DaemonSetPerforming a Rollback on a DaemonSet

Manage GPUs

Schedule GPUs

Edit This Page

Encrypting data at rest

This page shows how to enable and configure encryption of secret data at rest.

• Before you begin
• Configuration and determining whether encryption at rest is already enabled
• Understanding the encryption at rest configuration.
  • Providers:
• Encrypting your data
• Verifying that data is encrypted
• Ensure all secrets are encrypted
• Rotating a decryption key
• Decrypting all data

Before you begin

• You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using Minikube, or you can use one of these Kubernetes playgrounds:

• Katacoda

• Play with Kubernetes

• Kubernetes version 1.7.0 or later is required

• Encryption at rest is alpha in 1.7.0 which means it may change without notice. Users may be required to decrypt their data prior to upgrading to 1.8.0.

Configuration and determining whether encryption at rest is already enabled

The kube-apiserver process accepts an argument --experimental-encryption-provider-config that controls how API data is encrypted in etcd. An example configuration is provided below.

Understanding the encryption at rest configuration.

kind: EncryptionConfig
apiVersion: v1
resources:
  - resources:
    - secrets
    providers:
    - identity: {}
    - aesgcm:
        keys:
        - name: key1
          secret: c2VjcmV0IGlzIHNlY3VyZQ==
        - name: key2
          secret: dGhpcyBpcyBwYXNzd29yZA==
    - aescbc:
        keys:
        - name: key1
          secret: c2VjcmV0IGlzIHNlY3VyZQ==
        - name: key2
          secret: dGhpcyBpcyBwYXNzd29yZA==
    - secretbox:
        keys:
        - name: key1
          secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=

Each resources array item is a separate config and contains a complete configuration. The resources.resources field is an array of Kubernetes resource names (resource or resource.group) that should be encrypted. The providers array is an ordered list of the possible encryption providers. Only one provider type may be specified per entry (identity or aescbc may be provided, but not both in the same item).

The first provider in the list is used to encrypt resources going into storage. When reading resources from storage each provider that matches the stored data attempts to decrypt the data in order. If no provider can read the stored data due to a mismatch in format or secret key, an error is returned which prevents clients from accessing that resource.

IMPORTANT: If any resource is not readable via the encryption config (because keys were changed), the only recourse is to delete that key from the underlying etcd directly. Calls that attempt to read that resource will fail until it is deleted or a valid decryption key is provided.

Providers:

Name	Encryption	Strength	Speed	Key Length	Other Considerations
identity	None	N/A	N/A	N/A	Resources written as-is without encryption. When set as the first provider, the resource will be decrypted as new values are written.
aescbc	AES-CBC with PKCS#7 padding	Strongest	Fast	32-byte	The recommended choice for encryption at rest but may be slightly slower than secretbox.
secretbox	XSalsa20 and Poly1305	Strong	Faster	32-byte	A newer standard and may not be considered acceptable in environments that require high levels of review.
aesgcm	AES-GCM with random nonce	Must be rotated every 200k writes	Fastest	16, 24, or 32-byte	Is not recommended for use except when an automated key rotation scheme is implemented.

Each provider supports multiple keys - the keys are tried in order for decryption, and if the provider is the first provider, the first key is used for encryption.

Encrypting your data

Create a new encryption config file

kind: EncryptionConfig
apiVersion: v1
resources:
  - resources:
    - secrets
    providers:
    - aescbc:
        keys:
        - name: key1
          secret: <BASE 64 ENCODED SECRET>
    - identity: {}

To create a new secret perform the following steps:

1. Generate a 32 byte random key and base64 encode it. If you’re on Linux or Mac OS X, run the following command:

    head -c 32 /dev/urandom | base64 -i - -o -
   

2. Place that value in the secret field.
3. Set the --experimental-encryption-provider-config flag on the kube-apiserver to point to the location of the config file
4. restart your API server.

IMPORTANT: Your config file contains keys that can decrypt content in etcd, so you must properly restrict permissions on your masters so only the user who runs the kube-apiserver can read it.

Verifying that data is encrypted

Data is encrypted when written to etcd. After restarting your kube-apiserver, any newly created or updated secret should be encrypted when stored. To check, you can use the etcdctl command line program to retrieve the contents of your secret.

1. Create a new secret called secret1 in the default namespace:

    kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
   

2. Using the etcdctl commandline, read that secret out of etcd:

    ETCDCTL_API=3 etcdctl get /kubernetes.io/secrets/default/secret1 [...] | hexdump -C
   

   where [...] must be the additional arguments for connecting to the etcd server.

3. Verify the stored secret is prefixed with k8s:enc:aescbc:v1: which indicates the aescbc provider has encrypted the resulting data.

4. Verify the secret is correctly decrypted when retrieved via the API:

    kubectl describe secret generic -n default
   

   should match mykey: mydata

Ensure all secrets are encrypted

Since secrets are encrypted on write, performing an update on a secret will encrypt that content.

kubectl get secrets -o json | kubectl replace -f -

The command above reads all secrets and then updates them to apply server side encryption. If an error occurs due to a conflicting write, retry the command. For larger clusters, you may wish to subdivide the secrets by namespace or script an update.

Rotating a decryption key

Changing the secret without incurring downtime requires a multi step operation, especially in the presence of a highly available deployment where multiple kube-apiserver processes are running.

1. Generate a new key and add it as the second key entry for the current provider on all servers
2. Restart all kube-apiserver processes to ensure each server can decrypt using the new key
3. Make the new key the first entry in the keys array so that it is used for encryption in the config
4. Restart all kube-apiserver processes to ensure each server now encrypts using the new key
5. Run kubectl get secrets -o json | kubectl replace -f - to encrypt all existing secrets with the new key
6. Remove the old decryption key from the config after you back up etcd with the new key in use and update all secrets

With a single kube-apiserver, step 2 may be skipped

Decrypting all data

To disable encryption at rest place the identity provider as the first entry in the config:

kind: EncryptionConfig
apiVersion: v1
resources:
  - resources:
    - secrets
    providers:
    - identity: {}
    - aescbc:
        keys:
        - name: key1
          secret: <BASE 64 ENCODED SECRET>

and restart all kube-apiserver processes. Then run the command kubectl get secrets -o json | kubectl replace -f - to force all secrets to be decrypted.

Create an Issue Edit this Page

Get Started Documentation Blog Partners Community Case Studies

twitter Github Slack

Stack Overflow Mailing List Events Calendar

Get Kubernetes Contribute

© 2017 The Kubernetes Authors

Documentation Distributed under CC BY 4.0

Copyright © 2017 The Linux Foundation®. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our Trademark Usage page: https://www.linuxfoundation.org/trademark-usage