Skip to content

Latest commit

 

History

History
644 lines (517 loc) · 40.4 KB

meeting-notes-2019.md

File metadata and controls

644 lines (517 loc) · 40.4 KB

Kubernetes Sig-auth Meeting Agenda

December 25, 11a - Noon (Pacific Time)

  • Canceled due to winter holidays

December 11, 11a - Noon (Pacific Time)

  • Recording
  • Announcements *
  • Demos *
  • Designs of note
  • Pulls of note
  • Issues of note *
  • Discussion topic
    • [gcastle] Bringing an internal Google discussion to sig-auth audience: can we do better than file-system mounted secrets inside core K8s? Ideally filesystem information leaks (directory traversal bugs) wouldn’t result in secrets lost to bad guys. Christoph Kern to join us as a guest speaker.
      • Desire to provide applications with an alternate way to obtain secrets without exposing secrets in files easily vulnerable to directory traversal
      • Potential directions
    • [seh] Related: Following discussion on Slack, how can CSI drivers more securely acquire service account tokens from the pods into which they’re mounting? Mike Danese suggested that the kubelet should fetch attenuated tokens to hand to the CSI driver, rather than either forcing the driver to grovel around on the filesystem looking for tokens or having the driver request the tokens via the TokenRequest API.
      • seh: look around the filesystem :(
      • Tim: CSI driver creates TokenRequest directly
      • Global CSI Driver object. Is that a good spot? Are those objects usually locked down? Kubelet passes CSI Driver token with some globally configured audience.
  • Action Items *
  • Sweep issues with leftover time

November 27, 11a - Noon (Pacific Time)

  • Canceled due to proximity with Thanksgiving

November 13, 11a - Noon (Pacific Time)

  • Canceled due to proximity with 1.17 code freeze

October 30, 11a - Noon (Pacific Time)

October 16, 11a - Noon (Pacific Time)

  • Recording
  • Announcements
  • Demos *
  • Pulls of note *
  • Issues of note
    • Dynamic Audit Policy
      • we've started this design a few times, and ended up with very complex approaches multiple times
      • Tim wanted to ask some more fundamental questions to help focus the design
      • to make progress, likely need to have dedicated synchronous time to work through the design
        • Should we schedule some time at KC NA?
      • dimensions:
        • noise (e.g. events)
          • cluster admin filters things they consider noisy (or resource authors?)
          • webhooks can opt into more noise?
        • sensitivity (e.g. secret request/response contents?)
          • indicate sensitivity per resource?
            • built-in resources like secrets
            • custom resource authors
          • could inform things like
            • encryption at rest
            • allowed audit levels for webhook
          • cluster admin indicates things they consider sensitive that may not be sent to audit webhooks?
          • webhooks cannot opt into receiving sensitive info the cluster admin has disallowed?
          • need to be careful not to mislead webhooks (they think they registered to receive events, but don't get them at all because the cluster-admin disabled a specific resource)
      • areas of focus for debug
        • everything (interactions between namespaces/users)
        • namespace-focused
        • user-focused
      • Action items:
        • look at previously discussed use cases in light of the noise/sensitivity dimensions
        • consider whether use cases could be addressed with a trusted sink that receives everything and filters (identify gaps that would prevent that approach). most likely limit of backend-based filtering would be scale, but if an API and implementation was proved as a backend, it could be brought into the API server to address scale concerns
        • follow up with api-machinery on possibility of indicating sensitivity at a resource level
  • Designs of note
  • Discussion topic *
  • Action Items *
  • Sweep issues with leftover time

October 2, 11a - Noon (Pacific Time)

September 18, 11a - Noon (Pacific Time)

  • Recording
  • Issues of note
  • Designs of note
    • Extended NodeRestrictions for Pods
      • question about whether we should enforce policy on labels outside k8s.io/kubernetes.io prefixes (node self-labeling doesn't enforce policy
      • limiting ownerReferences makes sense (mirror pods shouldn't have controller:true references)
      • limiting annotations seems speculative. should we lean on webhook admission protections instead?
      • compatibility questions (things like network plugins setting annotations on pod status update using kubelet creds?)
    • Certificates KEP
      • ready for initial merge to capture current state
      • follow up to work through GA/v1 requirements
  • Discussion topic
    • 1.17
      • Token request to GA?
        • Merged KEP
        • Update docs
          • API/usage doc
          • Define structure of SA tokens as not opaque
          • Key ID docs?
        • Promote existing e2es to conformance?
          • Requires API server invocation changes to be conformant
        • Gather feedback on usage
          • Istio
          • AWS
          • linkerd wants to
        • Feature requests
          • arbitrary claims (#61795)
          • pluggable signer backend (#704)
        • Vault CSI driver
          • In progress
        • Vault auth backend
          • Change token review url to point at new version
      • Plans for SA token volume projection?
        • Performance numbers around large clusters
        • volume projection issues with permissions/fsGroups interactions
        • client readiness (refreshing behavior across libraries)
          • Some numbers around community adoption?
        • docs/breadcrumbs for people encountering new behavior
          • improve message from service account token authenticator when using an expired token to point to solution
          • ensure docs for components needing to update their client libraries that match the more informative error message so they are discoverable
          • ensure docs for users encountering expired errors second-hand via apps/components they do not control
        • method for gathering metrics about whether workloads are refreshing tokens correctly?
          • maybe mint tokens with long lifetimes, but continue refreshing every 10 minutes, expose metrics or audit info when tokens older than 10 minutes are presented (means a particular workload isn't refreshing tokens correctly)
          • Expose metrics on successful refreshes
      • Dynamic audit policy
      • Extended NodeRestrictions for Pods
      • External Projected Token Creation
      • OIDC Issuer URL (link fixed)
    • Dynamic audit policy: call for comments, short proposal overview, roadmap /can do that in the slot above too - Georgi
  • Action Item:
    • Mike to file an issue for things that need to be done for Vault kubernetes-credential-backend
  • Sweep issues with leftover time

September 4, 2019, 11a - Noon (Pacific Time)

  • Cancelled, empty agenda

August 21, 2019, 11a - Noon (Pacific Time)

August 7, 2019, 11a - Noon (Pacific Time)

July 24, 2019, 11a - Noon (Pacific Time)

  • Recording
  • Announcements
    • Requesting feedback on what folks would like to see covered in KubeCon NA 2019 (San Diego) SIG Auth deep dive (please respond to thread on mailing list)
    • Options
      • Walkthrough of OPA/gatekeeper?
        • Refactor of PSP
        • [Mo] what does policy wg talk about?
        • PSP might be a good option to talk about at contributor summit.
      • Authentication (client exec plugin, webhook)
      • RBAC?
        • Maybe not a topic by itself
      • Certificates API, approvers
      • Audit webhook
        • Audit policy API
      • Node authorizer, node admission
  • Demos *
  • Pulls of note *
  • Issues of note *
  • Designs of note *
  • Discussion topic
    • Audit policy use cases & requirements
      • Doc going to mailing list
      • Discussion punted for next meeting
  • Action Items *
  • Sweep issues with leftover time

July 10, 2019, 11a - Noon (Pacific Time)

June 26, 2019, 11a - Noon (Pacific Time)

  • Recording

  • Announcements

    • Requesting feedback on what folks would like to see covered in KubeCon NA 2019 (San Diego) SIG Auth deep dive (please respond to thread on mailing list)

  • Demos

  • Pulls of note *

  • Issues of note *

  • Designs of note *

  • Discussion topic

  • Action items

    • As part of the key ID changes to SA, we should consider if all SA tokens should no longer be considered opaque

  • Can sweep unassigned issues with leftover time

June 12, 2019, 11a - Noon (Pacific Time)

  • Recording
  • Announcements *
  • Pulls of note *
  • Issues of note *
  • Designs of note
  • Discussion topic
    • [@jackkleeman] certificate rotation for more cluster components
      • Is a kubelet style approach appropriate where perhaps you provide an initial cert and then the application keeps it fresh using CSR API
      • Could the controller sign any csr requested by an entity with the exact same username and group, if they have a special role.
      • Instead, could we perhaps just allow the reload of certs from disk on a signal
        • this is the preferred first step, more reusable, allows integration with a broader variety of PKIs
    • [@ahmedtd, @mikedanese] Add Key IDs to access tokens kubernetes/kubernetes#78502
      • Follow up with @mo
      • Note it in OpenID Connect discovery doc
  • Can sweep unassigned issues with leftover time

May 29, 2019, 11a - Noon (Pacific Time)

  • Cancelled, empty agenda

May 15, 2019, 11a - Noon (Pacific Time)

  • Cancelled, empty agenda

May 1, 2019, 11a - Noon (Pacific Time)

April 17, 2019, 11a - Noon (Pacific Time)

  • Recording
  • Announcements *
  • Pulls of note *
  • Issues of note:
  • Designs of note
  • Discussion topic
    • Gatekeeper presentation & status update
      • slides
      • pain points:
        • dynamic restmapper, watch management
    • [haiyanmeng] KEP for Node-scoped DaemonSet
    • [liggitt] split RBAC reconcile/evaluation to staging repo
      • for consumption by [kubectl auth reconcile](https://github.com/kubernetes/kubernetes/pull/74879#issuecomment-478675341), other external consumers
      • mailing list thread
  • Can sweep unassigned issues with leftover time

April 3, 2019, 11a - Noon (Pacific Time)

  • Recording
  • Announcements *
  • Pulls of note *
  • Issues of note:
  • Designs of note
  • Discussion topic
    • [destijl] Discouraging use of secrets in environment variables
      • for kube
        • update API docs to indicate security issues
        • remove any use from actual kube artifacts
        • when included in examples, accompany with caveats
        • Beyond docs:
          • We likely want some way to programmatically discourage and enforce policy for secrets in env vars. It probably needs to be applicable per namespace, rather than per cluster.
          • Current feeling is that solving this outside K8s using something like OPA would make some sense.
      • for knative
        • consider ways to enable but require users to be aware of security issues (naming of API to include "insecure", etc?)
    • [tallclair] RuntimeClass supported features & policy
      • "what does the runtime support?" vs "what is the user allowed to do?"
      • E.g. gvisor doesn’t allow host networking on purpose, they don’t want people thinking they are sandboxed but allowed to poke a dangerous hole. While gvisor could support host networking, they don’t want to.
      • Windows pods: want to fail fast if they request linux features.
      • If you request apparmor in selinux pod will fail, reverse isn’t true. Some inconsistency there.
      • Runtimeclass admission control validation that handles these separately? Do plan to add that for: injecting pod overhead (WIP), scheduling (tolerations, KEP exists).
      • Do I want to write pods that target multiple runtimeclasses? Default runtimeclass so I don’t care as a pod author? Plan to handle defaulting through PSP. Maybe runtimeclass selection: “support for windows”, “support for GPUs” etc.
      • Should pod authors target by name the runtimeclass? Expect to do nothing? Will windows add a runtimeclass?
      • [clayton] We may want a completely separate podspec for windows.
    • [liggitt] starting KEP for Certificate Signing Request (CSR) to v1
  • Can sweep unassigned issues with leftover time

March 20, 2019, 11a - Noon (Pacific Time)

March 6, 2019, 11a - Noon (Pacific Time)

February 20, 2019, 11a - Noon (Pacific Time)

  • Cancelled, empty agenda

February 6, 2019, 11a - Noon (Pacific Time)

  • Cancelled, empty agenda

January 23, 2019, 11a - Noon (Pacific Time)

  • Recording
  • Announcements
  • Demos
  • Pulls of note
  • Designs of note *
  • Discussion topics
    • Discuss/review GMSA KEP for Windows - Deep Debroy (@ddebroy)/Jeremy Wood (@jeremywx)/Jean Rogue (@jean)
    • [@pbarker] APIserver authentication to webhooks KEP kubernetes/enhancements#658
      • Add comparison/discussion of existing kubeconfig-based mechanism for admission webhooks
      • Add discussion of audience determination
    • Discuss KEP requirements and timeline for the 1.14 release (@marpaia)
      • sig-release: all enhancements for 1.14 must have a reviewed/approved/merged (and implementable?) KEP by feature freeze on 1/29
      • Old enhancements already in progress need a KEP that includes graduation criteria, testing plan (see the KEP template for relevant checklists)
      • Assistance available from sig-release
    • 1.14 plans/priorities (add your name to items you plan to work on/participate in)
      • Work through blockers to CSR API promotion - #69836 (@liggitt, @krmayankk)
        • Divide items in that issue into required-for-v1 vs possible-for-v2
        • Work on KEP with roadmap during 1.14, plan to start API updates in 1.15
      • Kubelet Client/Serving cert rotation graduation (@liggitt, @krmayankk)
        • Pull kubelet client cert rotation into KEP format for 1.14, ensure testing/docs are sufficient, push to graduate for 1.14
        • Pull kubelet server cert rotation into KEP format, promote existing alpha CI tests to always run, consider graduating for 1.14 if ready in time
      • Webhook auth - doc, kep (@pbarker?, @liggitt, @krmayankk)
      • CVE-2018-1002105 post-mortem action items (@dekkagaijin)
      • Transition SA controller clients to TokenRequest API #71275 (@enj)
      • RunAsGroup to beta (Currently not clear what blockers we have to make this change) . I opened the following test issues for CI (#72287, #72253) (@krmayankk)
        • No known blockers, work through the checklist for graduation/test
      • External JWT signing support (#73110) (@micahhausler)
        • Motivations:
          • update signing keys without restart
          • avoid secret material on disk
          • allow offloading of token signing
      • Support configurable ProjectedTokenVolume rotation period (#73221) (@micahhausler)

January 9, 2019, 11a - Noon (Pacific Time)

cancelled for zoom outage :(