Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

kms: add wiring to support automatic encryption config reload #113529

Merged
merged 1 commit into from Nov 7, 2022
Merged

kms: add wiring to support automatic encryption config reload #113529

merged 1 commit into from Nov 7, 2022

Conversation

enj
Copy link
Member

@enj enj commented Nov 2, 2022 •
edited

This change adds a flag --encryption-provider-config-automatic-reload
which will be used to drive automatic reloading of the encryption
config at runtime. While this flag is set to true, or when KMS v2
plugins are used without KMS v1 plugins, the /healthz endpoints
associated with said plugins are collapsed into a single endpoint at
/healthz/kms-providers - in this state, it is not possible to
configure exclusions for specific KMS providers while including the
remaining ones - ex: using /readyz?exclude=kms-provider-1 to exclude
a particular KMS is not possible. This single healthz check handles
checking all configured KMS providers. When reloading is enabled
but no KMS providers are configured, it is a no-op.

k8s.io/apiserver does not support dynamic addition and removal of
healthz checks at runtime. Reloading will instead have a single
static healthz check and swap the underlying implementation at
runtime when a config change occurs.

Signed-off-by: Monis Khan mok@microsoft.com

/kind cleanup
/sig auth
/priority important-soon
/milestone v1.26
xref #112050

A new API server flag --encryption-provider-config-automatic-reload has been added to control when the encryption config should be automatically reloaded without needing to restart the server.  All KMS plugins are merged into a single healthz check at /healthz/kms-providers when reload is enabled, or when only KMS v2 plugins are used.

@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. sig/auth Categorizes an issue or PR as relevant to SIG Auth. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. triage/accepted Indicates an issue or PR is ready to be actively worked on. area/apiserver area/test sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. sig/testing Categorizes an issue or PR as relevant to SIG Testing. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Nov 2, 2022
@k8s-ci-robot k8s-ci-robot added the priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. label Nov 2, 2022
@k8s-ci-robot k8s-ci-robot added this to the v1.26 milestone Nov 2, 2022
@k8s-ci-robot k8s-ci-robot removed the needs-priority Indicates a PR lacks a `priority/foo` label and requires one. label Nov 2, 2022
@dims
Copy link
Member

dims commented Nov 2, 2022

/retest
/assign @liggitt

@enj
Copy link
Member Author

enj commented Nov 2, 2022

cc @micahhausler @mtaufen

@liggitt
Copy link
Member

liggitt commented Nov 2, 2022

changes lgtm, would like an ack from the folks we know using this in beta state

@enj
Copy link
Member Author

enj commented Nov 2, 2022

@bingosummer can you confirm this change works for AKS?

@enj
Copy link
Member Author

enj commented Nov 2, 2022

/retest

hoskeri
hoskeri reviewed Nov 2, 2022
View reviewed changes
Copy link
Contributor

@hoskeri hoskeri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi,

Will this change be behind a feature flag, or only if KMSv2 is in use?

We depend on being able to exclude providers we know are not being referred to by etcd from health checks, and this would prevent us from doing that.

@enj
Copy link
Member Author

enj commented Nov 2, 2022

Will this change be behind a feature flag, or only if KMSv2 is in use?

No, this proposes a change in the default of how the server works. It is not related to KMS v2 explicitly and actually benefits v1 implementations far more because the v1 API lacks any ability to inform the API server at runtime about changes to its config.

We depend on being able to exclude providers we know are not being referred to by etcd from health checks, and this would prevent us from doing that.

Sorry, can you be specific on what behavior you are trying to observe? If you know that a provider isn't being used, why not simply remove it from your encryption config?

@k8s-ci-robot k8s-ci-robot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Nov 3, 2022
@enj enj mentioned this pull request Nov 4, 2022
Closed
@enj enj changed the title kms: always use single kms-provider-0 healthz endpoint kms: add wiring to support automatic encryption config reload Nov 4, 2022
liggitt
liggitt reviewed Nov 5, 2022
View reviewed changes
Copy link
Member

