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. * We could introduce a configmap, populated/updated via maintain-kubeusers, with data like this: ``` 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.

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. * 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.

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. * 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.