- add an integration test that exercises the unsafe delete flow
- extend newTransformTest to enable RBAC
- add integration test to verify that LIST returns corrupt object keys
Integration testing has to this point relied on patching serving codecs for built-in APIs. The
test-only patching is removed and replaced by feature gated checks at runtime.
Setting AllAlpha=true in integration tests changes the dynamic client request encoding and the
custom resource storage encoding to CBOR. The etcd storage path is updated to accept either JSON or
CBOR as storage encoding. The client feature gate controlling the dynamic client request encoding is
temporarily disabled until the serving codecs for builtin APIs are wired to the CBOR apiserver
feature gate.
This change updates the KDF "feature flag" to be per KMS provider
instead of global to the API server. This allows integration tests
that use distinct provider names to run in parallel.
Locally this change reduced the runtime of
test/integration/controlplane/transformation by 3.5 minutes.
Signed-off-by: Monis Khan <mok@microsoft.com>
27a68aee3a introduced context support for events. Creating an event
broadcaster with context makes tests more resilient against leaking goroutines
when that context gets canceled at the end of a test and enables per-test
output via ktesting.
The context could get passed to the constructor. A cleaner solution is to
enhance context support for the apiserver and then pass the context into the
controller's run method. This ripples up the call stack to all places which
start an apiserver.
This change updates KMS v2 to not create a new DEK for every
encryption. Instead, we re-use the DEK while the key ID is stable.
Specifically:
We no longer use a random 12 byte nonce per encryption. Instead, we
use both a random 4 byte nonce and an 8 byte nonce set via an atomic
counter. Since each DEK is randomly generated and never re-used,
the combination of DEK and counter are always unique. Thus there
can never be a nonce collision. AES GCM strongly encourages the use
of a 12 byte nonce, hence the additional 4 byte random nonce. We
could leave those 4 bytes set to all zeros, but there is no harm in
setting them to random data (it may help in some edge cases such as
live VM migration).
If the plugin is not healthy, the last DEK will be used for
encryption for up to three minutes (there is no difference on the
behavior of reads which have always used the DEK cache). This will
reduce the impact of a short plugin outage while making it easy to
perform storage migration after a key ID change (i.e. simply wait
ten minutes after the key ID change before starting the migration).
The DEK rotation cycle is performed in sync with the KMS v2 status
poll thus we always have the correct information to determine if a
read is stale in regards to storage migration.
Signed-off-by: Monis Khan <mok@microsoft.com>
