kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
community/sig-auth/archive/meeting-notes-2020.md

65 KiB
Raw Blame History

Kubernetes Sig-auth Meeting Agenda

December 23 - CANCELLED

Cancelled for December holidays.

December 9, 11a - Noon (Pacific Time)

  • Recording
  • Announcements *
  • Demos *
  • Pulls of note *
  • Issues of note *
  • Designs of note *
  • Discussion topic
    • [ankeesler] Next steps for getting client-go credential plugins to GA
    • [ahmedtd] SPIFFE client certificate authentication to kube-apiserver: any existing designs / KEPs / work?
      • SPIFFE puts cert UID in CN, puts username in SAN
      • questions about what the mapping should be, questions about whether this is a thing that kube-apiserver should be aware of
      • suggest mailing https://groups.google.com/g/kubernetes-sig-auth in case there are people working in the area not in the meeting
    • [zshihang] Disable TokenController/Provide a per service account knob to disable.
      • can we have a per-service-account way to opt out of controller-created tokens for specific service accounts in lieu of bound service account tokens
      • general positive attitude toward making it possible to opt out; could be via a field on serviceaccount (or annotation, if there's hesitance on introducing API surface around a controller behavior we'd like to see dropped in the far future)
      • possible users:
        • Could allow internal platform providers to roll out a opinionated default in a gradual way via admission control (defined in a site-specific way)
        • kube-controller-manager opting out of secret-based tokens for controller manager service accounts
        • wonderful security-conscious users
        • Tim
    • [micahhausler] Knob to prevent nodes from creating mirror pods
    • [nckturner] client request signing (#92535)
      • consider looking into local authenticated proxy (kubectl -> local proxy -> apiserver)
      • concerns around exec plugin: performance, inventing a request signing API/standard
    • [tsable] Future of PodSecurityPolicy
      • Work toward initial proposal from Tabitha Sable, Ian Coldwater, et al ongoing
      • liggitt: would recommend starting public discussion as early as possible to make sure progress can be made early
      • liggitt: since the existing PodSecurityPolicy API is not graduating as-is, suggest marking deprecation in 1.21 (ahead of planned 1.22) to communicate to users they should not start using it if they aren't already. Would keep the planned removal at 1.25.
      • tsable: would like to reserve the right to move PSP removal out past 1.25 to allow seamless transition to new thing
      • liggitt: 1.25 is a significant distance away... don't want to commit to moving out removal; instead, would use that endpoint to motivate progress on the replacement
      • tallclair: while working on the design for the replacement, would be helpful to make clearer what threat models are being addressed by the replacement (container breakout, node compromise, etc) to avoid unbounded API surface
  • Action Items *
  • Sweep issues with leftover time

November 25 - CANCELLED

Cancelled for US Thanksgiving holiday.

November 11, 11a - Noon (Pacific Time)

October 28, 11a - Noon (Pacific Time)

  • Recording
  • Announcements
    • Code freeze for 1.20 is Nov 12th
  • Demos *
  • Pulls of note
    • 1.20-targeted PRs
      • Kubelet credential provider externalization - #94196
      • client-go exec auth plugin - #95489
      • csi service account token - #93130
  • Issues of note *
  • Designs of note *
  • Discussion topic
    • Close 1.20 loose ends:
      • Token* Beta/GA graduation
        • #95896: make the flags required for TokenRequest so that presubmits e2e tests can pass because the prow job is using kubeadm.
          • This may be deferred to post-GA.
          • AI: Reach out to owners of deployment automation + clouds. Ask if this would be painful.
        • #95886: add a general test and later will change it to conformance one in the TokenRequest GA pr.
          • We want this even if the flags aren’t made required in 1.20.
        • #93258: mv TokenRequest to GA. this will be reworked after the first two merged.
        • #95667: mv BoundServiceAccountToken beta. this will also be reworked after the first three merged.
    • FYI - label/metadata policy discussion happening in sig-arch
      • mailing list thread
      • summary doc
      • planned for discussion at next sig-arch meeting (11/5)
  • Action Items *
  • Sweep issues with leftover time

October 14, 11a - Noon (Pacific Time)

  • Meeting cancelled - empty agenda.

September 30, 11a - Noon (Pacific Time)

  • Meeting cancelled - empty agenda.

September 16, 11a - Noon (Pacific Time)

September 2, 11a - Noon (Pacific Time)

August 19, 11a - Noon (Pacific Time)

  • Meeting cancelled - empty agenda, people busy with kubecon and the last week of 1.19

August 5, 11a - Noon (Pacific Time)

  • Recording
  • Announcements *
  • Demos *
  • Pulls of note *
  • Issues of note *
  • Designs of note *
  • Discussion topic
    • [tallclair] Core label policy
      • Labels don’t necessarily grant or restrict permission.
      • UID policy in openshift
      • Delegation
        • Tim creates replicaset
        • Can Tim use restricted labels?
        • Pod OwnerRef/ControllerRef is set by replicasetcontroller
        • RC has restricted labels, so pod is either allowed or required to have restricted labels.
        • What about horizontal controllers? Something that swaps out an image on the replicaset?
        • Tie the object back to the subject that kicked off the chain of events.
      • This wouldn’t be enforced in authorization, probably admission.
        • There are other use cases where cluster scoped objects need to be subdivided.
          • CSR kind of needed this with signer name.
          • Might be useful with CRDs.
      • Policy attachment point:
        • RBAC? Labels aren’t known.
        • Gatekeeper?
        • Network policy?
      • Big win is to apply this to cluster scoped objects.
      • Mike: If I were to re-review I KEP:
        • I would like to understand how inheritance works. OwnerRef? What about inheritance from the namespace?
        • What is the authorization model for the super user that can add or remove labels at specific points?
        • What are the user stories that this enables? Gatekeeper? RBAC? Network Policy?
      • Greg: We need an understandable authorization model.
      • Deads: Namespace subdivision is hard to understand.
      • Tim: Maybe the hierarchical namespace controller will address some of the use cases that make people want namespace subdivision.
    • [zshihang] BoundServiceAccountTokenVolume Beta
      • https://github.com/kubernetes/enhancements/pull/1912
      • What to do about warn after is still an open question?
        • Do we pick a default silently or do we make warn after required?
      • Warn after was added in 1.19.
      • Deads: no choice is going to make it easy for people.
      • Jordan: We can also enable warn after for X releases by default, then disable it for X releases by default, then remove? We start getting some better security properties, people have time to migrate.
      • Mike: What do we do about token controller?
      • Liggitt: Leave it running until BoundServiceAccountTokenVolume is GA. We should consider this as a separate deprecation.
        • One option is to migrate token controller to use the TokenRequest API to populate secrets containing tokens (we thought about this at one point, which is why TokenRequest supports binding to a Secret object)
        • We may have a lot of users who are creating service accounts, watching for secrets, extracting the token. We don’t have good visibility into this. We want them to ultimately switch to TokenRequest API. Probably announce auto-created service account secrets as deprecated once TokenRequest GAs and point people to that.
      • Liggitt: TokenRequest API is probably ready for GA in 1.20.
  • Action Items *
  • Sweep issues with leftover time

July 22, 11a - Noon (Pacific Time)

  • Recording
  • Announcements *
  • Demos *
  • Pulls of note *
  • Issues of note
    • CSR API: cluster signing duration is not flexible and has unsafe defaulting #92678
      • Notes from discussion below
      • A single new .spec field targeted at the user, two possible approaches:
        • durationHint (when does the duration start?)
        • notAfterHint (exact time the cert should expire)
      • The CSR .spec field could be targeted via admission to enforce policy (though self hosted environments would need to be careful with Kubelet CSR flows by using static pods or hosting the webhook externally)
      • No new field targeted at the approver or the signer
      • Signer would choose to honor the field if it is able to (it is a hint, not a requirement or guarantee)
      • Next steps:
        • Create PR to update the existing CSR KEP with proposed changes
        • Use that PR to get consensus on the specifics of the API changes
        • Ping James Munnely for a review on the proposed changes since he missed this discussion and we want to ensure that cert-manager could use this API
        • After agreement on the API changes:
          • Create PR to update API (similar to signer name changes)
          • Update the built-in signers to honor the new API
      • Future:
        • A kubelet that is aware of this field and its own rotation could use the field to set the duration to a shorter amount of time
  • Designs of note *
  • Discussion topic
  • Action Items *
  • Sweep issues with leftover time

July 8, 11a - Noon (Pacific Time)

  • Canceled due to empty agenda
  • Code freeze is July 9th

June 24, 11a - Noon (Pacific Time)

  • Recording
  • Announcements
    • @jackkleeman -> Apple, expect delays on intermediate cert work while I figure the OSS process out
  • Demos
    • Seccomp Operator - Paulo [slides, issue]
    • Policy Report CRD (PR, doc) - Jim, Erica
  • Pulls of note
  • Issues of note *
  • Designs of note *
  • Discussion topic
    • move “k8s.io/kubernetes/pkg/registry/rbac/reconciliation” to staging
      • sig-cli: "We are planning to move kubectl to staging(tracking issue), but now it is being blocked as “kubectl auth” still relies on “k8s.io/kubernetes/pkg/registry/rbac/reconciliation”"
      • Potential obstacle: the reconciliation package imports other k/k code, such as “pkg/registry/rbac/validation” and “pkg/apis/core/helper”, and these packages import others. We might need to figure out how to make the reconciliation package self-included.
      • liggitt: initial effort at https://github.com/liggitt/kubernetes/commits/extract-rbac, got stuck on interface imports that currently live in k8s.io/apiserver (user.Info) or in kube-apiserver (RBAC validation)
        • would welcome someone picking this up and working through the import issues
      • deads2k: question about the destination repo/granularity (rbac-specific? auth-specific? "things that depend only on client+api+apimachinery" shared between
    • [micahhausler] Discussion on adding request signing support (a la AWS SigV4)
      • Tracking issue with thoughts: #92535
      • On server-side, can do it w/ front-proxy
      • Client side, can we be better than exposing the full http.RoundTripper interface to an external plugin?
      • Does per-cluster HTTP proxy work (supported in kubeconfig now via proxy-url field under cluster config)? Is it easy enough? Is kubectl proxy any better?
      • Would be nice to to have authentication options e.g. limited to “only get pods” or “only in this time”, etc.
    • [mo] next steps for External TLS certificate authenticator #1749?
      • liggitt: similar questions to the previous topic... is externalizing TLS the right approach, or is routing through a client-side proxy sufficient to allow custom TLS behavior?
      • AI:
  • Action Items *
  • Sweep issues with leftover time

June 10, 11a - Noon (Pacific Time)

  • Recording
  • Announcements *
  • Demos *
  • Pulls of note
  • Issues of note *
  • Designs of note *
  • Discussion topic
    • [mo] CSR API questions
      • Custom MaxTTLHint?
        • i.e. for the built-in signers, can a user request a cert that is shorter lived than the 1 year default (which is problematic since we lack any form of revocation)
        • We state “Expiration/cert lifetime - minimum of CSR signer or request. Sanity of the time is the concern of the signer.”
        • But we do not expose any per signer config, just a single “--cluster-signing-duration”
        • Safe duration of client certs vs serving certs - long lived serving certs are probably okay but irrevocable client certs that assert an identity against the Kube API for a year by default seems like a bad idea
      • Support flow via public key and CSR template without requiring a signed CSR?
        • i.e. I want to issue a cert for a specific client without need the client’s private key
        • Currently if you do not want the client to directly be able to create CSRs, you have to give the CSR template to the client, ask it to sign it, and then submit the CSR on the client’s behalf
      • Support turning off individual signers to make it easier not to have to deploy a custom signer
        • Writing custom signers for built-in signer names is hard
        • Enable/disable built-in signers individually
    • Kubelet serving certificate rotation questions
      • feature not planned to GA for 1.19 because of open questions
      • little-to-no guidance for approving SANs
      • possible kubelet misbehavior when issued certs that don't match SANs (experience report from mhausler)
      • liggitt: in 1.20, strengthen documentation of requirements, consider ways to improve kubelet behavior to avoid many unapproved/unissued CSRs being created
    • [ao] Secret Type questions
    • [mvladev] Accessing OIDC discovery endpoint of the apiserver when ServiceAccountIssuerDiscovery feature gate is enabled and --anonymous-auth=false is set on the API server question
      • for anonymous discovery clients to fetch the data from the API server, it must allow anonymous requests
      • the issuer URL can be set to a different endpoint that is available anonymously (like a public storage bucket), and you could extract discovery/keyset info from the apiserver with a credentialed client and push the discovery/keyset data to that bucket. This also has the benefit of making the discovery data available even when the API server is not available.
  • Action Items *
  • Sweep issues with leftover time

May 27, 11a - Noon (Pacific Time)

May 13, 11a - Noon (Pacific Time)

  • Recording
  • Announcements *
  • Demos *
  • Pulls of note *
  • Issues of note *
  • Designs of note
    • Managed CA Bundles
  • Discussion topic
    • **[start with this] **Continue discussion around next steps for dynamic audit webhooks
      • Dynamic audit proxy webhook design
      • Dynamic webhook sinks with static policy
      • [mo] Invert the sink model from push to pull, rough sketch:
        • external sink scrapes API server audit logs similar to prometheus metrics / watch
        • Similar designs: #53455, #64494, community#2241
        • API server could just write event stream to a file and expose the file through a streaming API
          • IO bound
          • Limited CPU use, just stream (gzipped) bytes over network
          • File would be non-human readable and structured for fast processing by the API server, i.e. limited metadata (i.e timestamp) for any filtering and the associated bytes of the audit event
          • File could be encrypted using some transient in-memory key - the file would be “lost” on every restart of the API server (this would prevent concerns around storing sensitive data on disk)
          • File could be stored on tmpfs
          • File would be automatically truncated after it reached some “reasonable” size such as 1 GB
        • HA API servers seems to be biggest issue
          • API server serving the request would need to contact the other servers and multiplex their stream through to the client
      • [mo] does it make sense to support a binary format for audit events?
      • Enhancements freeze for v1.19 is May 19 so it would be great to have a decision on the future roadmap from dynamic audit by then
      • Thoughts on progressing current sink-only impl to beta/ga
        • liggitt: seems like 1/3 of a solution: provided dynamic sinks, but without understanding of what events will be sent to the sink (no policy), and with at least some existing distributors not planning to enable it as-is. There's been a lot of effort put into trying to figure out the policy and security aspects to define a path to GA, without much success.
        • deads2k: configuring dynamic sinks to receive unknown events (since there's no policy) is difficult to reason about and hard to support
        • micah: performance concerns around increasing audit event destinations, little customer demand to date for dynamic sinks
        • mikedanese: security concerns about sending unfiltered audit events to arbitrary sinks in GKE
      • AI: tallclair to start draft of email to (sig-auth, kubernetes-developers?, ...) describing intent to remove in-tree alpha sink API/impl in 1.19
    • (time permitting) kubernetes/enhancements#1689 Dynamic Authentication Config
    • [mo] should the credential exec plugin API include an “installHint” help string in the ExecConfig struct
      • Unable to connect to the server: getting credentials: exec: exec: "exec-binary-foo": executable file not found in $PATH
      • Could be improved to “you need to install exec-binary-foo via brew install exec-binary-foo …”
      • Not sure if this quality of life improvement is worth an API change
  • Action Items *
  • Sweep issues with leftover time

April 29, 11a - Noon (Pacific Time)

April 15, 11a - Noon (Pacific Time)

April 1, 11a - Noon (Pacific Time)

  • Recording

  • Announcements *

  • Demos *

  • Pulls of note *

  • Issues of note *

  • Designs of note *

  • Discussion topic

    • [tallclair] Deprecation timeline for RBAC
    • [jack] Intermediate certificates in certificates API #1615
      • [mike]
        • Intermediates across different cluster’s nodes?
      • [deads]
        • how to expose information (structure)
        • How is this information normally exposed?
        • Support more intermediates than immediate signer in chain
        • Support for multiple signers (different private keys) via the built in controller-manager
      • [jack]
        • Want to avoid magic/inference to determine what signed the cert
        • AI(jack): describe the problem around file format/intermediates so we can get folks with more x509 experience to see what makes sense
    • [mo] remove openstack auth plugin
    • [mo] Deprecate all kubectl authn plugins except oidc and exec -> general feeling was that on the same release we GA this API, we deprecate the gcp and azure plugins which starts the one year timeline for removal from kubectl
    • [mo] Related to above, get exec to GA
      • Per the KEP, it went beta in 1.11
        • This is listed as a GA requirement “support for remote TLS handshakes (e.g. TPM/KMS-hosted keys)”
          • This requirement was deemed unrelated to the rest of the functionality
      • Feedback from users
        • Matt Moyer noted that it is hard to pass information about the cluster to the exec plugin (hostname, CA, audience, etc)
      • Implementations - there seem to be 10ish
        • [mo] We should update the kube docs to include the list of known implementations to make them easier to find
          • Puts sig-auth in a gatekeeper role?
          • Security review implications of “blessed” plugins
          • kubectl / sig-cli owns this list?
          • Part of kpt?
      • Open issues? (need to be address before GA)
    • Audit annotations from authentication #89305
      • We should not worry about outbound annotations (i.e. defer in the authentication stack)
      • Per Tim, Alex’s PR on metrics from authenticators #88777 should use audit annotations

  • Action Items *

  • Sweep issues with leftover time

March 18, 11a - Noon (Pacific Time)

March 4, 11a - Noon (Pacific Time)

February 19, 11a - Noon (Pacific Time)

February 5, 11a - Noon (Pacific Time)

January 22, 11a - Noon (Pacific Time)

  • Canceled due to empty agenda

January 8, 11a - Noon (Pacific Time)