Skip to content

Latest commit

 

History

History
860 lines (717 loc) · 53.8 KB

meeting-notes-2017.md

File metadata and controls

860 lines (717 loc) · 53.8 KB

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: kubernetes/ingress-nginx#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
    • PodSecurityPolicy - @liggitt, @tallclair
      • ordering/priority - #52849, #45358 @liggitt
      • GCE/GKE/CI enablement - #52367 @tallclair
      • bootstrapping/default policy - #52367 @tallclair?
      • Transitioning out of extensions API group to which group? Possibly "policy" group, alongside other pod-related policies (PodDisruptionBudget). Requires more thought.
      • AllowedFlexVolumes - community#723 @php-coder?
    • Node label/taint restriction - features#279, community#911 @mikedanese, @liggitt
      • Required to prevent nodes from steering pods
      • Backwards compatibility issues with existing labels/taints
      • Coordinate with sig-node (@???), sig-scheduling (@davidopp)
    • Node status address restriction - community#911 @mikedanese, @jcbsmpsn
      • Required for nodes to obtain serving certs via CSR -
      • Split kubelet startup flow to obtain addresses from node status
      • Move authoritative source of addresses to node controller
      • Coordinate with sig-node/sig-cloud-provider - @???
    • ClusterRoles for API extensions (CRD and UAS) - @deads2k
    • Design for out-of-process KMS provider API - @jcbsmpsn
    • Vault as KMS provider - @kk, @deads2k
    • AWS as KMS provider - @mattmoyer (tentative)
    • Container Isolation (strategy & design) - @tallclair
      • Holistic look at the future of (Pod)SecurityContext, PodSecurityPolicy, Authz (for pods/PSP), VM based pods, etc.
    • Continued client cert rotation work - @jcbsmpsn, @mikedanese
      • Better define failure modes, fallback behaviors
      • Better testing coverage (enabled in e2e with short expire times)
      • Progress on bootstrap/attestation work
        • Would like to change auto-approve to add checks for attestation material in the CSR in environments where that is available (could allow "bootstrap" token to be long-lived)
    • [ add items you plan to work on ]
  • 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
  • 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)
      • Admission is purely limiting and has the use case of dynamic aggregated API servers
      • Clear use case? Could already do this by making your webhook handle the dynamic part.
      • Overlap with component config? kubernetes/kubernetes#12245
    • 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) kubernetes/ingress-nginx#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
      • Work with sig-apps to improve out-of-box experience with first-class helm charts, etc @ericchiang
      • Disable legacy ABAC policy in GCE/GKE by default - @cjcullen?
      • Documentation improvements (e.g. kubernetes/website#2792) - @liggitt, @ericchiang, …?
    • 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:
    • Certificate rotation for kubelet serving certs kubernetes/kubernetes#45059
      • Need to document the plan for having separate approval controllers
      • Can platform dependent extensions be made accessible for proving who requested the signature.
      • Categorization of a request: bootstrap client cert, kubelet requesting serving cert, kubelet requesting renewed client cert is generic.
    • Issue for expanding approval mechanisms: kubernetes/kubernetes#45030
  • 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.)
    • Audit logging #145
    • View the namespaces as your security boundary.
    • Discussion around svc 2 svc auth. Joe brought up SPIFFE (again).

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)

  • RBAC v1beta1
  • RBAC rollout (deads, cjcullen, liggitt)
    • Existing bring-up scripts used for CI and production
    • Upgrades of existing clusters using ABAC
      • Optionally include existing ABAC policy files
      • Define permissive RBAC policy matching legacy defaults (but do not use in CI/e2e)
    • Flushing out required permissions for system components
    • Example and doc updates
      • Cluster admin oriented
        • Delegating permissions per namespace
        • Giving permissions to a particular service account in a namespace
        • Giving permissions to a particular service account cluster-wide
        • Creating a custom role
      • Developer oriented
        • Consider permissions required by pod
        • Describe default RBAC roles (cluster-admin, admin, edit, view) - kubernetes/website#2169
        • Encourage documenting which RBAC role is required by your component
        • If no default role fits, include a tailored role definition
    • Deployment methods (kops, kubeadm, ansible, …, …)
      • Compatible upgrades
      • Default mode for new installs
      • Options to load legacy permissive policies?
    • For e2e troubles, here's a thread with helpful links
    • Want to come up with an education plan.
      • In some cases, this exposes problems that already existed. Bad extensions as a for instance, lack of safe multi-tenancy as another.
  • RBAC role granting allowed via "bind" permission from any authorizer