Audit Annotations
This page serves as a reference for the audit annotations of the kubernetes.io
namespace. These annotations apply to Event
object from API group
audit.k8s.io
.
Event
from API group audit.k8s.io
.
The annotations apply to audit events. Audit events are different from objects in the
Event API (API group
events.k8s.io
).pod-security.kubernetes.io/exempt
Example: pod-security.kubernetes.io/exempt: namespace
Value must be one of user
, namespace
, or runtimeClass
which correspond to
Pod Security Exemption
dimensions. This annotation indicates on which dimension was based the exemption
from the PodSecurity enforcement.
pod-security.kubernetes.io/enforce-policy
Example: pod-security.kubernetes.io/enforce-policy: restricted:latest
Value must be privileged:<version>
, baseline:<version>
,
restricted:<version>
which correspond to Pod Security
Standard levels accompanied by
a version which must be latest
or a valid Kubernetes version in the format
v<MAJOR>.<MINOR>
. This annotations informs about the enforcement level that
allowed or denied the pod during PodSecurity admission.
See Pod Security Standards for more information.
pod-security.kubernetes.io/audit-violations
Example: pod-security.kubernetes.io/audit-violations: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "example" must set securityContext.allowPrivilegeEscalation=false), ...
Value details an audit policy violation, it contains the Pod Security Standard level that was transgressed as well as the specific policies on the fields that were violated from the PodSecurity enforcement.
See Pod Security Standards for more information.
authorization.k8s.io/decision
Example: authorization.k8s.io/decision: "forbid"
This annotation indicates whether or not a request was authorized in Kubernetes audit logs.
See Auditing for more information.
authorization.k8s.io/reason
Example: authorization.k8s.io/reason: "Human-readable reason for the decision"
This annotation gives reason for the decision in Kubernetes audit logs.
See Auditing for more information.
missing-san.invalid-cert.kubernetes.io/$hostname
Example: missing-san.invalid-cert.kubernetes.io/example-svc.example-namespace.svc: "relies on a legacy Common Name field instead of the SAN extension for subject validation"
Used by Kubernetes version v1.24 and later
This annotation indicates a webhook or aggregated API server
is using an invalid certificate that is missing subjectAltNames
.
Support for these certificates was disabled by default in Kubernetes 1.19,
and removed in Kubernetes 1.23.
Requests to endpoints using these certificates will fail. Services using these certificates should replace them as soon as possible to avoid disruption when running in Kubernetes 1.23+ environments.
There's more information about this in the Go documentation: X.509 CommonName deprecation.
insecure-sha1.invalid-cert.kubernetes.io/$hostname
Example: insecure-sha1.invalid-cert.kubernetes.io/example-svc.example-namespace.svc: "uses an insecure SHA-1 signature"
Used by Kubernetes version v1.24 and later
This annotation indicates a webhook or aggregated API server is using an insecure certificate signed with a SHA-1 hash. Support for these insecure certificates is disabled by default in Kubernetes 1.24, and will be removed in a future release.
Services using these certificates should replace them as soon as possible, to ensure connections are secured properly and to avoid disruption in future releases.
There's more information about this in the Go documentation: Rejecting SHA-1 certificates.