Skip to content

Commit 4d9c5f6

Browse files
enjaramase
andauthored
Apply suggestions from code review
Co-authored-by: Anish Ramasekar <[email protected]>
1 parent 77b78d7 commit 4d9c5f6

File tree

1 file changed

+2
-2
lines changed
  • keps/sig-auth/3299-kms-v2-improvements

1 file changed

+2
-2
lines changed

keps/sig-auth/3299-kms-v2-improvements/README.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -86,7 +86,7 @@ This KEP proposes the new v2 `KeyManagementService` service contract to:
8686
### Goals
8787
- improve readiness times for clusters with a large number of encrypted resources
8888
- reduce the likelihood of hitting the KMS rate limit
89-
- enable fully automated key rotation for the latest key
89+
- enable partially automated key rotation for the latest key without API server restarts
9090
- improve KMS plugin health check reliability
9191
- improve observability of envelop operations between kube-apiserver, KMS plugins and KMS
9292
- if this v2 API reaches beta in release M, the existing v1beta1 gRPC API will be deprecated at release M
@@ -143,7 +143,7 @@ Add v2 `KeyManagementService` proto service contract in Kubernetes to include `k
143143

144144
In case of KMS v1, a new DEK is generated for every encryption. This means that for every write request, the API server makes a call to the KMS plugin to encrypt the DEK using the remote KEK. The API server also has to cache the DEKs to avoid making a call to the KMS plugin for every read request. When the API server restarts, it has to populate the cache by making a call to the KMS plugin for every DEK in the etcd store based on the cache size. This is a significant overhead for the API server.
145145

146-
With KMS v2, the API server will generate a DEK seed at startup and cache it. The API server also makes a call to the KMS plugin to encrypt the DEK seed using the remote KEK. This is a one-time call at startup and on KEK rotation. The API server then uses the cached DEK seed to generate single use DEKs via a KDF. Each DEK is used once (and only once) to encrypt a resource. This reduces the number of calls to the KMS plugin and improves the overall latency of the API server requests.
146+
With KMS v2, the API server will generate a DEK seed at startup and cache it. The API server also makes a call to the KMS plugin to encrypt the DEK seed using the remote KEK. This is a one-time call at startup and on KEK rotation. The API server then uses the cached DEK seed to generate single use DEKs via a Key Derivation Function (KDF). Each DEK is used once (and only once) to encrypt a resource. This reduces the number of calls to the KMS plugin and improves the overall latency of the API server requests.
147147

148148
### key_id and rotation
149149

0 commit comments

Comments
 (0)