Change Details

In [[ https://github.com/kyverno/kyverno/issues/10458#issuecomment-2182348444 | talks with upstream kyverno maintainers ]], I discovered there is another approach we could take to introduce kyverno-based pod security controls. === Option 1 === * We could introduce a configmap, populated/updated via maintain-kubeusers, with data like this (a mapping of account name to uid): ``` data: tool-sometool: "1" tool-someothertool: "2" ``` * Using kyverno [[ https://release-1-10-0.kyverno.io/docs/writing-policies/external-data-sources/#variables-from-configmaps | variables from configmaps ]], we could have a single ClusterPolicy resource, that would lookup tool account uid in the configmap. * Crafing the ClusterPolicy to do this lookup may not be trivial, but the upside is that we would greatly reduce the kyverno workload and resources footprint in the cluster, from 3.5k policy resources (one in each tool account namespace) to a single one. However, configmaps have [[ https://kubernetes.io/docs/concepts/configuration/configmap/ | a hard limit of 1MB ]], so this may not scale well. === Option 2 === Another option is to use two other kyverno functions: * [[ https://kyverno.io/docs/writing-policies/external-data-sources/#variables-from-service-calls | variables from external service calls ]] * [[ https://kyverno.io/docs/writing-policies/external-data-sources/#api-call | global context cache from external service calls ]] Which allows calling (and caching) external HTTP services that returns a JSON that can be used at policy evaluation time. However, with LDAP in particular, we would need some kind of HTTP/JSON frontend o return the mapping of account names and uids. This is only available starting with Kyverno 1.12.

In [[ https://github.com/kyverno/kyverno/issues/10458#issuecomment-2182348444 | talks with upstream kyverno maintainers ]], I discovered there is another approach we could take to introduce kyverno-based pod security controls. === Option 1 === * We could introduce a configmap, populated/updated via maintain-kubeusers, with data like this (a mapping of account name to uid): ``` data: tool-sometool: "1" tool-someothertool: "2" ``` * Using kyverno [[ https://release-1-10-0.kyverno.io/docs/writing-policies/external-data-sources/#variables-from-configmaps | variables from configmaps ]], we could have a single ClusterPolicy resource, that would lookup tool account uid in the configmap. * Crafing the ClusterPolicy to do this lookup may not be trivial, but the upside is that we would greatly reduce the kyverno workload and resources footprint in the cluster, from 3.5k policy resources (one in each tool account namespace) to a single one. However, configmaps have [[ https://kubernetes.io/docs/concepts/configuration/configmap/ | a hard limit of 1MB ]], so this may not scale well. === Option 2 === Another option is to use two other kyverno functions: * [[ https://kyverno.io/docs/writing-policies/external-data-sources/#variables-from-service-calls | variables from external service calls ]] * [[ https://kyverno.io/docs/writing-policies/external-data-sources/#api-call | global context cache from external service calls ]] Which allows calling (and caching) external HTTP services that returns a JSON that can be used at policy evaluation time. However, with LDAP in particular, we would need some kind of HTTP/JSON frontend o return the mapping of account names and uids. This is only available starting with Kyverno 1.12 (and by the time of this writing, we are forced to use 1.10 because k8s version constraints)

In [[ https://github.com/kyverno/kyverno/issues/10458#issuecomment-2182348444 | talks with upstream kyverno maintainers ]], I discovered there is another approach we could take to introduce kyverno-based pod security controls. === Option 1 === * We could introduce a configmap, populated/updated via maintain-kubeusers, with data like this (a mapping of account name to uid): ``` data: tool-sometool: "1" tool-someothertool: "2" ``` * Using kyverno [[ https://release-1-10-0.kyverno.io/docs/writing-policies/external-data-sources/#variables-from-configmaps | variables from configmaps ]], we could have a single ClusterPolicy resource, that would lookup tool account uid in the configmap. * Crafing the ClusterPolicy to do this lookup may not be trivial, but the upside is that we would greatly reduce the kyverno workload and resources footprint in the cluster, from 3.5k policy resources (one in each tool account namespace) to a single one. However, configmaps have [[ https://kubernetes.io/docs/concepts/configuration/configmap/ | a hard limit of 1MB ]], so this may not scale well. === Option 2 === Another option is to use two other kyverno functions: * [[ https://kyverno.io/docs/writing-policies/external-data-sources/#variables-from-service-calls | variables from external service calls ]] * [[ https://kyverno.io/docs/writing-policies/external-data-sources/#api-call | global context cache from external service calls ]] Which allows calling (and caching) external HTTP services that returns a JSON that can be used at policy evaluation time. However, with LDAP in particular, we would need some kind of HTTP/JSON frontend o return the mapping of account names and uids. This is only available starting with Kyverno 1.12.12 (and by the time of this writing, we are forced to use 1.10 because k8s version constraints)