We recommend that users in larger environments limit the set of "identity-relevant" labels to avoid frequent creation of new security identities due to labels that are not useful for policy enforcement or visibility (e.g., timestamps, hashes, etc. that may change for each pod or version of an app).
This can be done using the labels field of the cilium-config ConfigMap . Labels are discussed at a high-level here (https://docs.cilium.io/en/v1.7/concepts/terminology/#security-relevant-labels), but the 'labels' field is not well documented, nor do we have good examples for example that show handling multiple labels, or using negation of labels.
In particular, multiple labels are specified as space separated in the config map (we have had users who assume it is comma separated".
Negation is a syntax like: !app-timestamp but if a "source", like "k8s:" is included, you actually have to put the negation AFTER the source (e.g., k8s:!app-timetamp) which has confused several users.
The following may ignore namespace labels --labels=!io.cilium.k8s.namespace.labels (need to validate)
Its also not clear exactly what type of a match is being performed here... it seems like it is not just exact match based on some examples I've seen. Is it is a prefix match, as there are no explicit regex or wildcard characters required?
Also, the text in https://docs.cilium.io/en/v1.7/concepts/terminology/#security-relevant-labels just needs a refresh in general to be more kubernetes-relevant (I think much of this text is still from the docker days). In particular, statements like: "For this purpose, the user is required to specify a list of string prefixes of meaningful labels" and "The standard behavior is to include all labels which start with the prefix id." do not seem accurate at all anymore. The current behavior with Kubernetes seems to be that we default include most labels, except for an explicit set of excluded labels.
Also, I don't think we document anywhere the set of default labels we ignore for kubernetes, such as "pod-template-hash". It seems that the code of which labels we automatically include, exclude is here:
It may also make sense to document common cases of problematic behavior, such as k8s cron jobs, and document how one can use filters to avoid many identities. The labels str in the config map to do this seems to be:
labels: "k8s:!controller-uid k8s:!job-name"
As a bonus, one could also expose a helm option to enable setting the labels in the config map, or is that already possible?
We recommend that users in larger environments limit the set of "identity-relevant" labels to avoid frequent creation of new security identities due to labels that are not useful for policy enforcement or visibility (e.g., timestamps, hashes, etc. that may change for each pod or version of an app).
This can be done using the
labelsfield of the cilium-config ConfigMap . Labels are discussed at a high-level here (https://docs.cilium.io/en/v1.7/concepts/terminology/#security-relevant-labels), but the 'labels' field is not well documented, nor do we have good examples for example that show handling multiple labels, or using negation of labels.In particular, multiple labels are specified as space separated in the config map (we have had users who assume it is comma separated".
Negation is a syntax like:
!app-timestampbut if a "source", like "k8s:" is included, you actually have to put the negation AFTER the source (e.g.,k8s:!app-timetamp) which has confused several users.The following may ignore namespace labels
--labels=!io.cilium.k8s.namespace.labels(need to validate)Its also not clear exactly what type of a match is being performed here... it seems like it is not just exact match based on some examples I've seen. Is it is a prefix match, as there are no explicit regex or wildcard characters required?
Also, the text in https://docs.cilium.io/en/v1.7/concepts/terminology/#security-relevant-labels just needs a refresh in general to be more kubernetes-relevant (I think much of this text is still from the docker days). In particular, statements like: "For this purpose, the user is required to specify a list of string prefixes of meaningful labels" and "The standard behavior is to include all labels which start with the prefix id." do not seem accurate at all anymore. The current behavior with Kubernetes seems to be that we default include most labels, except for an explicit set of excluded labels.
Also, I don't think we document anywhere the set of default labels we ignore for kubernetes, such as "pod-template-hash". It seems that the code of which labels we automatically include, exclude is here:
cilium/pkg/labelsfilter/filter.go
Line 163 in 2d34336
It may also make sense to document common cases of problematic behavior, such as k8s cron jobs, and document how one can use filters to avoid many identities. The labels str in the config map to do this seems to be:
labels: "k8s:!controller-uid k8s:!job-name"As a bonus, one could also expose a helm option to enable setting the
labelsin the config map, or is that already possible?