The project does not recommend using insecure ports. Even
unauthenticated TLS is an improvement since it provides confidentiality.
If you relied upon this, please update to secure serving options.
Kubernetes-commit: de302c73e9558c192fde1cd7d6dcbea7eb76e950
This is a no-op change that makes the internal encryption config
hash more specific to it use and explicitly marks it as unstable.
Signed-off-by: Monis Khan <mok@microsoft.com>
Kubernetes-commit: 9387a66c71fd85840cb199b468610b8fa950253f
Avoids starting informers or the config-consuming controller when
--enable-priority-and-fairness=false. For kube-apiserver, the config-producing controller runs if
and only if flowcontrol API storage is enabled.
Kubernetes-commit: 83f5b5c240e5cced1371bbd22e458dae43975238
Change name to make it compliant with prometheus guidelines.
Calculate it on demand instead of periodic to comply with prometheus standards.
Replace "endpoint" with "server" label to make it semantically consistent with storage factory
Kubernetes-commit: 7a63997c8a1a9ba14f2bdc478fdf33cf88f48d80
Change admission ApplyTo() to take in clients instead of a rest.Config.
Signed-off-by: Andy Goldstein <andy.goldstein@redhat.com>
Kubernetes-commit: 364b66ddd6554a898724b6781fd90a15a38ddb41
Prior to this change, we wait until the DEK is used to perform an
encryption before validating the response. This means that the
plugin could report healthy but all TransformToStorage calls would
fail. Now we correctly cause the plugin to become unhealthy and do
not attempt to use the newly generated DEK.
Signed-off-by: Monis Khan <mok@microsoft.com>
Kubernetes-commit: 5469c198e5d074c7e88e14c3dcbc3ebb2b37cfa8
This matches the logic we have for the Authorization header as well
as the impersonation headers.
Signed-off-by: Monis Khan <mok@microsoft.com>
Kubernetes-commit: e9866d2794675aa8dc82ba2637ae45f9f3a27dff
It is possible for a KMSv2 plugin to return a static value as Ciphertext
and store the actual encrypted DEK in the annotations. In this case,
using the encDEK will not work. Instead, we are now using a combination
of the encDEK, keyID and annotations to generate the cache key.
Signed-off-by: Anish Ramasekar <anish.ramasekar@gmail.com>
Kubernetes-commit: 8eacf09649ac9042c7e998b5c24ac59d68ae7e6c
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>
Kubernetes-commit: 832d6f0e19f13b9dd22b1fe9d705817e9e64f4f1
chenk008