@liggitt liggitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

logic looks good, one request on the plumbing of the kmsv1/kmsv2 indicators to avoid accidents or future us losing our minds

staging/src/k8s.io/apiserver/pkg/server/options/encryptionconfig/config.go Outdated
@@ -419,7 +457,7 @@ var (
EnvelopeKMSv2ServiceFactory = envelopekmsv2.NewGRPCService
)

func kmsPrefixTransformer(config *apiserverconfig.KMSConfiguration, stopCh <-chan struct{}) (value.PrefixTransformer, healthChecker, error) {
func kmsPrefixTransformer(config *apiserverconfig.KMSConfiguration, stopCh <-chan struct{}) (value.PrefixTransformer, healthChecker, bool, bool, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

super nit, but name the return values or godoc it or something (and maybe order them as kmsv1, kmsv2?)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same comments up the call chain, sorry... two undocumented bools in a surprising order is asking for accidents

Copy link
Member

@liggitt liggitt Nov 5, 2022 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

alternatively, make a struct to hold info about the loaded encryption config with KMSV1 and KMSV2 bools, since it looks like #112050 is going to add ~3 more return values that need plumbing as well, which is really unweildy (max kms timeout, content hash, and totalKMSPlugins (though I'm not sure why we need the total kms count)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

though I'm not sure why we need the total kms count

Each call to /healthz for KMS v1 can result in two gRPC calls (each of which have the KMS timeout)
With the kms-providers endpoint, these calls all happen in a union

So I think the "safe" sleep duration is (which is obviously an overestimate):

2 * 2 * <num_kms> * <max timeout> where the first 2 is simply a buffer, the second 2 is for the two gRPC calls for kms v1

@liggitt liggitt mentioned this pull request Nov 5, 2022
Merged
@enj
kms: add wiring to support automatic encryption config reload
22e540b 
This change adds a flag --encryption-provider-config-automatic-reload
which will be used to drive automatic reloading of the encryption
config at runtime.  While this flag is set to true, or when KMS v2
plugins are used without KMS v1 plugins, the /healthz endpoints
associated with said plugins are collapsed into a single endpoint at
/healthz/kms-providers - in this state, it is not possible to
configure exclusions for specific KMS providers while including the
remaining ones - ex: using /readyz?exclude=kms-provider-1 to exclude
a particular KMS is not possible.  This single healthz check handles
checking  all configured KMS providers.  When reloading is enabled
but no KMS providers are configured, it is a no-op.

k8s.io/apiserver does not support dynamic addition and removal of
healthz checks at runtime.  Reloading will instead have a single
static healthz check and swap the underlying implementation at
runtime when a config change occurs.

Signed-off-by: Monis Khan <mok@microsoft.com>
@liggitt
Copy link
Member

liggitt commented Nov 7, 2022

/lgtm
/approve

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Nov 7, 2022
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: enj, liggitt

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Nov 7, 2022
@k8s-ci-robot k8s-ci-robot merged commit b1dd1cd into kubernetes:master Nov 7, 2022
@aramase aramase mentioned this pull request Nov 7, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@hoskeri hoskeri hoskeri left review comments

@liggitt liggitt liggitt left review comments

@aramase aramase aramase left review comments

@johnSchnake johnSchnake Awaiting requested review from johnSchnake

@lavalamp lavalamp Awaiting requested review from lavalamp

Assignees

@liggitt liggitt

Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. area/apiserver area/test cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. lgtm "Looks good to me", indicates that a PR is ready to be merged. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. sig/auth Categorizes an issue or PR as relevant to SIG Auth. sig/testing Categorizes an issue or PR as relevant to SIG Testing. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
SIG Auth: KMS v2
Status: ✅ Done
[sig-release] Bug Triage
Archived in project
Milestone
v1.26
Development

Successfully merging this pull request may close these issues.

None yet
6 participants
@enj @dims @liggitt @k8s-ci-robot @hoskeri @aramase