New KB articles published for the week ending 26th October,2019
October 31, 2019
Keep Parquet and ORC from the data graveyard with new BigQuery features
October 31, 2019
Note that you can only use CMEK to protect data on new persistent disks attached to nodes in your cluster–you cannot use it to protect existing persistent disks. Nor can you use CMEK to protect node boot disks or control plane disks. To use CMEK with regional clusters, you must use GKE version 1.14 or higher, and the GCE PD CSI driver version 0.5.1 or higher.
Secrets in Kubernetes
The GKE control plane stores API objects, including Kubernetes secrets, inside the etcd database, which sits on a disk encrypted with a Google-managed key.
To add more protection for secrets, Kubernetes has allowed for application-layer envelope encryption of Secrets with a KMS provider since v1.10. A local key is used to encrypt the Secrets (known as a “data encryption key”), and the key is itself encrypted with another key (a “key encryption key”) stored in a key management service, not in Kubernetes. This model allows you to regularly rotate the key encryption key without having to re-encrypt all the Secrets.
Application-layer Secrets encryption is now generally available in GKE, so you can protect Secrets with envelope encryption: your Secrets are encrypted with a local AES-256-CBC data encryption key, which is encrypted with a key encryption key that you manage in Cloud KMS.
You can use application-layer Secrets encryption with new clusters and existing clusters. To enable it, specify the --database-encryption-key flag as part of your cluster creation/update, with your Cloud KMS key KMS_KEY_ID:
