Open astefanutti opened 4 years ago
/cc @davidffrench @david-martin
@astefanutti I've already seen the validating admission webhook used to enforce multi-tenancy on K8s/OCP clusters and to handle nodes draining without service disruption in case of replicated stateful applications. For that reason, I think it is the right path.
This issue has been automatically marked as stale due to 90 days of inactivity. It will be closed if no further activity occurs within 15 days. If you think that’s incorrect or the issue should never stale, please simply write any comment. Thanks for your contributions!
In some environments, where Camel K is delivered as a managed service, it would be useful to control the ability to configure the Camel K resources at the fields level based on RBAC, and restrict the configuration surface for users, to keep the risk of mis-configuration and the operation effort low. This would be particularly useful for build related fields, whose mis-configuration and combinatory complexity can lead to some hard to troubleshoot errors.
From the implementation standpoint, a validating admission webhook could be exposed by the operator, to gate the creation and updates of Camel K resources. The Webhook could rely on the
userInfo
field from theAdmissionReview
request, and check whether the content of the.Spec
field for the Camel K resource does not contain forbidden fields.