-
Story
-
Resolution: Done
-
Major
-
None
-
None
-
Product / Portfolio Work
-
False
-
-
False
-
13
-
None
-
CLOUD Sprint 271, CLOUD Sprint 272, CLOUD Sprint 273, CLOUD Sprint 274, CLOUD Sprint 275, CLOUD Sprint 276, CLOUD Sprint 277
Background
When Machines and MachineSets are not authoritative, they should not be allowed to be modified apart from labels, annotations and the authoritative API related fields.
We may be able to implement this using ValidatingAdmissionPolicy. If the validation is too complex for this, we will then need to use a webhook to validate the updates.
https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/
Both VAP and Webhooks have access to the SubjectAccessReview information, which will tell us which user updated the resource. We only want to allow major updates to come from the sync controller service account.
Behaviours
- Reject updates to non-authoritative resources, except:
- Labels and Annotations that are not material to operation
- Are not kubernetes.io or openshift.io prefixed
- Are not being modified to not match the Authoritative resource
- Are not important for operation of Cluster API or Machine API
- Updates to the .spec.authoritativeAPI
- Updates that originate from the service account of the sync controller or migration controller
- Labels and Annotations that are not material to operation
edit(theo):
- Are not being modified to not match the Authoritative resource === Are being modified away from matching Authoritative
Steps
- Explore using VAP for Machine and MachineSet validation in MAPI
- Explore using VAP for Machine and MachineSet validation in CAPI
- If we cannot validate based on the above, implement a webhook to apply the validations described.
Stakeholders
- Cluster Infra
Definition of Done
- When a non authoritative Machine/MachineSet is updated, the request is rejected unless it comes from the sync controller service account
- Docs
- <Add docs requirements for this card>
- Testing
- <Explain testing that will be added>
- links to