Возня с Kyverno

Какое-то время пришлось возиться с Kyverno в GKE и решил сделать пометки для истории. Началось всё с обратной связи от разработчиков, которым Kyverno не давал создать сервис Knative.

Failed to create Ingress: admission webhook "validate.kyverno.svc-fail" denied the request: resource Ingress/NAMESPACE/SERVICE was blocked due to the following policies disallow-empty-ingress-host: disallow-empty-ingress-host: The Ingress host name must be defined, not empty.

Это результат работы политики disallow-empty-ingress-host, которая написана без учёта того что одинаковые kind Ingress может быть у разных apiVersion и скорее всего они будут несовместимы.

Добавил исключение в конфигурацию, но обновление чарта с политиками Kyverno завершилась с ошибками:

admission webhook "validate-policy.kyverno.svc" denied the request: no unique match for kind Service
admission webhook "validate-policy.kyverno.svc" denied the request: no unique match for kind Ingress

В общем отделаться по-быстрому исключением и закинуть улучшение в бэклог не вышло. Выпустил новый релиз чарта с подправленными политиками (/v1/Service вместо Service и networking.k8s.io/*/Ingress вместо Ingress) и раз полез в Kyverno, то заодно подтянул изменения с нижних окружений, которые касались Kyverno.

В числе этих изменений было и обновление версии самого Kyverno. Полистал коротенький upgrading kyverno, но там подсветили только риск при обновлении до 1.13, которая уже была позади. Список изменений в GitHub это просто компиляция сообщений из комитов, но на всякий случай полистал и его. Обновление версии Kyverno в GKE принесло проблему, которая не проявлялась в AKS - большое количество полиси отчётов стали содержать ошибки вида:

Message:    expression '![ "system:addon-manager", "system:serviceaccount:kube-system:cronjob-controller", "system:serviceaccount:kube-system:daemon-set-controller", "system:serviceaccount:kube-system:deployment-controller", "system:serviceaccount:kube-system:job-controller", "system:serviceaccount:kube-system:replicaset-controller", "system:serviceaccount:kube-system:replication-controller", "system:serviceaccount:kube-system:statefulset-controller", "system:high-scale-checkpointing-controller" ].exists(sa, sa == request.userInfo.username)' resulted in error: no such key: username
Policy:     validating-node-p4sa-audience
Properties:
Binding:  validating-node-p4sa-audience-binding
Process:  background scan
Result:     error
Rule:       validating-node-p4sa-audience
Scored:     true
Source:     ValidatingAdmissionPolicy
Timestamp:
Nanos:    0
Seconds:  1774959021

Эта ValidatingAdmissionPolicy является частью GKE, поэтому сначала попробовал её исключить через config.resourceFiltersInclude ('[ValidatingAdmissionPolicy,*,validating-node-p4sa-audience]'), но это не дало нужного результата. Нужно иметь ввиду что reportsController по-умолчанию игнорирует фильтр ресурсов, но его принудительное включение результата не дало.

Проблема известная (kyverno #15127) и возможно её исправят в 1.18, но пока пришлось выключить проверку ValidatingAdmissionPolicy в reportsController:

reportsController:
  extraArgs:
    # Disabling VAP policy reports due to issues in GKE (recheck in 1.18)
    # See https://github.com/kyverno/kyverno/issues/15127
    validatingAdmissionPolicyReports: "false" # If passed as boolean it will be ignored

После этого отчёты Kyverno пришли в норму.