You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 26, 2023. It is now read-only.
We should avoid having all resources across all namespaces (* wildcard in rules for resources, apiVersions and apiGroups from going through the Gatekeeper webhooks due to performance and security risks. As a result, we need to deploy a default opt-in namespace selector for the Gatekeeper ValidatingWebhookConfiguration and MutatingWebhookConfiguration. This will allow the user to label the specific namespaces that they want to have the Gatekeeper policy engine enabled.
Additionally, we need to determine if the NamespaceSelector field in the Gatekeeper Operator API should be used to override this new default described above entirely, or make it an additive to this new default. It would be best to make it additive so as to avoid inadvertently stepping on critical namespaces.
This new default namespace selector will be good for all namespaced resources, but additionally, since all cluster-scoped resources will still be sent to the Gatekeeper webhooks, we need to update the rules field in the ValidatingWebhookConfiguration and MutatingWebhookConfiguration to avoid sending critical and security sensitive resources e.g. tokenreviews, subjectaccessreviews. This could be achieved by modifying the rules field to list all apiGroups for which a wildcard of * for all resources should apply, as well as a rule containing the list of specific apiGroups for which specific resources from that group must only apply. This may be simplified and/or refined by using the rule scope field..
TODO:
Determine if this is the behavior we would also want for all Kubernetes clusters.
The text was updated successfully, but these errors were encountered:
We should avoid having all resources across all namespaces (
*
wildcard in rules forresources
,apiVersions
andapiGroups
from going through the Gatekeeper webhooks due to performance and security risks. As a result, we need to deploy a default opt-in namespace selector for the GatekeeperValidatingWebhookConfiguration
andMutatingWebhookConfiguration
. This will allow the user to label the specific namespaces that they want to have the Gatekeeper policy engine enabled.Additionally, we need to determine if the
NamespaceSelector
field in the Gatekeeper Operator API should be used to override this new default described above entirely, or make it an additive to this new default. It would be best to make it additive so as to avoid inadvertently stepping on critical namespaces.This new default namespace selector will be good for all namespaced resources, but additionally, since all cluster-scoped resources will still be sent to the Gatekeeper webhooks, we need to update the
rules
field in theValidatingWebhookConfiguration
andMutatingWebhookConfiguration
to avoid sending critical and security sensitive resources e.g.tokenreviews
,subjectaccessreviews
. This could be achieved by modifying therules
field to list allapiGroups
for which a wildcard of*
for allresources
should apply, as well as a rule containing the list of specificapiGroups
for which specificresources
from that group must only apply. This may be simplified and/or refined by using the rulescope
field..TODO:
Determine if this is the behavior we would also want for all Kubernetes clusters.
The text was updated successfully, but these errors were encountered: