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
Our intention in not adopting the pluralizing logic is to ensure a 1-1 mapping between a ConstraintTemplate and it's generated CRD, without any guesswork on how it might have been pluralized.
The Constraint Framework is also intended to be abstracted from KRM. For example, GCP Config Validator uses the Constraint Framework to evaluate policy on Google cloud resources. As such, we do not feel strongly that we need to honor K8s idioms in this case.
I am curious if there any operational issue you are facing here or if the motivation is more philosophical. Is the non-pluralized CRD generation blocking you from doing something or making something difficult?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.
What steps did you take and what happened:
Apply a constrainttemplate containerdenyprivileged
Apply a constraint containerdenyprivileged matching this template
Run:
kubectl get customresourcedefinitions.apiextensions.k8s.io containerdenyprivileged.constraints.gatekeeper.sh -o yaml
What did you expect to happen:
Anything else you would like to add:
Kubernetes makes an unsafe guess on the plural from the ResourceName using https://github.com/kubernetes/kubernetes/blob/0383802c906edc31431c83307301138f2e53982d/staging/src/k8s.io/apimachinery/pkg/api/meta/restmapper.go#L126 if the client did not specify a resourcePlural (which a lot don't and simply rely on the same logic). It would be nice if gatekeeper would implement the same logic to generate the CRD.
See also: kubernetes/client-go#1082
Environment:
kubectl version
): 1.25The text was updated successfully, but these errors were encountered: