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-2017.md

54 KiB
Raw Blame History

Kubernetes Sig-auth Meeting Agenda

December 27, 2017 - No meeting, Christmas holiday

December 13, 2017, 11a - Noon (Pacific Time)

  • Recording
  • Announcements
    • Code freeze lifts today
    • kubernetes-wg-multitenancy - google group
  • Demos
  • Pulls of note
    • User-facing RBAC policies for NetworkPolicy - #56650 (already approved)
  • Designs of note
  • Needs review:
    • Encryption at rest: KMS gRPC plugin - #55684
      • AI: sig-architecture office hours
    • Rules review: express denies and add webhook support - #53922
    • Reducing scope of node on node actions - community#911

November 29, 2017, 11a - Noon (Pacific Time)

Canceled due to release crunch and lack of agenda items.

November 15, 2017, 11a - Noon (Pacific Time)

  • Recording
  • Announcements
    • Code freeze is coming Nov 22nd.
  • Demos
  • Pulls of note
    • Kubectl OpenID Connect login (1.10) - #55514
      • Separate login and rotation
      • Figure out out of tree login/rotation
    • KMS gRPC plugin (1.10) - #55684
      • Concerns about another plugin mechanism
      • Make sure that API machinery/API reviewers see this
    • Allow nodes to impersonate service accounts of pods - #55019
      • Part of a prototype for pod identity
  • Designs of note
  • Discussions
    • RBAC: way to provide extra context like the node authorizer?
      • E.g. field selector and label selector
      • Node authorizer doesn't get additional data about the request, still requires admission controller.
      • Still possible to create something externally that builds a graph and creates RBAC roles. E.g. ingress secrets for an ingress controller
      • Help solve the ingress problem: https://github.com/kubernetes/ingress-nginx/issues/816
      • Action item: Review secrets roadmap for 1.10

November 1, 2017, 11a - Noon (Pacific Time)

October 18, 2017, 11a - Noon (Pacific Time)

October 4, 2017, 11a - Noon (Pacific Time)

  • Recording
  • Announcements
    • 1.8 release retrospective this week, 10/6 at 10a PST - agenda
  • Demos
  • Pulls of note
    • CSR Cleanup Controller - #51840
    • PodSecurityPolicy ordering, non-mutation - #52849
  • Designs of note:
    • Reduce scope of node on node object (kubernetes/community#911)
      • Needed to prevent a node from getting a serving cert for another node
      • Need to make sure that version skewed kubelets don't self-destruct (n-2)
      • Could use a cloud provider initializer/controller to provide the information about serving cert.
    • Vault KMS provider (kubernetes/community#888)
    • Verifying Workload JWTs
      • Minting short lived JWTs with audiences
      • Can't be used to talk to Kubernetes API, e.g. you could verify your identify without giving your access
      • Two possible models:
        • Decentralized (built up from container identity)
        • Centralized (request to API server for a short lived JWT)
      • Request: feedback on which model we'd prefer
  • 1.9 planning
  • Discussions
    • (if we have time) [jbeda] Appropriate usage of TokenReview API
      • Designed for delegated token authentication in the same auth domain (API -> webhook, kubelet -> API, extension server -> core API server)
      • Not intended to promote using kube API tokens as authentication to systems outside the API auth domain

Attendees:

  • Joe Beda, Matt Moyer -- Heptio
  • Steven E. Harris — IBM
  • Others?

September 20, 2017, 11a - Noon (Pacific Time)

  • Recording
  • Pulls of note
    • #52367 - PSP config, looks dependent on 50169
    • #52654 - Add pod disruption budgets to admin/edit/view roles
  • Designs of note: * Vault KMS Provider - Likely for 1.9. Comments so far look minor, request for reviews * Needs the plugin mechanism to work since vault isn't a cloud provider, see #48574 for background discussion * deads to follow up with api machinery
    • Verifying Workload JWTs
      • Minting short lived JWTs with audiences
      • Can't be used to talk to Kubernetes API, e.g. you could verify your identify without giving your access
      • Two possible models:
        • Decentralized (built up from container identity)
        • Centralized (request to API server for a short lived JWT)
      • Request: feedback on which model we'd prefer
  • Discussions
    • cert-manager project for automatic acquisition and renewal of x509 certificates for TLS in Kubernetes from a variety of issuing sources / incubator proposal - @munnerz
      • Note: incubator was recently frozen until after the election
      • Several existing projects were focused on ingress TLS through ACME
        • kube-lego, kube-cert-manager, kubernetes-letsencrypt
      • Similar API to the certificates API through CRDs
      • Acts as a ACME style issuer
    • support unequivocal DENY in union authorizer
      • General agreement on supporting this
      • Would like to see how it's actually hooked up
      • Questions about just switching authorizer to AND instead of OR

September 6th, 2017, 11a - Noon (Pacific Time)

Canceled due to release crunch and lack of agenda items.

August 23th, 2017, 11a - Noon (Pacific Time)

  • Recording
  • Announcements
    • Container identity working group meets Friday 11am EST
    • Code freeze on September 1st
  • Demos
    • SPIFFE + SPIRE overview (Evan Gilman, Scytale) ~20 min
      • SPIFFE (https://spiffe.io/, https://github.com/spiffe/spiffe)
        • Standard for service identity and credentials (x509)
        • spiffe://example.com/foo/bar <- SVID
        • API endpoint to get private keys and public certs (ca bundle a caller should trust). Doesn't specify auth-n/z of API.
        • Istio uses SVID as identity, doesn't implement workload API
      • SPIRE (will be open sourced in the future)
        • Implementation of SPIFFE
        • Node agent that has to attest to a central "control plane"
        • Node agent can then request credentials for workloads
      • SPIRE + kube
        • Few possible thoughts for "this pod is running on this node"
          • SPIRE shim for workload registration
          • Admission controller
          • Kubelet "plugin"
        • Node attestation
          • SPIRE-based, SPIRE attests for kubelet
          • Kubernetes-based, kubelet attests for SPIRE agent
        • Workload attestation
      • SPIFFE + kube
      • Source: https://docs.google.com/presentation/d/1C49epueLEjsv8QsQ36EoWbK9EuIHvbocGMu1vGmIGNo/edit?usp=sharing
  • Pulls of note
    • Bootstrap token extra groups (#50933)
    • Client cert rotation to beta (#51045)
    • Configurable OIDC value prefixes (#50875)
    • Google cloud KMS provider (#48574)
  • Designs of note:
    • Reduce scope of node on node object (kubernetes/community#911)
      • Needed to prevent a node from getting a serving cert for another node
      • Need to make sure that version skewed kubelets don't self-destruct (n-2)
      • Could use a cloud provider initializer/controller to provide the information about serving cert.
    • Vault KMS provider (kubernetes/community#888)
      • Greg read it and had a question about authentication backends. How do you plug in different authentication backends? Kube changes needed?
  • Discussion
    • SelfSubjectRulesReview going into a v1 API group? (@ericchiang) (#48051)
      • Known and learned from openshift
      • Never persisted (eliminates the migration concern)
      • Only difference is partial results because of multiple authorizers
      • Should decide this week ahead of freeze

August 9th, 2017, 11a - Noon (Pacific Time)

July 26th, 2017, 11a - Noon (Pacific Time)

  • Recording
  • Pulls of note
    • Allow nodes to evict their own pods (#48707)
    • Best practices for secrets (#4380)
    • Selfsubjectrulesreview (#48051)
      • Namespaced or cluster-scoped?
        • At cluster scope make sure this can't expose information about what namespaces exist
      • Include control over "extra" data or not?
        • Used to plumb information between authentication and authorization (example: oauth scopes, keystone project role info)
        • Use case: give a scoped credential to a third party that is only allowed to submit selfsubjectrulesreviews, and allow that third party to ask about unscoped permissions
        • If "extra" is only used to limit permissions,
      • Open feature/issue to discuss a method for webhook authorizers to support this API @ericchiang
    • Remove automatic binding of system:node role (#49638)
    • RBAC v1 (#49642)
  • Designs of note
    • Giving nodes write access to pvc/status (proposal)
    • kubeadm (alpha) HA implementation plan (doc link)
    • Vault based KMS provider for secrets in etcd3 (doc link, kk.sriram)
      • This design is based off the in-flight implementation for Google Cloud KMS integration sakshamsharma has been writing (issue #48522), PRs: #48574, #49350, #49742
  • Discussions
    • Dynamic authz and audit webhook configuration (along the lines of Dynamic Admission Control in 1.7) (Matt Moyer)
    • Over next several releases, migrate webhook authn/authz to use v1 APIs (@liggitt to open issue)

July 12th, 2017, 11a - Noon (Pacific Time)

  • Recording
  • Demo
  • Discussions:
  • API resources with Secret information: embed or reference secrets? (Paul Morie)
    • Needed for service-catalog work
    • Original solution:
      • Referencing a Secret and key containing confidential information
      • svc-cat has a need to store secret data that is not going to be injected into Pod, but used as parameters to an external API
      • Initial design had similar issues as ingress (watch all secrets) https://github.com/kubernetes/ingress/issues/816
    • Access pattern: individual gets, looking forward to bulk watch
      • Action item: Need to formalize this "don't list/watch all secrets" opinion.
    • Usability of managing permissions individually:
  • Additional TLS validation in the kubeadm bootstrap/discovery API (WIP proposal) (Matt Moyer)
    • Proposal to add a CA signature pin to kubeadm join
      • No specific objections to the pinning
      • Discussion of auth token
  • 1.8 planning/coordination
    • RBAC to v1 - @liggitt
    • NodeRestriction control over pod steering (prevent adding labels, prevent removing taints / deleting while tainted) - @liggitt
    • Audit logging beta - @tallclair, @ericchiang, …?
    • TLS rotation (client, server) beta @jcbsmpsn
    • Container identity working group - @smarterclayton, @destijl
    • PodSecurityPolicy enablement - @tallclair
    • Kubernetes Secrets: Roadmap work - @destijl, @smarterclayton, …?
      • Add support for storing secrets encryption key in Google KMS @sakshamsharma, @jcbsmpsn
      • Controller secret access patterns
      • Generated secret injection into pods/containers, possibly via volume plugins
        • Probably overlaps with container identity (service account token is attesting by ownership of the token that the agent can act as the service account, but could be much more finely scoped)
    • SecurityContext improvements (entitlements?) roadmap - @tallclair

June 28st, 2017, 11a - Noon (Pacific Time)

  • Canceled due to release crunch and lack of agenda items.

June 14th, 2017, 11a - Noon (Pacific Time)

Attending:

  • Quintin Lee, CJ Cullen, Saad Ali, Google
  • Luke Heidecke, Solinea
  • Eric Chiang, CoreOS
  • Chris Hoge, OpenStack Foundation (@hogepodge)
  • David Eads, Red Hat
  • Amir Jerbi, Aqua Security

May 31st, 2017, 11a - Noon (Pacific Time)

  • Recorded meeting
  • Pull requests of note:
  • Designs of note:
    • Nothing new
  • End of release stuff:
  • Secrets roadmap
    • Spectrum of use cases
      • Value injected into container (easiest to solve, few API implications)
      • "First class" use pulling from API (e.g. kubelet)
      • High-privilege controller (e.g. cloud provider, less subdivision needed)
      • Low-privilege controller (e.g. namespaced ingress controller)
    • Dimensions to slice secret authorization by:
      • Available today: Name, namespace
      • Potential generic mechanisms: Secret type? Labels?
      • Desired, but difficult to represent generically: relationships/references from other objects ("let the ingress controller get any secret referenced as a TLS cert from an Ingress object", etc)
    • Mechanisms for authorizing based on object relationships:
      • Bespoke in-tree authorizer (e.g. node authorizer)
        • Pros: fast, low write impact to etcd, can be used in combination with any other authorization mode
        • Cons: approach doesn't scale to wide variety of controllers/relationships (ingress, service catalog, etc, etc, etc)
      • "Programming RBAC" based on object relationships, e.g. an "ingress role binder" that watches nIngress objects and grants get permissions on referenced TLS secrets to the ingress cotroller
        • Pros: no core changes, policy is inspectable
        • Cons: higher write traffic (may not matter for low change relationships), one more component to consider
    • Problematic API access patterns for secret subdivision:
      • list/watch
        • would not be compatible with per-secret authorization strategies
        • Straw-man guidance: avoid list/watch, prefer individual gets
      • Lack of separation between metadata and confidential content
        • Ideally could see a secret exists without seeing secret data
        • Straw-man proposal:
          • key/value field that is write-only (e.g. superSecretData)
          • never included in get/list/watch responses
          • only accessible via a subresource (e.g. /api/v1/namespaces/myns/secrets/mysecret/data), which means it is separately authorized.
          • possible plug-point for external secret management integration (on write, plugin stores secure data, on subresource read, how the data is retrieved is determined by the plugin)

Attending:

  • Saad Ali, Tim St. Clair, CJ Cullen, Mike Danese, Eric Tune, Jacob Simpson, Quintin Lee, Google
  • Andrew Jessup, Emiliano Berenbaum, Scytale
  • Steven E. Harris, IBM
  • Jordan Liggitt, Derek Carr, Paul Morie, Red Hat
  • Fred Vong, VMware
  • Alexander Brand, Apprenda
  • Joe Beda, Heptio

May 17th, 2017, 11a - Noon (Pacific Time)

  • Recorded meeting
  • Pull requests of note:
    • Mirror pod restriction/validation #45775
    • NodeRestriction admission plugin #45929
    • Migrate group approver to use subject access review #45619
      • TLS certificate request approving controller
      • Types of requests: kubelet client cert (bootstrap), kubelet client cert (renew/rotate), kubelet serving cert
      • Splits signing controller and autoapproving controller to be individually runnable
      • Optional controller to auto-approve certain types of certificate requests (not required, can use out-of-band methods for approving requests)
    • Kubeadm, put system certificates in kube-system secrets for self-hosted clusters: #42548
      • Getting secrets in kube-system already game over today?
      • Intrinsic tradeoff between self-hosted and isolation?
      • Might help putting them in a different namespace?
      • Would be good to support both models.
      • Secrets API not compatible with chain of trust?
      • Maybe not worse than the current situation? Just know that we're going to have to change this later.
      • More secure today to shove it in a TPR?
      • Action item (Greg Castle): Update secrets design doc to describe what secrets are for.
      • _Action item _(Eric Tune): Setup call around scoping controller privs.
  • Designs of note (may kubernetes/community PRs discussed in previous meetings):
  • Suggested working group on container identity
    • Ensuring containers can assert their identity to other system has been discussed as necessary for a number of efforts, in order to try to get discussion going across the multiple impacted sigs it has been suggested that we try to do a working group.
    • Try to follow the example of the resource management working group and solicit participants from other sigs and community
    • Figure out what is out of scope.

Attendees

  • Joe Beda, Heptio
  • Saad Ali, Google
  • Eric Tune, Google
  • CJ Cullen, Google
  • Yang Guan, Google
  • Quintin Lee, Google
  • Mike Danese, Google
  • Eric Chiang, CoreOS
  • Rithu John, CoreOS
  • Clayton Coleman, Red Hat
  • David Eads, Red Hat
  • Jordan Liggitt, Red Hat
  • Jacob Simpson, Google

May 3rd, 2017, 11a - Noon (Pacific Time)

  • Recorded meeting
  • Pull request of note:
  • Designs of note (may kubernetes/community PRs discussed in previous meetings)
  • Individual identity in Docker Swarm ~20m - (Ying Li)
    • Ying didn't join the hangout.
    • Eric Chiang will follow up with the Swarm people and send something to sig-auth if they're going to present at another sig meeting.
  • Scoped kubelet API access - #585 - 10m - @liggitt
    • Include other areas we'd like to extend it further. For instance, PersistentVolumes.
    • Should a kubelet be able to list all Pods in the system, or just Pods on itself?
    • Ditto for every other Resource in the system (including TPR?)
  • Greg castle: if clayton joins I'd be interested in talking about #454, encrypting secrets to see where it is at.
    • Clayton is at Red Hat Summit. I wouldn't anticipate him here.
  • [jbeda] If we have extra time and folks are interested, I'm happy to give a quick overview of SPIFFE.
    • deads - Looks like it's worth a read, but I don't think we're ready to talk about it today.
  • Attendees:
  • Joe Beda, Heptio
  • Alex Mohr, Google
  • CJ Cullen, Google
  • Greg Castle, Google
  • Jacob Simpson, Google
  • Jacob Beacham, Google
  • Saad Ali, Google
  • Steve Sloka, UPMC Enterprises
  • David Eads, Red Hat
  • Jordan Liggitt, Red Hat
  • Eric Chiang, CoreOS
  • Rithu John, CoreOS
  • Tim St. Clair, Google
  • Quintin Lee, Google
  • Yang Guan, Google
  • Vipin Jain, SPIFFE
  • Emiliano Berenbaum, SPIFFE/Scytale

April 19th, 2017, 11a - Noon (Pacific Time)

  • Recorded meeting
  • Pull requests of note
    • Reduce allocations by RBAC authorizer - #44449 (@liggitt)
  • Designs of note
    • Auth setup for federation control plane - (Nikhil Jindal)
      • Per-cluster creds vs per-cluster-per-namespace vs per-user and per-cluster-per-user
      • Tracking users adds complexity, but would allow federation controller to impersonate users.
    • Enterprise control for K8s 10m, @erictune, Rae W (rae42), Ray C (rcolline)
      • Not specifically tied to LDAP (just a strawman)
      • Hierarchical set of namespaces that can be controlled, resource-quota'd, from a central database
      • Had issues with "shadow namespaces" (developers who create untracked namespaces)
      • Possibly no need to alter core kubernetes?
      • Admission control?
        • E.g. want to check LDAP before running a pod in a namespace
        • Maybe can use pod security policies, etc. for these kind of things?
    • Security model for user facing services - #532 (@Q-Lee)
  • Q: Is there a place for make working with policies easier? (e.g. RBAC, networking policy, pod security policy, etc.)

April 5th, 2017, 11a - Noon (Pacific Time)

  • Recorded meeting
  • Pull requests of note
    • Brainstorm role name for read access to storageclasses - #40881 (@seh)
    • PodSecurityPolicy: limit which host paths are allowed - #43946 (@jhorwit2)
    • PodSecurityPolicy: allow within particular namespaces - #42360 (@liggitt)
    • Enable service account token lookup/revocation - #24167, #44071 (@liggitt)
      • Performance implications of etcd lookups (can use cache if needed)
      • HA/Federation implications if service account token use based solely on signature is desired (can always opt out of lookup)
      • What is the least disruptive way to change this default?
        • What matches user expectations best?
        • What could changing the default cause to stop working?
    • Include system:authenticated group in impersonated requests - #44076 (@liggitt)
    • Remove special-case handling for unsecured port - #43888 (@liggitt)
  • Designs of note
    • Threat models WIP - #504 (@smarterclayton)
    • Security proposals/designs refresh - #500 (@smarterclayton)
  • Kubectl client auth plugins
    • Azure, #43987 (@cosmincojocar, @colemickens, @ericchiang)
      • access_token vs id_token concerns
      • can we delegate obtaining initial token to external tool, and just handle refreshing the token internally?
    • Openstack, #39587 (@zhouhaibing089)
      • Retrying transport implementation is questionable
    • Likely common patterns that could be factored out
      • Respond to 401 API response by trying to obtain new credentials
  • CIS Kubernetes 1.6 Benchmark update (ericchiang)
  • SIG business item (@erictune)
    • @erictune stepping down as sig-auth lead, focusing more on sig-apps
    • No immediate plans to seek a replacement, most sigs have 2-3 leads (though feedback on that is welcome)

March 22nd, 2017, 11a - Noon (Pacific Time)

March 8th, 2017, 11a - Noon (Pacific Time)

  • Recorded meeting
  • 1.6 close-out
  • 1.7 plans / priorities?
    • Documentation
      • Threat model @timstclair (node), ...
      • Hardening guide
      • User-focused guides @rithujohn191
    • Deployments
      • Need sig-auth members to work with each deployment project
      • Help implement best practices (setup, hardening, etc)
      • kube-up
      • kubeadm
      • kops
      • …
    • Add-ons
      • Almost all add-ons run as default kube-system service account
      • Need to work with add-on manager devs, and add-on devs to define best practices - #38541
      • Partitioned namespaces, service accounts, accompanying roles, etc
    • Implementation work
      • Node authorizer - #40476, @liggitt
      • PodSecurityPolicy improvements - #23217, @liggitt
      • CSR auto-approval switch from hard-coded group to authz check using SubjectAccessReview - @liggitt
      • Encrypt secrets at rest - #12742, @erictune, @smarterclayton
      • Groupification - #23720, @ericchiang
      • OIDC plugin maintenance - #42654, @ericchiang
      • Kubelet server cert bootstrapping @jcbsmpsn
      • Kubelet client certificate rotation #4672, @jcbsmpsn
      • Audit Logging features#22, @timstclair, @cjcullen, @ericchiang, others?
      • Seccomp enabled by default #39845 , #145 @timstclair
    • Design/Roadmap work
      • Bulk namespace access control #40403 @cmluciano, @smarterclayton
      • Roadmap for secrets, and integration with external secret stores @erictune
      • Extensible admission (in concert with sig-api-machinery)
    • Backlog
      • CRL support - #33519 (might be mitigated by rotation / shorter expirys)

February 22nd, 2017, 11a - Noon (Pacific Time)

  • Meeting cancelled

February 8th, 2017, 11a - Noon (Pacific Time)

January 25th, 2017, 11a - Noon (Pacific Time)

January 11th, 2017, 11a - Noon (Pacific Time)