Secure your data

Protecting your data is essential for maintaining confidentiality, integrity, and availability in your Kubernetes environment. This article outlines strategies for securing secrets, encrypting data at rest and in transit, and planning for cluster recovery. By following these practices, you can help safeguard sensitive information and support business continuity.

Keep secret values (passwords, keys, etc.) in a vault, such as Azure Key Vault. It's good practice for such secrets never to leave the vault, and to be used only for signing/crypto operations inside the vault itself. However, for on-premises clusters, you may not be able to reliably maintain your cloud connection to this vault and hence maintain your ability always to use secrets when they're needed.

If so, consider using the Azure Key Vault Secret Store extension for Kubernetes (preview) ("SSE"). This extension can help automatically synchronize selected secrets from an Azure Key Vault and store them for offline use in the Kubernetes secrets store of an Azure Arc-enabled Kubernetes cluster.

• CIS Kubernetes Benchmark - Sections 1, 2, and 4
• NIST Application Container Security Guide - Section 4.5.1-3

If you're running AKS enabled by Azure Arc on Azure Local, then it restricts direct access to the Kubernetes configuration store, etcd, which holds Kubernetes secrets. Further, it has a built-in KMS plugin that helps to automatically encrypt these secrets. This plugin generates the Key Encryption Key (KEK), isolates it away from the cluster in the underlying Windows host, and automatically rotates it every 30 days.

If you connect your own cluster via Arc-enabled Kubernetes, then help ensure etcd is protected, and your secrets are encrypted, by following your vendor's guidance.

• Section 2 of the CIS Kubernetes Benchmark
• NSA Kubernetes Hardening Guidance - "Secrets"
• Kubernetes Security - OWASP Cheat Sheet Series - "Securing data"

Plan how you would recover from a loss of your cluster. If you're using AKS enabled by Azure Arc on Azure Local or other high-availability options, then it can help protect against regular hardware failures. But it's still possible that the cluster can be lost due to an incident that impacts your whole site or to a cyberattack.

A starting point is to aim for all your configuration and data to be sourced from, and synchronized back to, the cloud. This synchronization means that reinstating your cluster is like initial activation. Consider configuring your cluster using GitOps with Flux, synchronizing your Azure Key Vault secrets using the Secret Store extension (preview).

Alternatively, you may still need to consider using a dedicated cluster backup solution such as Velero. Such as solution could be necessary if the only copy of some of your data is stored in your cluster or if you require extra protection.

• Learn how to secure your network
• Return to the top of this security book