Calico 3.29.2 apiserver fails to start due to missing validatingadmission* rbac rules #3780
Description
Code @ https://github.com/tigera/operator/blob/ed26c42e1e232e9cc604a9a010d4ca9111b6f388/pkg/render/apiserver.go#L654C11-L654C28 conditionally adds rule based on kuberetes version
if c.cfg.KubernetesVersion == nil || !(c.cfg.KubernetesVersion != nil && c.cfg.KubernetesVersion.Major < 2 && c.cfg.KubernetesVersion.Minor < 30) {
// If the kubernetes version is higher than 1.30, we add extra RBAC permissions to allow establishing watches.
// https://v1-30.docs.kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/
rules = append(rules, rbacv1.PolicyRule{
// Kubernetes validating admission policy resources.
APIGroups: []string{"admissionregistration.k8s.io"},
Resources: []string{
"validatingadmissionpolicies",
"validatingadmissionpolicybindings",
},
Verbs: []string{
"get",
"list",
"watch",
},
})
}
With calico 3.29.2 with commit projectcalico/calico@8eacb02 there was a new default set to EnableValidatingAdmissionPolicy which depends on the validatingadmissionpolicies and validatingadmissionpolicybindings being present. When deploying tigera operator via a helm chart install the rules required to successfully make those requests are missing resulting in calico-apiserver error:
0219 12:38:01.076291 1 reflector.go:150] k8s.io/[email protected]/tools/cache/reflector.go:232: Failed to watch *v1.ValidatingAdmissionPolicy: failed to list *v1.ValidatingAdmissionPolicy: validatingadmissionpolicies.admissionregistration.k8s.io is forbidden: User "system:serviceaccount:calico-apiserver:calico-apiserver" cannot list resource "validatingadmissionpolicies" in API group "admissionregistration.k8s.io" at the cluster scope
The logic of the if statement above is reversed for the c.cfg.KubernetesVersion.Minor check and should be checking c.cfg.KubernetesVersion.Minor > 30 and not < 30 as the comment suggests it is. I tested with kuberenetes 1.32 and observed these errors. If I manually add these rules the the calico-apiserver starts as expected.