Skip to content
Switch branches/tags
Go to file
Cannot retrieve contributors at this time

2021 Annual Report: SIG Auth

Current initiatives

  1. What work did the SIG do this year that should be highlighted?

    • Pod Security admission has graduated to beta and is enabled by default. The admission configuration version has been promoted to in v1.23.
    • The PodSecurityPolicy API is deprecated in v1.21, and will no longer be served starting in v1.25.
    • Marking[alpha|beta]1 versions as deprecated and warning if a version other than was passed to the kube-apiserver flags --audit-log-version and --audit-webhook-version in v1.21.
    • PodSecurityPolicy only stores "generic" as allowed volume type if the GenericEphemeralVolume feature gate is enabled
    • RunAsGroup feature for Containers in a Pod graduates to GA in v1.21
    • RootCAConfigMap feature graduates to GA in v1.21
    • The ServiceAccountIssuerDiscovery feature has graduated to GA, and is unconditionally enabled in v1.21.
    • CSIServiceAccountToken graduates to GA in 1.22
    • Mark net.ipv4.ip_unprivileged_port_start as safe sysctl in v1.22
    • BoundServiceAccountTokenVolume graduates to GA in v1.22
    • Kubernetes client credential plugins feature graduates to stable in v1.22. The GA feature set includes improved support for plugins that provide interactive login flows. The in-tree Azure and GCP authentication plugins have been deprecated in favor of out-of-tree implementations.
    • Kube-apiserver --service-account-issuer can be specified multiple times now, to enable non-disruptive change of issuer starting v1.22
    • The API supports an optional expirationSeconds field to allow the client to request a particular duration for the issued certificate. The default signer implementations provided by the Kubernetes controller manager will honor this field as long as it does not exceed the --cluster-signing-duration flag starting v1.22.
    • Aggregate write permissions on events to edit and admin role starting v1.22
    • The kubelet now reports distinguishes log messages about certificate rotation for its client cert and server cert separately to make debugging problems with one or the other easier.starting v1.22
    • A new field omitManagedFields has been added to both audit.Policy and audit.PolicyRule so cluster operators can opt in to omit managed fields of the request and response bodies from being written to the API audit log starting v1.23
    • Adds --as-uid flag to kubectl to allow uid impersonation in the same way as user and group impersonation starting v1.23
  2. What initiatives are you working on that aren't being tracked in KEPs? SIG Auth leads have curated and broadcasted a list of work from the Needs KEP swimlane out of the #sig-auth board in the Needs KEP / release work #sig-auth living document. The call-out to the community is a way of looking for folks to both lead the design work necessary to get these KEPs into an implementable state, as well as to land the implementation into the Kubernetes codebase. Specifically:

    • KMS-Plugin: Improvements
    • Specifying multiple webhooks in the kube-apiserver authorization chain
    • Structured config for OIDC authentication
    • Audit logging improvements
    • system:masters rename
  3. KEP work in 2021 (1.x, 1.y, 1.z):

Project health

  1. What areas and/or subprojects does your group need the most help with? Any areas with 2 or fewer OWNERs? (link to more details)

    The Needs KEP / release work #sig-auth document lists multiple areas that need help and some currently have volunteers working on them.

  2. What metrics/community health stats does your group care about and/or measure?

  3. Does your help new contributors engage with your group specifically by pointing to activities or programs that provide useful context or allow easy participation?

    • Currently there is no onboarding or growth path. This is something we are working on and learning from other SIGs.
  4. If your group has special training, requirements for reviewers/approvers, or processes beyond the general contributor guide, does your document those to help existing contributors grow throughout the contributor ladder?

    • Currently there is no onboarding or growth path. This is something we are working on and learning from other SIGs.
  5. Does the group have contributors from multiple companies/affiliations?

    • Yes. Our chairs, leads, contributors, participants, and subproject owners are from various companies.
  6. Are there ways end users/companies can contribute that they currently are not? If one of those ways is more full time support, what would they work on and why?


  • Primary slack channel member count: 2463
  • Primary mailing list member count: 470
  • Primary meeting attendee count (estimated, if needed): 20 ~ 30
  • Primary meeting participant count (estimated, if needed): 5 ~ 10
  • Unique reviewers for SIG-owned packages: 11
  • Unique approvers for SIG-owned packages: 4

Include any other ways you measure group membership


New in 2021:


Working groups



Operational tasks in

  • reviewed for accuracy and updated if needed
  • reviewed for accuracy and updated if needed (or created if missing and your contributor steps and experience are different or more in-depth than the documentation listed in the general contributor guide and devel folder.)
  • Subprojects list and linked OWNERS files in sigs.yaml reviewed for accuracy and updated if needed
  • SIG leaders (chairs, tech leads, and subproject owners) in sigs.yaml are accurate and active, and updated if needed
  • Meeting notes and recordings for 2021 are linked from and updated/uploaded if needed
  • Did you have community-wide updates in 2021 (e.g. community meetings, kubecon, or kubernetes-dev@ emails)? Links to email, slides, or recordings: - 2021 Kubecon NA Virtual - PSP is Dead, Long Live PodSecurity session recording