CNTRLPLANE-2121: doc running pre-flight checker on every configuration change#1999
CNTRLPLANE-2121: doc running pre-flight checker on every configuration change#1999p0lyn0mial wants to merge 1 commit into
Conversation
p0lyn0mial
changed the title
|
@p0lyn0mial: This pull request references CNTRLPLANE-2121 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set. DetailsIn response to this: Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci-robot
added
the
jira/valid-reference
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
| #### Pre-flight Checker (Tech Preview v2) | ||
|
|
||
| The pre-flight checker validates KMS configuration before an encryption key is created. It consists of two parts: a preflight binary that tests the KMS provider end-to-end via the plugin, and a controller that coordinates the check with the key-controller. | ||
| The pre-flight checker validates KMS configuration before any configuration change is applied. The API allows admins to specify a KMS plugin image reference, and the API may add new fields over time in a backward-compatible way (e.g., a new field that maps to a new plugin flag). A new flag is expected to be supported for a range of image versions (say 1.X+), but we do not control which image version the admin provides: they might set a new field while referencing an older image (e.g., 1.X-2) that does not support the corresponding flag. Rather than maintaining a compatibility matrix between API field sets and image versions, we run the pre-flight checker unconditionally — the cost of an extra pod is acceptable compared to the risk of deploying an incompatible configuration. |
There was a problem hiding this comment.
+1000 to the benefits of this mechanism
| **Recovery from incorrect configuration:** | ||
| - Migration-triggering fields: prevented by pre-flight checks (misconfiguration is caught before key generation). | ||
| - Non-migration fields (e.g., image): admin provides corrected configuration via APIServer resource. A new revision is created; older providers retain their original configuration as fallback. | ||
| - Non-migration fields (e.g., image): prevented by pre-flight checks (misconfiguration is caught before the update is applied). |
There was a problem hiding this comment.
It would still make sense keeping this statement;
older providers retain their original configuration as fallback.
Because in-place updates are only active for the last active key. Preflight checker only works with the last active key.
If the content of the Secret of one of the old read keys is updated, preflight won't validate it. Controllers will still degrade and it is up to the cluster admin to fix it.
There was a problem hiding this comment.
If the content of the Secret of one of the old read keys is updated, preflight won't validate it.
yes, we will not support updating old providers, we only support currently configured provider.
p0lyn0mial
force-pushed
the
kms-preflight-checker-update
branch
from
e609f28 to
b2601f6
Compare
|
@p0lyn0mial: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
/lgtm |
|
/assign @benluddy for approval. |
4 participants
No description provided.