kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add sig-auth meeting note archive to github

This commit is contained in:
Tim Allclair 2019-01-08 13:08:02 -08:00
parent cd961fad1e
commit 79b42031c7
3 changed files with 2185 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

646
sig-auth/archive/meeting-notes-2016.md Normal file
View File

@ -0,0 +1,646 @@
# Kubernetes Sig-auth Meeting Agenda
## December 14th, 2016, 11a - Noon (Pacific Time) - [recording](https://youtu.be/XaPDkb5hFww)
* Presentation on Openshift Service server cert annotations
* Signs a serving certificate for an in cluster DNS name: `service-name.namespace.svc`.
* Separate distributes a CA bundle to all pods by piggy-backing on the auto-mounted SA secrets.
* A stolen key can't be used by a pod in another namespace since they can't control traffic routing.
* Does *not* sign client certificates since those could be re-used from anywhere.
* Getting pods to reload updated serving certificates is hard.
* Notes:
* Usage in openshift here: https://github.com/openshift/origin/blob/master/test/extended/cmd.sh#L182-L188
* Add an annotation to your deployment
* Get a serving cert in your service account secrets
* Ingress only does TLS termination, not re-encryption
* Rotation is hard.
* Demo of https://github.com/kelseyhightower/vault-controller (Kelsey, 10 minutes demo + 10m questions)
* Notes:
* Prototype.
* Kubernetes doesn't have "real" secrets.
* Token per pod
* Use an init container which talks to the vault controller
* Vault controller looks up a pod with that name
* Once the vault controller is confident that it's actually talking to a pod, it will give it a token.
* E.g. uses pod IP to actually send token to pod
* Dynamic secrets that can have short TTLs and renewing
* Vault only lets one client decode the token
* Raises an alarm if it's been tried to be unwrapped twice
* There is no way to secure the use of particular annotations today.
* Still have to handle key/cert updates. Health check? Rotation is still hard.
* How does this handle generic secrets?
* Policies determine what can read what
* Vault controller needs to be able to have access to all policies it might delegate to pod.
## November 30th, 2016, 11a - Noon (Pacific Time)
* Sig Self Assessment [15 min?]
* Does your SIG own code in kubernetes/kubernetes? Elsewhere? Within kubernetes/kubernetes, is it reflected in OWNERS files? If not do, you see a path to doing that?
* /pkg/apis/{abac,authorization,authentication,rbac}
* /pkg/auth
* /plugin/pkg/auth
* No code outside the main repo
* OWNERS? Sig-auth leads in many owners files as individuals, but not aliased as sig-auth. Github kubernetes/sig-auth team is not synced with the google group. Should it be?
* Does your SIG spend (not enough, the right amount, too much) time responding to user issues in Github? On stackoverflow? On your SIG mailing list?
* Mailing list not great. Slack channel is amazing!
* Document what kind of questions are appropriate for which forum.
* E.g. slack isn't searchable.
* Move frequent questions/answers to doc
* Is the balance between new features work and stabilization good, over the last 2 releases? Do you feel the need to focus on stabilization in the next release? Something else?
* Overall, how do you feel good about the level of test coverage for the code you are responsible for? Docs completeness? Number of open bug reports?
* Docs have a lot of catching up to do.
* Unit test coverage is generally good
* Integration test coverage is less good… difficult to start servers with lots of different configurations
* fill out survey, once per sig, after the meeting. https://docs.google.com/a/google.com/forms/d/e/1FAIpQLScR4dkTyfP56cQdKyqHWMJl3glLfyu46EXqCxAH7Bd-xkJ8cw/viewform
* 1.6 objectives. P1 - staffed and the release was unsuccessful if we don't get it. P2 - really want it, will devote review time to it, but no one has signed up to do it. P3 - nice to have, but not being actively worked
* Do we have a pithy threat model that we're focusing on for 1.6? E.g., "compromise nginx running on cluster does not give root in cluster w/o further vulns"? Possible to configure pods that way, then by default?
* Explains to users+devs why we're doing the work below.
* Pod security context and RBAC are the work being done for the nginx example
* Also need docs on how to use them all together.
* RBAC to beta - P1,big - deads, sttts, someone from test please?
* Default roles for controllers - pulls in progress
* Controller, scheduler, kubelet, etc identity - pulls in progress
* Local-up-cluster support - pulls in progress
* CI test that enforces controller, kubelet, other infrastructure permissions - need assistance here. We're on the agenda next meeting: https://docs.google.com/document/d/1z8MQpr_jTwhmjLMUaqQyBk1EYG_Y_3D4y4YdMJ7V1Kk/edit cjcullen says he'll be able to help once we've reached a point where it make sense to wire this up.
* ~~Default (minimal) roles for service accounts (don't want compromised pod to be able to wreak havoc). This is already done (default).~~
* Document how to effectively use RBAC for API protection by default.
* Tracking issues to enable in deployment mechanisms (aws, gce, kubeadm, kops, etc, etc, etc) (ericchiang can help with this)
* Authn/Authz with federated API servers in a single cluster - P1,small - deads, sttts
* API machinery has existing plan: https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/federated-api-servers.md
* Pulls in progress to make auth proxy available as the standard authentication
* POC being brought into kube demonstrating the concept here: https://github.com/openshift/kube-aggregator
* Credential rotation {possible | on by default} - P2,big?
* Credential revocation
* Service account tokens - delete secret, validate against etcd
* X509 certs - CRL?
* Credential rotation
* Service account token
* X509 cert
* Credential signing/granting rotation
* Token signing keys
* CA signing certs
* Whitelist paths for host dir (erictune, P2?)
* Fixing open issues with kubectl/OIDC. No net new features. (ericchiang, P2?)
## November 16th, 2016
* No SIG meetings this week
## November 2nd, 2016, 11a - Noon (Pacific Time)
* Security response team update
* Proposal in progress: https://docs.google.com/document/d/1dGzReKkYdRwyj2uYFMeIJbZesnBlhWgCeuSJ9af4gbE/edit
* 1.5 items - any exceptions required?
* https://github.com/kubernetes/features/issues?q=is%3Aopen+is%3Aissue+label%3Ateam%2FSIG-Auth
* Kubelet authn/z - [in](https://github.com/kubernetes/kubernetes/pull/34381)
* Auth proxy - [in](https://github.com/kubernetes/kubernetes/pull/35452)
* SA credential rotation - [in](https://github.com/kubernetes/kubernetes/pull/34029)
* RBAC
* Bootstrapping, discovery role/rolebinding, default roles in
* will continue work next release
* Needs mutable, secure API server summarization
* PSP - user-specific PR pending ([#33080](https://github.com/kubernetes/kubernetes/pull/33080))
* CRL - pending review, unsure if it will be ready for freeze (maybe early 1.6)
* https://github.com/kubernetes/kubernetes/pull/33519
* https://github.com/kubernetes/kubernetes/pull/35698
* Short-lived certs (must be easily rotatable) vs easy revocation (performance hit of CRL lookups)
* F2F at kubecon?
* FYI: Kelsey's vault integration sketch
* https://github.com/kelseyhightower/vault-controller
* Feedback on this please.
* 1.6 planning
* Threat models (master, node, pod compromise, etc)
* Appropriate use of secrets (encryption requirements, who holds keys, type and access segmentation, etc)
* Credential rotation (service account tokens, client/server certs)
* Intent based RBAC API
* https://github.com/kubernetes/kubernetes/pull/31441
* Declarative vs imperative
* Post-1.5, david and clayton to follow up
* OpenID Connect client updates
* Upstream rewrite of coreos library
* Better compatibility with arbitrary oauth/oidc servers
* External test coverage (in kube usage of OIDC) before switching
* ericchiang to open tracking issue to switch, summarize changes
## October 19th, 2016, 11a - Noon (Pacific Time)
* Expanding the sig-auth charter (15 min - leads)
* Sig-security proposal: https://groups.google.com/forum/#!topic/kubernetes-dev/7YvCC3GrvJE
* Current charter: https://gist.github.com/erictune/a123f2df7ce8b5fcdd33
* Proposed charter: https://gist.github.com/liggitt/008700a8f22f47b8f75f114dfba21540
* Security response team / vulnerability management team
* Working group of sig-auth
* Goals:
* Small team to privately triage CVE/security reports
* Coordinate with appropriate sig leads / feature owners
* Coordinate with releng on point releases or backports for security fixes
* Coordinate with vendors/distros on distribution of security fixes?
* Two phases:
* Figure out how to create and structure the security response team.
* One or more sig auth leads to be involved initially?
* Security response team executes on mission.
* Prior Art:
* https://security.openstack.org/vmt-process.html (OpenStack Vulnerability Management Team)
* Networking round two (20 min - deads) with Dan Williams
* [Prior discussion](#september-21st-2016-11a---noon-pacific-time)
* What is a tenant?
* Recap:
* OpenShift: Namespace networks start isolated, can become shared.
* Potential for N-to-N relationship where users may need access to some subset of networks.
* Current network policy in upstream is not trying to solve tenancy.
* Does ingress (no egress), you can whitelist other things to send traffic to you.
* Contention around cluster administrator vs app developer.
* What is networking sig doing to make this easy to use?
* Simple policy: Default deny then you can enable the things you want
* Expect higher level tools to control these rules
* Similar to ec2 security groups.
* Who is the audience?
* You write an app with a service and want to expose it to some subset of namespaces.
* Again, expect high level tools (e.g. http://www.opencontrail.org/)
* Intent based? E.g. if I configure a service I clearly expect the pods backing it to expose specific ports.
* RBAC intent. I allow access for "david" to access "pods/proxy"
* How would you set up policy in human terms. E.g. This thing can access another thing.
* Unreliability of source IP.
* How to handle cross-namespace resources
* Possibly a higher level concept (e.g. a deployment vs pods)
* Next steps
* Try to help sort out what a tenant is, or at least summarize what others think of it.
* David Oppenheimer will help facilitate that document.
* What is a tenant?
* Use cases
## October 5th, 2016, 11a - Noon (Pacific Time)
* Kubelet authn/authz proposal (10 min)
* https://github.com/kubernetes/kubernetes/pull/32518
* GKE considerations
* Can continue running in current mode (no authn/authz)
* LGTM'd by CJ Cullen, with reservations around SAR for kubelet
* Will continue discussion in PR
* Review 1.5 goals (15 min) (hopefully with erictune)
* Month and a half of time left
* rbac to beta? (deads2k)
* On by default?
* Biggest risk is SA controllers on by default
* Eric will follow up on benchmark stuff
* Intent based API
*
* login (eric chiang)
* Not for 1.5
* CoreOS de-prioritized, but would not block it.
* SA credential rotation (liggitt)
* Pull open to allow multiple signer key recognition to tokens.
* Currently nothing that decides when and how the old tokens go away.
* https://github.com/kubernetes/kubernetes/pull/34029
* File CRL (eric chiang)
* https://github.com/kubernetes/kubernetes/pull/33519
* X-Remote User authenticator (liggitt)
* On the TODO list
* Kubelet authn/authz (liggitt)
* https://github.com/kubernetes/kubernetes/pull/32518
* CSR for server cert
* Use the client cert to request a server cert
* Make insecure port unnecessary (deads/dims)
* Now possible, but not easily possible
* Needs refinement and probably RBAC on by default
* Controllers and the schedulers use it
* Give these "system:" identities
* Probably end up with possible in 1.5, but not easy until 1.6
* No current work
* Kubernetes as an Authenticating Proxy
* Default Service Account Power Reduction (authz addresses power reduction, no work in progress to omit token entirely)
* Presentation about Open Policy Agent by Torin Sandall
* [ www.openpolicyagent.org](http://www.openpolicyagent.org)
* [15 min?]
* Some discussion around remote admission controllers
* How do we see this going in the future?
* Process based plugin?
* Implementing a generic callout would mean we now expose every object to our webhooks. Might be hard to reason about how changes to internal objects would impact every outside evaluator.
* Proposal to split the admission controller interface into multiple interfaces: https://github.com/kubernetes/kubernetes/pull/34131
* Video! https://www.youtube.com/watch?v=34vDoGSi0JY
*
## September 21st, 2016, 11a - Noon (Pacific Time)
* Joint meeting with Sig-network (thockin) 40min
* Network ingress policy objects (egress not supported yet)
* https://godoc.org/k8s.io/kubernetes/pkg/apis/extensions#NetworkPolicy
* Determine which pods can talk to each other
* Also select a set of namespaces (label selectors) which can talk to each other. Note: assumption that only admins can create namespaces.
* Openshift differentiates between "I want to create this object" and "I want an admin to create this for me"
* Further policy (whitelist) around what labels you can set.
* Policy that determines what traffic others can send to your pod
* Either with your namespace
* Or on another namespace
* Only additive
* How does RBAC complicate network policy?
* (chris marino) RBAC doesn't map well to network policy today
* RBAC review:
* Two levels: cluster admin vs namespace admin
* Namespace admin shouldn't be able to impact other namespaces
* Network policy side
* Mimic AWS security groups
* Create a group (e.g. I expose port 80, will only accept traffic from IP foobar, etc.), add a VM to that group
* Scope by label selector
* Goal: Operator policies that take precedence over user policies
* Challenges with using labels on namespaces to identify common policy across namespaces
* Label values are limited
* Openshift had to use annotations
* Who controls the labels?
* Notes from RBAC: Grant vs Accept
* Just because I give you something, doesn't mean you want it (possible phishing attacks by granting someone access to things with misleading names)
* How does RBAC, or its model, extend to network policy?
* What level of flexibility/complexity does this need to support?
* Types of separation
* Dev vs. production, service provider vs. customer, admin vs. teams
* Can we provide hierarchy on policy? Namespaces are nice, but they can often overlap.
* NOTE: sig-auth might be a good place to discuss general policy when other sigs want to implement something
## September 7th, 2016, 11a - Noon (Pacific Time)
* "What can I do?" endpoint (david) 10min
1. Users need to be able to predict which actions they can perform. SAR and SelfSAR give them one at a time checks, but getting a complete list is very useful.
1. Should not be specific to a particular authorizer.
1. https://github.com/kubernetes/kubernetes/issues/31292
1. Namespaced or cluster scoped?
* Yes, but as a secondary objective
1. Would like to see an implementation
* How to express queries about non-namespaced objects or cluster wide rules
* How to deal with stars, do we return wildcards? authorization.Attributes lacks a current rule for dealing with this.
* How to indicate incomplete information.
1. Interaction with UI is important (do I show a delete button?), but a heavy operation
* Batching important
1. Next steps
* actually review clients that will use this (demo of OpenShift by liggit)
* Propose an API and have UI builders review
* Tighten RBAC rules (david) 10min
1. Stop cross-namespace role references
* Currently, fail at runtime
* Still allow referencing service accounts in different namespaces
1. Require `Kind` and `APIGroup` on the roleref (could be defaulted)
*
1. Breaking changes
1. Other notes: bootstrapping of roles
* Call for 1.5 Goals (erictune) 20min
1. Kubernetes as an Authenticating Proxy - P2
* OpenShift is interested but does not expect to have Resources.
* Google is interested not sure about allocating resources.
* Dashboard would like this.
* Not well designed yet.
* OpenShift interested in the "allow proxy within namespace to anyone with namespace access" use case.
* Feels like plan but not execute in 1.5 item, or do it in pieces.
* Experience: If I am authenticated to the Kubernetes API, I can be authenticated to addon/apps/charts running on the cluster. Addons and Apps don't need to implement Authn.
* Example users of Proxy: K8s Dashboard, Federation Apiserver, Grafana, Spark driver dashboard,.
* Jordan says likes the idea, but wants to do the right thing with cookies
1. Kubernetes API can sit behind an Authenticating Proxy - P1 (deads2k/liggitt)
* What: Cluster deployer can put an authenticating proxy in front of Kubernetes APIserver.
* Request Header upstream -> Jordan or David is likely to upstream this in 1.5 time frame.
1. Authorization - P1 (deads2k) (etune or ericchiang to review)
* What: Review contributions to RBAC, ensure goes to Beta.
* Why: because OSS needs authorization
* David will drive this.
* Requirements: accuracy (deads2k), performance (deads2k, but eric chiang will help with testing), default roles (deads2k)
1. Default Service Account Power Reduction - P3
* Not issue for OpenShift/RBAC.
* Why: currently service accounts are "root" by default on GKE, and changing the default is annoying
* Turning on any authorizer (RBAC, ABAC, etc) addresses this for OSS, etune needs to work on it for GKE and etune to fix the ABAC example to use groups.
* Way to not have service account (or not have a token). deads: I don't think this bit is a P1 objective for 1.5.
1. Credential rotation - P3
* Need to document that rotation is possible.
* Might need flag on apiserver to allow multiple SA signer certs
* Needs more thought on exactly what threats and what keys are involved.
* Why: So if someone gets a service account token, we can revoke it.
* Turn on that one admission controller (or authorizer option) by default for standard Kubernetes turnups so it can do Service Account Token revocation.
* Why: so if someone takes master's key, we can revoke it (assuming root CA still secure).
* Consider letting the JWT verifier to take multiple verification keys
1. Eliminate unsecured master port (issue [13598](https://github.com/kubernetes/kubernetes/issues/13598), possible PR [31491](https://github.com/kubernetes/kubernetes/pull/31491)) - P1 (liggitt)
* This should work regardless of any other authorization config
1. Add authn/authz to kubelet API (issue [11816](https://github.com/kubernetes/kubernetes/issues/11816), starting PR [31562](https://github.com/kubernetes/kubernetes/pull/31562)) - P1 (liggitt)
1. (ericchiang): continue to iron out kubectl login PMaybe (deads2k/red hat can review)
* Keystone auth integration (liggitt) 20min
1. https://github.com/kubernetes/kubernetes/pull/25391
1. user mapping
* User friendly? Keystone <user name>@<domain name>
* Unique and programmatic? Keystone user id
1. project/role mapping
* Could map keystone project/role tuple to groups. Suggested by deads, liggitt, and marc boorshtein. It allows clean layering in kube authentication and authorization layers.
1. Kubernetes gets a token
* Identifies the keystone user
* Is scoped to a specific keystone project and role tuple (or roles?)
1. Will arrange two meetings, one for getting to know keystone, one for how to map keystone concepts to kube concepts.
1. Not discussed: fate of current password auth? Single-domain? Multi-domain?
## August 24th, 2016, 11a - Noon (Pacific Time)
Cancelled.
## August 10th, 2016, 11a - Noon (Pacific Time)
* Group for x509 clients certs through Organizations or Organizational Units
1. Use organizations for parity with OpenShift
1. https://github.com/kubernetes/kubernetes/issues/30260
1. Interactions with groupification?
* Can you say "no more groups can be added?"
1. Interactions with impersonation?
1. The more we embed in certs, the more we need revocation (https://github.com/kubernetes/kubernetes/pull/29293)
1. AI: ericchiang to open PR
* Node CSR API (liggitt, mikedanese, gtank)
1. https://github.com/kubernetes/kubernetes/pull/30153
1. What kind of rules do we need to have a safe-ish system
1. Goals:
* Partitioned node API permissions
* Sufficient info to approve node client certs for shared secret bootstrap
* Sufficient info to approve node serving certs for bootstrap
1. API-enforced info
* Who requested (user/uid/groups)
1. User-specified info
* What they're requesting (CSR content)
* What type of cert they're requesting (ExtKeyUsageServerAuth, ExtKeyUsageClientAuth, KeyUsageCertSign, etc)
1. Bootstrap cases
* Nodes starting from shared secret, getting individual client certs
* Limits usage to client cert
* Require specific CSR subject shape (e.g. "O=system:nodes,CN=system:node:<nodename>")
* Controller auto-approval can be based on a bootstrap group or user flag (allows a shared bootstrap secret to fan out to node client certs)
* Auto-approver for node serving certs
* Limits usage to server cert
* Requires specific CSR subject/SAN shape (CN only, CN must be in SANs?)
* Gates on request coming from the node user? Daisy-chains with node client cert auto-approver, but allows more security when individual identities can be distributed to nodes at provision time
1. Notes:
* Nodes need to be authorized differently based on the particular node requesting access.
* a node should only see pods scheduled to it
* a node should only see secrets used by pods scheduled on it
* a node should only be able to update itself
* etc
* To do that, you must have authentication provide information that can
* indicate that the subject is a node: special group?
* indicate that a node subject corresponds to a _particular_ node
* Names to match Jordan's suggestion.
* Server certs and client certs should be seen as different actions.
* Does the PR generate a serving cert rather than a client cert? PR needs to be updated, it's touching serving certs.
* gtank? Inspect the CSR profile to see if we can make it reasonable for API consumers to express their usage intent regardless of profile names.
* Any controller that can decide whether something can be signed needs to be aware of who can request what (requires API knowledge).
* liggitt, mikedanese, deads2k want this to be based on API intent. Not sure how much CSR policy overlaps with these use cases.
* Extend impersonation (david)
1. Allow complete impersonation including groups and extra (last bits of user.Info interface)
1. Needed for proxy/delegation cases (federated clusters) where auth method is non-transitive (like x509 client cert auth)
1. Allows authenticating at the edge, forwarding requests as the determined user (gated on the forwarding user's ability to impersonate)
1. Interaction with groupification? Proposal: impersonated data replaces
* ServiceAccount changes? (clayton/david)
1. Don't want to have the tokens in secrets?
1. Because service accounts store credentials in secrets anyone who can view secrets can grab the credentials and act on their behalf.
1. Possibly move service account tokens to their own resource
* Maybe a specific solution to a general problem. Do we need a permission system for secrets or general objects?
1. Secrets as subresource on serviceaccount. Only serviceaccounts can access secrets. User would have to be able to impersonate the service account to get at it.
1. https://github.com/kubernetes/kubernetes/issues/16779
1. https://github.com/kubernetes/kubernetes/issues/11070
* Image policy admission
1. Default deny (please)
1. Tag to immutable mapping? Image pull policy? Can we do it without an immutable image ID?
1. Particular registries don't have to have immutable image IDs to make decision.
## July 27th, 2016, 11a - Noon (Pacific Time)
* `kubectl login` (https://github.com/kubernetes/kubernetes/pull/29350)
1. "discovery" mechanism
1. Possibly don't want to add new paths to the API server.
1. Would be preferable if we could use more standard discovery mechanisms.
1. We can start kubectl login without discovery mechanism
* ServiceAccount changes? (clayton/david)
1. Don't want to have the tokens in secrets?
1. Because service accounts store credentials in secrets anyone who can view secrets can grab the credentials and act on their behalf.
1. Possibly move service account tokens to their own resource
* Maybe a specific solution to a general problem. Do we need a permission system for secrets or general objects?
1. Secrets as subresource on serviceaccount. Only serviceaccounts can access secrets. User would have to be able to impersonate the service account to get at it. \
* https://github.com/kubernetes/kubernetes/pull/27336 Add a generic admission controller that uses JSONPath for rules
1. Concerned about having to restart the server to have the changes take effect
1. Concerned about not having different rules per-subject
* Track resource creator? (david) https://github.com/kubernetes/kubernetes/pull/13925
1. This has been requested a lot. Some controllers want to know who created something initially. Could also be used for special authorization rules that allow creators/owners access (mentioned in SA/secret item)
1. This feature seems questionable. In a world with mutable resources tracking just a creator isn't sufficient to make ACL decisions.
1. **Clayton**: any other reason to reconsider?
* Current work
1. David
* subject access review from openshift to kube (needs api review)
* Enabling webhook token endpoint as on by default (rolled back)
1. Eric Chiang:
* kubectl login proposal
## July 13th, 2016, 11a - Noon (Pacific Time)
* Jordan to report on webhook vs native OpenStack auth options.
1. Authentication (https://github.com/kubernetes/kubernetes/pull/25391)
* Adds token auth, remote authn call
* Converting to webhook would lose project id and keystone roles
* It uses those for authz? Put them into user.Info.Extra (maybe, but not first)
* First class plugin is reasonable
* Can we convert roles to groups? Not immediately straightforward because roles are scoped to projects.
1. Authorization (https://github.com/kubernetes/kubernetes/pull/25624)
* On hold until we know how keystone roles are being mapped.
* Set Goals for 1.4?
1. Groupification changes (bobbyrullo as I recall)? Picked up by Eric Chiang. Not for 1.4
1. RBAC alpha (target 1.4) - Eric Chiang
* GCE test should run with it on
* Default set of roles
* Default ServiceAccount roles
1. Rbac up to beta level (target 1.5):
* On by default for auto-set up cluster
* API working
* Not mixing resource/non-resource rules
1. `kubectl login` Eric Chiang
* (ericchiang): would like to discuss requirements for initial "kubectl login" command: https://github.com/kubernetes/kubernetes/pull/25758
1. Include basic auth challenge handling
* [Example challenge handler in OpenShift](https://github.com/openshift/origin/blob/master/pkg/cmd/util/tokencmd/)
* ChallengeHandler interface (basic, negotiate, and multi impls)
* Basic handler can use specified user/pass or prompt from stdin
* Negotiate handler can use gssapi libs if present (via dlopen)
* ServiceAccount changes? (clayton/david)
1. Don't want to have the tokens in secrets?
1. Because service accounts store credentials in secrets anyone who can view secrets can grab the credentials and act on their behalf.
1. Possibly move service account tokens to their own resource
* Maybe a specific solution to a general problem. Do we need a permission system for secrets or general objects?
1. Secrets as subresource on serviceaccount. Only serviceaccounts can access secrets. User would have to be able to impersonate the service account to get at it. \
* https://github.com/kubernetes/kubernetes/pull/27336 Add a generic admission controller that uses JSONPath for rules
* Track Creator?
## June 29, 2016, 11a - Noon (Pacific Time)
* SIG business
* Jordan, David and Eric Chiang have volunteered to help lead.
* Security - Auth/Design/API dev is the primary focus, but this group will keep an eye to vulnerability management until there is enough more interest in a more vulnerability focused group.
* RBAC summary and next steps?
* API types and authorizer is in
* Basic documentation is in
* Next steps:
* API support for intent-driven operations (bind user to role, remove user from role, etc)?
* CLI tools?
* OpenStack: standalone plugin vs webhook approach, 1.4 direction
* Open PRs:
* https://github.com/kubernetes/kubernetes/pull/25624
* https://github.com/kubernetes/kubernetes/pull/25391
* https://github.com/kubernetes/kubernetes/pull/25536
* AI: Jordan to review open PRs, discuss webhook vs native with authors, summarize for next SIG
* Field level policy: https://github.com/kubernetes/kubernetes/pull/27330
* AI: Interested members comment on the proposal
* GCP
* Kubectl login: https://github.com/kubernetes/kubernetes/pull/25758
## June 15, 2016, 11a - Noon (Pacific Time)
Cancelled
## June 1, 2016, 11a - Noon (Pacific Time)
OpenStack Identity and Kubernetes (https://github.com/kubernetes/kubernetes/issues/25066) 15m.
## May 18, 2016, 11a - Noon (Pacific Time)
Cancelled due to upcoming release
## May 5, 2016, 11a - Noon (Pacific Time)
Group handling (https://github.com/kubernetes/kubernetes/issues/23720) - bobbyrullo
Service Account tokens for ubernetes: deads2k
Kubectl auth / refresh tokens: liggitt
Field level authorization (impacted by cascading delete): deads2k
Auto-loading of ABAC: etune
Suggestion of future agenda topics: everyone
## April 20, 2016, 11a - Noon (Pacific Time)
First meeting, introductions (5m)
Agenda: etune (5m)
Direction: etune(5m)
Suggestion of future agenda topics: everyone (5m)
Scopes vs. Extra on user.Info: deads2k (5m)
Field level authorization (impacted by cascading delete): deads2k (5m)
Service Account tokens for ubernetes: deads2k (5m)
Auto-loading of ABAC: etune (5m)
Kubectl auth / refresh tokens: liggitt (5m)
Intros
Eric Tune's view of priorities:
- P1: A default authorization system upstream, but allowing others
- P2: Address Image Security and Pod Security Policy
- P3: System Roles and Impersonation
deads2k plans to upstream just the subjectAccessReview parts of Openshift Auth.
ericchiang offered to help upstream the policy parts, and deads2k offered to review and consult.
Suggested future agenda topics:
- Group handling (https://github.com/kubernetes/kubernetes/issues/23720) - bobbyrullo
Scopes vs. Extra on user.Info: deads2k
- long discussion
- RedHat wants to have a server that gives out oauth tokens with scopes on them that say
the token was issued by user U, but the token is scoped to further restrict it to only do certain things.
- erictune asked why the user does not create a separate service account for this more narrowly scoped use case.
- Clayton said some of their customers do not want to use service accounts, for some reason.
- Someone (Jordan or David?) said it was easier to revoke user U's authentication, and then all their tokens are revoked too.
- We decided to allow the Extra info, rather than having a structured place to put scopes (which would then be the responsibility of kubernetes to manage the scopes and map to REST operations). Instead, individual authenticator and authorizer modules have to agree on how to interpret the Extra info. Suggest map with namespaced keys.
Field level authorization (impacted by cascading delete): deads2k
deads2k asked how we would handle cascading delete. If someone has permission to set the parent label of an object, but not delete the object, they can make the parent delete the object.
Or if they have permission to delete a parent object, they can make the controller delete children even if they don't have permission to delete the children (or not if we use Impersonate-User for the controller).
- We didn't get to finish this discussion.
Kubectl auth / refresh tokens: liggitt (5m)
- Long discussion
- Question about whether apiserver handling client secret is okay
- I'd like someone from community to summarize.
deads2k's perspective:
I think that we had discussions in three areas.
1. Any login command must be flexible enough to handle the different sorts of authentication providers we already have along with other likely standards. This means it should have plug-points for things like challenges (basic and kerberos use these). It should not be tied to a particular provider. I think we had agreement on this point. \
1. The API server should not be in business of providing authentication endpoints. This was only tangentially touched. We started and got distracted by item 3, so I don't know whether we agree or disagree. In my mind this is related to item 1. Core kube should be agnostic, but some sort of discovery or structured returns is probably necessary. \
1. Automatically attaching client secrets to refresh tokens presented to the API server. The current design has the API server attaching his own client secret to any refresh token submitted to it. This allows the token submitter to get back an access token without having the client secret to use the refresh token. It changes the oauth spec's requriement for two pieces of information (refresh token and client secret) to exchange a refresh token for an access token to a system requiring a single piece of information (refresh token). \
\
This was the big one. This takes us from a system where confidential clients are confidential, to a system where a confidential client is blindly attaching his secret to any request saying, "yep, that's me". This is concerns me a lot. @erictune has an google OIDC expert for a another opinion. I think I'd be less concerned if the server behaving this way wasn't our API server, but I'd still like to hear from another expert about whether it's a good idea or not.
Deferred for next meeting:
Field level authorization (impacted by cascading delete): deads2k
Service Account tokens for ubernetes: deads2k (5m)
Auto-loading of ABAC: etune (5m)

860
sig-auth/archive/meeting-notes-2017.md Normal file
View File

@ -0,0 +1,860 @@
# Kubernetes Sig-auth Meeting Agenda
## December 27, 2017 - No meeting, Christmas holiday
## December 13, 2017, 11a - Noon (Pacific Time)
* [Recording](https://youtu.be/hvbPwNpsflE)
* Announcements
* Code freeze lifts today
* kubernetes-wg-multitenancy - [google group](https://groups.google.com/forum/#!forum/kubernetes-wg-multitenancy)
* Demos
* Pulls of note
* User-facing RBAC policies for NetworkPolicy - [#56650](https://github.com/kubernetes/kubernetes/pull/56650) (already approved)
* Designs of note
* Proposal: bound service account tokens - [community#1460](https://github.com/kubernetes/community/pull/1460)
* Proposal: self-hosted webhook authorizers - [community#1458](https://github.com/kubernetes/community/pull/1458)
* Needs review:
* Encryption at rest: KMS gRPC plugin - [#55684](https://github.com/kubernetes/kubernetes/pull/55684)
* AI: sig-architecture office hours
* Rules review: express denies and add webhook support - [#53922](https://github.com/kubernetes/kubernetes/pull/53922)
* Reducing scope of node on node actions - [community#911](https://github.com/kubernetes/community/pull/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](https://www.youtube.com/watch?v=7EPCh8kymrM&list=PL69nYSiGNLP0VMOZ-V7-5AchXTHAQFzJw&index=1)
* Announcements
* Code freeze is coming Nov 22nd.
* Demos
* Pulls of note
* Kubectl OpenID Connect login (1.10) - [#55514](https://github.com/kubernetes/kubernetes/pull/55514)
* Separate login and rotation
* Figure out out of tree login/rotation
* KMS gRPC plugin (1.10) - [#55684](https://github.com/kubernetes/kubernetes/pull/55684)
* Concerns about another plugin mechanism
* Make sure that API machinery/API reviewers see this
* Allow nodes to impersonate service accounts of pods - [#55019](https://github.com/kubernetes/kubernetes/pull/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)
* [Recording](https://youtu.be/uDHNcZ0eGHI)
* Announcements
* Demos
* [SPIFFE SPIRE](https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/kubernetes-sig-auth/s3EX5Wmew_Q/1QaOLDb0AwAJ) - Evan Gilman (evan2645)
* https://github.com/spiffe/spiffe
* https://github.com/spiffe/spire
* Pulls of note
* Google Cloud KMS removal! - [54759](https://github.com/kubernetes/kubernetes/pull/54759) - from [54439](https://github.com/kubernetes/kubernetes/pull/54439) . This kills [51760](https://github.com/kubernetes/kubernetes/pull/51760)
* Short-circuit deny - [#53273](https://github.com/kubernetes/kubernetes/pull/53273) (looks ready to merge, but affects selfsubjectrulesreview)
* SelfSubjectRulesReview support for webhook authorizer - [#53922](https://github.com/kubernetes/kubernetes/pull/53922) - what do we do with short-circuit denies?
* Aggregated RBAC roles - [#54005](https://github.com/kubernetes/kubernetes/pull/54005) - needs review cycles
* Designs of note
* [External KMS](https://github.com/kubernetes/kubernetes/issues/51965#issuecomment-340850795) - Homework for next time
* [Strawman](https://docs.google.com/document/d/1S_Wgn-psI0Z7SYGvp-83ePte5oUNMr4244uanGLYUmw/edit?ts=59f965e1#) for discussion.
* Discussions
* Admission plugins - PSP mutate/validate split in particular
* kube-apiserver insecure port deprecation and eventual removal
* API aggregation requires secured port
* Doesn't support admission plugins wanting authorizers
* Going to be difficult in the cluster scripts, but we'll hit and resolve bumps there. - https://kubernetes.io/docs/tasks/access-kubernetes-api/http-proxy-access-api/
* For 1.10, external SA token creation and mounting
* Clayton/MikeDanese? to send sketch.
## October 18, 2017, 11a - Noon (Pacific Time)
* [Recording](https://youtu.be/P6oY2FdqYvY)
* Announcements
* New experimental [AWS IAM webhook authenticator](https://github.com/heptiolabs/kubernetes-aws-authenticator) @mattmoyer
* Demos
* Pulls of note
* Authorizer support for unequivocal deny - [#53273](https://github.com/kubernetes/kubernetes/pull/53273)
* Aggregated RBAC roles - [#54005](https://github.com/kubernetes/kubernetes/pull/54005)
* SelfSubjectRulesReview support for webhook authorizer - [#53922](https://github.com/kubernetes/kubernetes/pull/53922)
* Designs of note
* [Trustworthy Workload JWTs (v2 of previous doc)](https://docs.google.com/a/google.com/document/d/1jyQjfIOJxOMpyuSV5EBpJY97TjOet6nRJ95zroeKO7k/edit?usp=sharing)
* Discussions
## October 4, 2017, 11a - Noon (Pacific Time)
* [Recording](https://youtu.be/qA-UrUsqujw)
* Announcements
* 1.8 release retrospective this week, 10/6 at 10a PST - [agenda](https://docs.google.com/document/d/1pZ_hOxrwwPHA2lEWaJizfkvf80eMluVCBw9PDwj8oMA/edit#)
* Demos
* [audit2rbac](https://github.com/liggitt/audit2rbac) - @liggitt
* Potential [solution for using this on GKE](https://github.com/kubernetes/kubernetes/issues/53455).
* Pulls of note
* CSR Cleanup Controller - #[51840](https://github.com/kubernetes/kubernetes/pull/51840)
* PodSecurityPolicy ordering, non-mutation - #[52849](https://github.com/kubernetes/kubernetes/pull/52849)
* Designs of note:
* Reduce scope of node on node object ([kubernetes/community#911](https://github.com/kubernetes/community/pull/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](https://github.com/kubernetes/community/pull/888))
* [Verifying Workload JWTs](https://docs.google.com/document/d/1pyauN6hffhVbc3xdgi6fGsp0p189xgGaX9k4poOHK9s/edit)
* 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](https://github.com/kubernetes/kubernetes/pull/52849), [#45358](https://github.com/kubernetes/kubernetes/pull/45358) @liggitt
* GCE/GKE/CI enablement - [#52367](https://github.com/kubernetes/kubernetes/pull/52367) @tallclair
* bootstrapping/default policy - [#52367](https://github.com/kubernetes/kubernetes/pull/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](https://github.com/kubernetes/community/pull/723) @php-coder?
* Node label/taint restriction - [features#279](https://github.com/kubernetes/features/issues/279), [community#911](https://github.com/kubernetes/community/pull/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](https://github.com/kubernetes/community/pull/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
* https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/kubernetes-sig-auth/lbnMMXq7TyA/qUHNNJSNBwAJ
* Design for out-of-process KMS provider API - ~~@jcbsmpsn~~
* https://github.com/kubernetes/kubernetes/issues/51965
* Vault as KMS provider - @kk, @deads2k
* https://github.com/kubernetes/community/pull/888
* https://github.com/kubernetes/kubernetes/pull/51760
* This is our second implementation for sorting out what an out of process extension point would look like.
* The hope is this work provides more information to facilitate a general integration mechanism - https://github.com/kubernetes/kubernetes/issues/51965
* AWS as KMS provider - @mattmoyer (tentative)
* https://github.com/kubernetes/kubernetes/issues/52916
* Blocked on out-of-process extension point (WIP/discussion:???)
* Bug for adding an interface to allow out of process integration of KMS providers - https://github.com/kubernetes/kubernetes/issues/51965
* 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](https://youtu.be/jRvlrRKDSs4)
* Pulls of note
* [#52367](https://github.com/kubernetes/kubernetes/pull/52367) - PSP config, looks dependent on [50169](https://github.com/kubernetes/kubernetes/pull/50169)
* [#52654](https://github.com/kubernetes/kubernetes/pull/52654) - Add pod disruption budgets to admin/edit/view roles
* Designs of note:
* [Vault KMS Provider](https://github.com/kubernetes/community/pull/888) - Likely for 1.9. Comments so far look minor, request for reviews
* Needs [the plugin mechanism to work](https://github.com/kubernetes/kubernetes/issues/51965) since vault isn't a cloud provider, see [#48574](https://github.com/kubernetes/kubernetes/pull/48574) for background discussion
* deads to follow up with api machinery
* [Verifying Workload JWTs](https://docs.google.com/document/d/1pyauN6hffhVbc3xdgi6fGsp0p189xgGaX9k4poOHK9s/edit)
* 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](https://github.com/jetstack-experimental/cert-manager) for automatic acquisition and renewal of x509 certificates for TLS in Kubernetes from a variety of issuing sources / [incubator proposal](https://github.com/jetstack-experimental/cert-manager/pull/50) - @munnerz
* Note: incubator was recently [frozen until after the election](https://groups.google.com/forum/#!topic/kubernetes-dev/iaHlJnA1T4Y)
* 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](https://github.com/kubernetes/kubernetes/issues/51862)
* 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](https://youtu.be/t6O8MZ5tgAg)
* Announcements
* Container identity working group meets [Friday 11am EST](https://groups.google.com/forum/#!topic/kubernetes-wg-container-identity/IeKC18iFf9w)
* Code freeze on September 1st
* Demos
* SPIFFE + SPIRE overview (Evan Gilman, [Scytale](https://www.scytale.io/)) ~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](https://github.com/kubernetes/kubernetes/pull/50933))
* Client cert rotation to beta ([#51045](https://github.com/kubernetes/kubernetes/pull/51045))
* Configurable OIDC value prefixes ([#50875](https://github.com/kubernetes/kubernetes/pull/50875))
* Google cloud KMS provider ([#48574](https://github.com/kubernetes/kubernetes/pull/48574#issuecomment-324082506))
* Designs of note:
* Reduce scope of node on node object ([kubernetes/community#911](https://github.com/kubernetes/community/pull/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](https://github.com/kubernetes/community/pull/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](https://github.com/kubernetes/kubernetes/pull/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)
* [Recording](https://youtu.be/DJDuDNALcMo)
* Pulls of note
* Enable short caching of successful token authentication ([#50258](https://github.com/kubernetes/kubernetes/pull/50258))
* E2E node tests ([#49869](https://github.com/kubernetes/kubernetes/pull/49869)), blocked on moving sig-auth e2e tests ([#48966](https://github.com/kubernetes/kubernetes/pull/48966))
* CSR approver, adding resync ([#49788](https://github.com/kubernetes/kubernetes/pull/49788))
* Node authorizer on by default in local-up-cluster ([#49812](https://github.com/kubernetes/kubernetes/pull/49812)) (merged)
* Designs of note:
* Rules review API proposal ([kubernetes/community#887](https://github.com/kubernetes/community/pull/887))
* Out-of-tree keystone authenticator/authorizer ([link](https://groups.google.com/forum/#!topic/kubernetes-sig-openstack/mJQ2jjXRZno))
* Discussions
* [Generating RBAC profiles](https://docs.google.com/document/d/1jyNDETzIUDJWo2ZNscCM7C4scB7U73lSvdrgDy79wyw/edit#) (@tallclair)
* Request to cherry pick an OIDC server fix ([#48907](https://github.com/kubernetes/kubernetes/pull/48907))
* Container identity working group kickoff summary
* [Recording](https://www.youtube.com/watch?v=jcQ0mY7PQ8c&feature=youtu.be)
* Talked through the proposal and boundaries
* [Initial proposal](https://docs.google.com/document/d/1bCK-1_Zy2WfsrMBJkdaV72d2hidaxZBhS5YQHAgscPI/edit) for the wg
* Greg Castle's [design discussion](https://docs.google.com/document/d/1no8rYJ_nzhMeXYLL6JLjVSDtrj7pd6CBBfE3cPGOv8g/edit#heading=h.xgjl2srtytjt)
* [Mailing list ](https://groups.google.com/forum/#!forum/kubernetes-wg-container-identity)
* SIG apps charts + RBAC discussion
* [Recording](https://www.youtube.com/watch?v=eaQlsRoZVqs)
* [Notes](https://docs.google.com/document/d/1LZLBGW2wRDwAfdBNHJjFfk9CFoyZPcIYGWU7R1PQ3ng/edit#heading=h.9hy2gp3abcm5)
## July 26th, 2017, 11a - Noon (Pacific Time)
* [Recording](https://youtu.be/0ENcstWC06k)
* Pulls of note
* Allow nodes to evict their own pods ([#48707](https://github.com/kubernetes/kubernetes/pull/48707))
* Best practices for secrets ([#4380](https://github.com/kubernetes/kubernetes.github.io/pull/4380))
* Selfsubjectrulesreview ([#48051](https://github.com/kubernetes/kubernetes/pull/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](https://github.com/kubernetes/kubernetes/pull/49638))
* RBAC v1 ([#49642](https://github.com/kubernetes/kubernetes/pull/49642))
* Designs of note
* Giving nodes write access to pvc/status ([proposal](https://github.com/kubernetes/community/pull/657/files))
* kubeadm (alpha) HA implementation plan ([doc link](https://docs.google.com/document/d/1ff70as-CXWeRov8MCUO7UwT-MwIQ_2A0gNNDKpF39U4/edit#))
* Vault based KMS provider for secrets in etcd3 ([doc link](https://docs.google.com/document/d/15-baW4i7qws1yxxIYjHXqKpk259ebauQbECQCpPD308/edit#heading=h.67bgmqyjswzf), kk.sriram)
* This design is based off the in-flight implementation for Google Cloud KMS integration sakshamsharma has been writing (issue [#48522](https://github.com/kubernetes/kubernetes/issues/48522)), PRs: [#48574](https://github.com/kubernetes/kubernetes/pull/48574), [#49350](https://github.com/kubernetes/kubernetes/pull/49350),[ #49742](https://github.com/kubernetes/kubernetes/pull/49742)
* Discussions
* Dynamic authz and audit webhook configuration (along the lines of [Dynamic Admission Control](https://kubernetes.io/docs/admin/extensible-admission-controllers/) 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? https://github.com/kubernetes/kubernetes/issues/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](https://www.youtube.com/watch?v=9XAQriZ06CI&list=PL69nYSiGNLP0VMOZ-V7-5AchXTHAQFzJw&index=1)
* Demo
* Liz Rice - [kube-bench](https://github.com/aquasecurity/kube-bench) demo - July 12th
* Get involved in CIS benchmarks: https://groups.google.com/forum/#!searchin/kubernetes-sig-auth/cis%7Csort:relevance/kubernetes-sig-auth/mJbmwzKTMqY/jDgZWM26DAAJ
* Will be updated with the 1.7 benchmark
* Has issues with different install tools
* Could use help with those default locations
* Discussions:
* API resources with Secret information: embed or reference secrets? (Paul Morie)
* Needed for [service-catalog work](https://github.com/kubernetes-incubator/service-catalog/issues/621)
* 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](https://github.com/kubernetes/community/pull/443)
* **Action item:** Need to formalize this "don't list/watch all secrets" opinion.
* Usability of managing permissions individually:
* How to express "grant access to secrets referenced by object X to subject Y"
* [Issues with label-aware RBAC](https://github.com/kubernetes/ingress/issues/816#issuecomment-309630254)
* Additional TLS validation in the kubeadm bootstrap/discovery API ([WIP proposal](https://docs.google.com/document/d/1SP4P7LJWSA8vUXj27UvKdVEdhpo5Fp0QHNo4TXvLQbw/edit#)) (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](https://github.com/kubernetes/features/issues/2) - @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. https://github.com/kubernetes/kubernetes.github.io/issues/2792) - @liggitt, @ericchiang, …?
* [NodeRestriction control over pod steering](https://github.com/kubernetes/features/issues/279) (prevent adding labels, prevent removing taints / deleting while tainted) - @liggitt
* [Audit logging beta](https://github.com/kubernetes/features/issues/22) - @tallclair, @ericchiang, …?
* TLS rotation ([client](https://github.com/kubernetes/features/issues/266), [server](https://github.com/kubernetes/features/issues/267)) beta @jcbsmpsn
* Container identity working group - @smarterclayton, @destijl
* PodSecurityPolicy enablement - @tallclair
* [Kubernetes Secrets: Roadmap](https://docs.google.com/document/d/1JAwPuZg47UhfRVlof-lMw08OJztunW8pvTNxDK3rCF8/edit#) work - @destijl, @smarterclayton, …?
* Add [support for storing secrets encryption key in Google KMS](https://github.com/kubernetes/kubernetes/issues/48522) @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)
* Not recorded
* Pull requests of note:
* Azure client auth plugin merged -[ #43987](https://github.com/kubernetes/kubernetes/pull/43987)
* Designs of note:
* Secrets roadmap? - gcastle?
* Didn't happen. Maybe next meeting?
* Release Issues:
* [All issues marked for 1.7](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+milestone%3Av1.7+label%3Asig%2Fauth)
* Update base images - [#47386](https://github.com/kubernetes/kubernetes/issues/47386)
* E2E testing of alpha features is broken - [#47283](https://github.com/kubernetes/kubernetes/issues/47283)
* PSP paths allow ".." - [#47107](https://github.com/kubernetes/kubernetes/issues/47107)
* GCE Load-Balancer Controller using insecure port - [#46983](https://github.com/kubernetes/kubernetes/issues/46983)
* Demo
* Aqua Secrets - Amir Jerbi
* https://www.aquasec.com/products/aqua-container-security-platform/
* Federated secret store (is backed by vault, kms, etc.)
* Injects secrets into containers using a sidecar.
* http://blog.aquasec.com/injecting-secrets-kubernetes-hashicorp-vault-and-aqua-on-azure
* How does this fit into secrets roadmap?
* https://docs.google.com/document/d/1JAwPuZg47UhfRVlof-lMw08OJztunW8pvTNxDK3rCF8/edit
* Parts possibly going to be open source?
* Questions
* Openstack auth
* Many of the current PRs/Issues for Authn/z backed by Keystone are either abandoned, experimental, or have issues with security.
* Openstack provider uses Keystone backed by MySQL. 250+ users, with 2,000+ tenants (tenant per app). Looking for the current recommendations on using Keystone as the source for user auth and roles.
* Would prefer if Keystone was backed by LDAP, but this is not possible in this case.
* Looking to discuss authn against Keystone, along with status of RBAC role mapping to keystone domains and groups.
* Openstack authn/z plugins should be developed out of tree and use the token webhook, authz webhook, and/or RBAC syncing (read policy from keystone and create associated RBAC rules)
* https://kubernetes.io/docs/admin/authentication/#webhook-token-authentication
* https://kubernetes.io/docs/admin/authorization/webhook/
* _Action item_: add better examples of webhook servers?
### 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](https://youtu.be/E_3L8dFaha0)
* Pull requests of note:
* Kubelet serving cert creation/rotation merged - [#45059](https://github.com/kubernetes/kubernetes/pull/45059)
* Node authorizer merged - [#46076](https://github.com/kubernetes/kubernetes/pull/46076)
* [S](https://github.com/kubernetes/kubernetes/pull/40760)A[R](https://github.com/kubernetes/kubernetes/pull/40760) [A](https://github.com/kubernetes/kubernetes/pull/40760)p[p](https://github.com/kubernetes/kubernetes/pull/40760)r[o](https://github.com/kubernetes/kubernetes/pull/40760)v[e](https://github.com/kubernetes/kubernetes/pull/40760)r[ ](https://github.com/kubernetes/kubernetes/pull/40760)m[e](https://github.com/kubernetes/kubernetes/pull/40760)r[g](https://github.com/kubernetes/kubernetes/pull/40760)e[d](https://github.com/kubernetes/kubernetes/pull/40760) [-](https://github.com/kubernetes/kubernetes/pull/40760) [#45619](https://github.com/kubernetes/kubernetes/pull/40760)
* Kubelet client cert rotation - [#41912](https://github.com/kubernetes/kubernetes/pull/41912)
* Kubelet TLS bootstrap in GCE/GKE - [#40760](https://github.com/kubernetes/kubernetes/pull/40760)
* Designs of note:
* Nothing new
* End of release stuff:
* [Bugs](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Fauth+label%3Akind%2Fbug) (1)
* [Flakes](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Fauth+label%3Akind%2Fflake) (0)
* [PRs](https://github.com/kubernetes/kubernetes/pulls?q=is%3Aopen+is%3Apr+label%3Asig%2Fauth+milestone%3Av1.7)
* 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](https://youtu.be/9MdFd_9CwVw)
* Pull requests of note:
* Mirror pod restriction/validation [#45775](https://github.com/kubernetes/kubernetes/pull/45775)
* NodeRestriction admission plugin [#45929](https://github.com/kubernetes/kubernetes/pull/45929)
* Proposal: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/kubelet-authorizer.md
* Migrate group approver to use subject access review [#45619](https://github.com/kubernetes/kubernetes/pull/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](https://github.com/kubernetes/kubernetes/pull/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.
* Doc: https://docs.google.com/document/d/1KQNZmNMvViE4us44jIj8k-eOkhTGV21Sq42rNrizlGg/edit?ts=591caaeb#
* Designs of note (may kubernetes/community PRs discussed in previous meetings):
* [Kubernetes Secrets: Updated Roadmap](https://docs.google.com/document/d/1JAwPuZg47UhfRVlof-lMw08OJztunW8pvTNxDK3rCF8/edit#).
* TL;DR - Try to get identity so we can use external stores.
* 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](https://www.youtube.com/watch?v=dLXz1T1yxXw)
* Pull request of note:
* Certificate rotation for kubelet serving certs https://github.com/kubernetes/kubernetes/pull/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: https://github.com/kubernetes/kubernetes/issues/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](https://github.com/kubernetes/community/pull/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](https://github.com/kubernetes/community/pull/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](https://docs.google.com/document/d/1GjurNK2ROw4rXz-k-l68JtpGRkGj2fZcWqP6gksEriQ/edit#heading=h.pq1kki84bhak).
* 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](https://www.youtube.com/watch?v=eT35tfepKGE)
* Pull requests of note
* Reduce allocations by RBAC authorizer - [#44449](https://github.com/kubernetes/kubernetes/pull/44449) (@liggitt)
* Designs of note
* [Auth setup for federation control plane](https://docs.google.com/document/d/1ioBg6Nn7PwyAAY48S42VQ0Zr1LXY5IAnMbBsftmE8DI/edit?ts=58f56a16) - (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](https://docs.google.com/document/d/1pH9jn4mj0Dap2LSEYFJDNP7JCE8ScIQoSGysfdzfv9s/edit#heading=h.gw8roqrqd77p) 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](https://github.com/kubernetes/community/pull/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 https://github.com/kubernetes/community/pull/145
* View the namespaces as your security boundary.
* Discussion around svc 2 svc auth. Joe brought up [SPIFFE](https://spiffe.io) (again).
## April 5th, 2017, 11a - Noon (Pacific Time)
* [Recorded meeting](https://www.youtube.com/watch?v=OfgnBOlSj_A&index=1&list=PL69nYSiGNLP0VMOZ-V7-5AchXTHAQFzJw)
* Pull requests of note
* Brainstorm role name for read access to storageclasses - [#40881](https://github.com/kubernetes/kubernetes/pull/40881) (@seh)
* PodSecurityPolicy: limit which host paths are allowed - [#43946](https://github.com/kubernetes/kubernetes/pull/43946) (@jhorwit2)
* PodSecurityPolicy: allow within particular namespaces - [#42360](https://github.com/kubernetes/kubernetes/pull/42360) (@liggitt)
* Enable service account token lookup/revocation - [#24167](https://github.com/kubernetes/kubernetes/issues/24167), [#44071](https://github.com/kubernetes/kubernetes/pull/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](https://github.com/kubernetes/kubernetes/pull/44076) (@liggitt)
* Remove special-case handling for unsecured port - [#43888](https://github.com/kubernetes/kubernetes/pull/43888) (@liggitt)
* Designs of note
* Threat models WIP - [#504](https://github.com/kubernetes/community/pull/504) (@smarterclayton)
* Security proposals/designs refresh - [#500](https://github.com/kubernetes/community/pull/500) (@smarterclayton)
* Kubectl client auth plugins
* Azure, [#43987](https://github.com/kubernetes/kubernetes/pull/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](https://github.com/kubernetes/kubernetes/pull/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)
* https://groups.google.com/forum/#!topic/kubernetes-sig-auth/mJbmwzKTMqY
* Lots of suggested settings (tickets) that could use input from sig-auth members
* Timeframe is 6-8 weeks to completion
* 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](https://github.com/kubernetes/community/blob/master/sig-list.md) have 2-3 leads (though feedback on that is welcome)
## March 22nd, 2017, 11a - Noon (Pacific Time)
* [Recorded meeting](https://www.youtube.com/watch?v=SyU6aerXUKo&list=PL69nYSiGNLP0VMOZ-V7-5AchXTHAQFzJw&index=1)
* 1.6 close-out
* Discussion re https://groups.google.com/forum/#!topic/kubernetes-sig-auth/diw9LH67iIs
* Keep kube-up.sh running with legacy ABAC policy by default ([#43544](https://github.com/kubernetes/kubernetes/pull/43544) cjcullen, liggitt)
* Continue running some CI jobs with RBAC-only to ensure coverage
* Run upgrade CI jobs with legacy ABAC policy to ensure coverage ([#2330](https://github.com/kubernetes/test-infra/pull/2330), liggitt)
* Follow ups:
* Document intended "secure" profile? (clayton)
* Warning about starting in insecure mode (no good place to surface in kube-up today)
* "security profile" options ("insecure", "secured", "multitenant", etc)?
* Release notes
* Kubeadm's release notes need more details? (ericchiang will follow up)
* kube-up.sh on GCE enables rbac and insecure abac policy by default. Needs to document option to start kube-up.sh without legacy ABAC policy (liggitt/cjcullen)
* Doc PRs
* https://github.com/kubernetes/kubernetes.github.io/pull/2940/
* https://deploy-preview-2940--kubernetes-io-master-staging.netlify.com/docs/admin/authorization/rbac/#service-account-permissions
## March 8th, 2017, 11a - Noon (Pacific Time)
* [Recorded meeting](https://www.youtube.com/watch?v=ri6BVhCMKB8)
* 1.6 close-out
* RBAC
* [documentation available in preview](https://kubernetes-io-vnext-staging.netlify.com/docs/admin/authorization/rbac/)
* Enabled by default in kubeadm, kube-up, bootkube
* kops is [proposing](https://github.com/kubernetes/kops/pull/2039/files#diff-38574c080d4e2eb38c49b86e6588ad98R8) to enable RBAC by default (their 1.6 lags k8s)
* Secured Kubelet API
* Enabled by default in kubeadm, kube-up, bootkube
* [Flakes](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aopen+label%3Asig%2Fauth+label%3Akind%2Fflake+milestone%3Av1.6): 0
* [Bugs](https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=%20is%3Aopen%20label%3Asig%2Fauth%20label%3Akind%2Fbug%20milestone%3Av1.6%20): 1
* 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](https://github.com/kubernetes/kubernetes/issues/38541)
* Partitioned namespaces, service accounts, accompanying roles, etc
* Implementation work
* Node authorizer - [#40476](https://github.com/kubernetes/kubernetes/issues/40476), @liggitt
* PodSecurityPolicy improvements - [#23217](https://github.com/kubernetes/kubernetes/issues/23217), @liggitt
* CSR auto-approval switch from hard-coded group to authz check using SubjectAccessReview - @liggitt
* Encrypt secrets at rest - [#12742](https://github.com/kubernetes/kubernetes/issues/12742), @erictune, @smarterclayton
* Groupification - [#23720](https://github.com/kubernetes/kubernetes/issues/23720#issuecomment-284032814), @ericchiang
* OIDC plugin maintenance - [#42654](https://github.com/kubernetes/kubernetes/issues/42654), @ericchiang
* Kubelet server cert bootstrapping @jcbsmpsn
* Kubelet client certificate rotation [#4672](https://github.com/kubernetes/kubernetes/issues/4672), @jcbsmpsn
* Audit Logging [features#22](https://github.com/kubernetes/features/issues/22), @timstclair, @cjcullen, @ericchiang, others?
* Seccomp enabled by default [#39845](https://github.com/kubernetes/kubernetes/issues/39845) , [#145](https://github.com/kubernetes/community/pull/145) @timstclair
* Design/Roadmap work
* Bulk namespace access control [#40403](https://github.com/kubernetes/kubernetes/issues/40403) @cmluciano, @smarterclayton
* [Roadmap](https://docs.google.com/document/d/1T2y-9geg9EfHHtCDYTXptCa-F4kQ0RyiH-c_M1SyD0s/edit?ts=58bf234e#) for secrets, and integration with external secret stores @erictune
* [Extensible admission](https://github.com/kubernetes/community/pull/132) (in concert with sig-api-machinery)
* Backlog
* CRL support - [#33519](https://github.com/kubernetes/kubernetes/pull/33519) (might be mitigated by rotation / shorter expirys)
## February 22nd, 2017, 11a - Noon (Pacific Time)
* Meeting cancelled
## February 8th, 2017, 11a - Noon (Pacific Time)
* [Recorded meeting](https://www.youtube.com/watch?v=DZShqi2eDOc)
* Representative from sig-auth to PM group (5 minutes, cjcullen)
* CIS security benchmark for kubernetes (15 minutes, praving5)
* https://groups.google.com/d/msgid/kubernetes-sig-auth/da0aba5b-9285-487c-b236-34ebddfd0d8a%40googlegroups.com
* SubjectAccessReview, TokenReview promotion to v1 (5 minutes, liggitt)
* https://github.com/kubernetes/kubernetes/pull/40709
* https://github.com/kubernetes/kubernetes/pull/41058
* Auto-reconciliation of bootstrap roles/rolebindings (5 minutes, liggitt)
* https://github.com/kubernetes/kubernetes/pull/41155
* Add missing permissions to bootstrap roles on server start
* Add missing subjects to bootstrap rolebindings on server start
* No auto-removal of permissions or subjects
* Can opt out of auto-reconciliation by annotating roles/rolebindings (become responsible for manually updating with new permissions/subjects)
* Eventually could be moved to a controller loop
## January 25th, 2017, 11a - Noon (Pacific Time)
* [Recorded meeting](https://www.youtube.com/watch?v=5mYdRXR9ZfM&list=PL69nYSiGNLP0VMOZ-V7-5AchXTHAQFzJw)
* 1.5 cherry picks
* OIDC client-side performance fix
* https://github.com/kubernetes/kubernetes/pull/40191
* Fix for requestheader proxy client cert prompt
* https://github.com/kubernetes/kubernetes/pull/40301
* RBAC v1beta1 released, API enabled by default (liggitt)
* https://github.com/kubernetes/kubernetes/pull/39625
* RBAC rollout for 1.6 (liggitt, cjcullen)
* Doc overview - https://kubernetes.io/docs/admin/authorization/#rbac-mode
* Built-in role documentation (in progress) - https://github.com/kubernetes/kubernetes.github.io/pull/2169/files?short_path=48e69c0#diff-48e69c0b942ef9dcc93b90046d09f9e6
* kubeadm enablement
* https://github.com/kubernetes/kubernetes/pull/39846
* kops enablement
* https://github.com/kubernetes/kops/pull/1357/files
* kube-up.sh with GCE provider enables RBAC by default
* ABAC enablement on upgrade in progress
* GKE enablement for 1.6 in-progress
* Should new clusters provide an option to start with legacy ABAC?
* Should new clusters provide an option to start with permissive RBAC?
* Default roles and role-bindings being added in-tree:
* https://github.com/kubernetes/kubernetes/tree/master/plugin/pkg/auth/authorizer/rbac/bootstrappolicy/testdata
* Docs in progress (working with docs team to find a home for 1.6 docs)
* Multidimensional multi-tenancy (mspreitz, clayton, liggitt)
* Per-namespace DNS: https://github.com/kubernetes/community/pull/269
* API isolation (API authorization)
* Service isolation (DNS and/or network policy, explicit service references)
* Network isolation (network policy)
* Interested sigs:
* apimachinery (for watching across a subset of namespaces)
* networking (for dns and kube-proxy implications, API shape)
* service-catalog (for explicit service references)
* many:many visibility
* Problem space:
* One namespace per cluster
* Possibly have a shared one that all namespaces need to hit.
* How many "tenants", how big?
* Performance issues with kube-dns if you have a lot of tenants?
* Policy aware DNS server vs per-namespace DNS server.
* In openshift, kube-proxy is the DNS server.
* Have to go through kube-proxy to talk to service, extends nicely to DNS.
* Kube-proxy would have to understand policy too.
* Network policy is only pod selection and only ingress today.
* Maybe some sort of API that declares "I consume these service"?
* Are service accounts a good proxy for a pod identity?
* Could we say something like "if a pod's service account can see a service it can access the service"?
* Efficient subdivision of namespaces into groups (tenancy of organizations)
* https://github.com/kubernetes/kubernetes/issues/40403
* efficient multi-namespace watch and authorization
* SIG Auth update to Kubernetes Community
* liggitt will present RBAC status for 1.6
* Discussions about secrets
* Encryption at rest (in etcd).
* https://github.com/kubernetes/kubernetes/issues/12742
* https://github.com/kubernetes/features/issues/92
* Subdivision access (ingress vs build vs serviceaccount)
* https://github.com/kubernetes/kubernetes/issues/18725
* https://github.com/kubernetes/kubernetes/issues/4957
* External injection without visibility in the API (e.g. Vault)
* https://github.com/kubernetes/kubernetes/issues/10439
* https://github.com/kubernetes/kubernetes/issues/28538
* Future work: subdivided node access
* Currently able to read all secrets, modify all pods
* Should limit to resources needed by pods bound to the node
* https://github.com/kubernetes/kubernetes/issues/40476
* Ericchiang: maybe related to [40403](https://github.com/kubernetes/kubernetes/issues/40403)?
## January 11th, 2017, 11a - Noon (Pacific Time)
* RBAC v1beta1
* https://github.com/kubernetes/kubernetes/pull/39625
* attributeRestrictions removed.
* Doc pull with default role explanation, command grant explanations: https://github.com/kubernetes/kubernetes.github.io/pull/2169
* RBAC rollout (deads, cjcullen, liggitt)
* Existing bring-up scripts used for CI and production
* https://github.com/kubernetes/kubernetes/issues/39532
* https://github.com/kubernetes/kubernetes/pull/39537
* 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
* https://github.com/kubernetes/kubernetes/issues/39639
* https://github.com/kubernetes/kubernetes/pull/39641
* 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) - https://github.com/kubernetes/kubernetes.github.io/pull/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
* Controller permissions, e2e new namespace permissions, kubelet permissions, etc
* https://groups.google.com/forum/#!msg/kubernetes-dev/gASoXHp52R8/3sEBdwGGFQAJ;context-place=forum/kubernetes-dev
* 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
* https://github.com/kubernetes/kubernetes/pull/39383

679
sig-auth/archive/meeting-notes-2018.md Normal file
View File

@ -0,0 +1,679 @@
# Kubernetes Sig-auth Meeting Agenda
## December 26, 2018, 11a - Noon (Pacific Time)
* Canceled for holidays
## December 12, 2018, 11a - Noon (Pacific Time)
* Canceled in lieu of kubecon seattle SIG events:
* [State of Kubernetes Security: Mon, December 10, 10:00am – 10:30am](http://bit.ly/kubernetes-summit) (contributors summit)
* [SIG Auth intro: Tuesday, December 11, 10:50am-11:25am](https://sched.co/Grd0)
* [SIG Auth deep dive: Thursday, December 13, 10:50am-11:25am](https://sched.co/Grez)
## November 28, 2018, 11a - Noon (Pacific Time)
* Recording
* Announcements
* [1.13 release notes draft](https://github.com/kubernetes/sig-release/pull/386) open for review ([preview](https://github.com/marpaia/sig-release/blob/1.13-release-notes/releases/release-1.13/release-notes-draft.md)), any comments on SIG Auth items welcome (search for "SIG Auth")
* Demos
* [kube-rbac-proxy](https://github.com/brancz/kube-rbac-proxy)
* Pulls of note
*
* Designs of note
*
* Discussion topics
* sig-auth ownership of [kube-rbac-proxy](https://github.com/brancz/kube-rbac-proxy)
* [@pbarker] Outgoing webhook auth https://docs.google.com/document/d/1rtnPnrW2Ws1I8h826oYwSKuqWif5SaRnm2jvwFH9lIk/edit?usp=sharing
* [@cjcullen,@tallclair] Request for feedback on contributor summit "State of Security" outline: https://docs.google.com/document/d/1m5tPasZJ_7IZDw_i-iQsEe7bNMa1VGlytHcI_I9jMOg/edit#
* [Clayton] Something about bootstrapping
* Unblocking static pods to run prior to establishing kubelet/API connection
* https://github.com/kubernetes/kubernetes/pull/71174 ?
* Action items
* @brancz will make issue for review of kube-rbac-proxy
## November 14, 2018, 11a - Noon (Pacific Time)
* Canceled due to kubecon china and code freeze
## October 31, 2018, 11a - Noon (Pacific Time)
* [Recording](https://youtu.be/xfj8wG4aG_0)
* Announcements
* Code freeze November 15th (middle of kubecon China)
* Demos
* Nikhil Bhatia @ Microsoft - Demo for Kubernetes Policy Controller -- https://github.com/Azure/kubernetes-policy-controller
* Pulls of note
* .
* Designs of note
* .
* Discussion topics
* [klizhentas] Discuss CSR API promotion out of beta https://github.com/kubernetes/kubernetes/issues/69836
* API shape/issues
* Requires requesters to know all the info about the end certificate
* Use for higher-level requests ("give me a node client cert", "give me a serving cert for a pod backing a service")
* Approval flow/issues
* Cannot limit or add components to request (limit or add SANs, usages, etc)
* Signing flow/issues
* Method for multiple signers to interact (or approver to indicate what signer should be used)
* Guarantees on issued certificates
* No (current) guarantee all requested extensions/SANs are issued
* No (current) guarantee issued client certificates will be accepted as API client certs
* [liggitt] [node self-labeling resolution](https://github.com/kubernetes/community/pull/911#issuecomment-434757411)
* NodeRestriction limits self-labeling under kubernetes.io and k8s.io
* [mikedanese] moving service account token secret mounts to projected volumes
* Breaks in the presence of PSPs that only allow secret volumes
* Ugly options:
* Change PSP to allow projected volumes if secret volumes are allowed
* …
* Discussion in [#69848](https://github.com/kubernetes/kubernetes/pull/69848#issuecomment-434158411)
* Action items
* [Mike] CSR ?
## October 17, 2018, 11a - Noon (Pacific Time)
* [Recording](https://youtu.be/-t680vY95NU)
* Announcements
* s/@liggitt/@enj/ in sig-auth chairs ([thread](https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/kubernetes-sig-auth/kqhoYhrzYLc/HBCOWEYKBQAJ), [PR](https://github.com/kubernetes/community/pull/2749))
* Pulls of note
* NodeRestriction prevents node label updates ([#68267](https://github.com/kubernetes/kubernetes/pull/68267))
* Preference for well-known labels and prefixes (zero-config)
* Will try to reconcile with proposed approach for CSI labels
* Will start thread with sig-node/storage/auth
* Possible that adding arbitrary labels on node create (kubelet --node-labels flag) could still be allowed
* Depends on nodes not being able to delete themselves
* Assumes a new node isn't compromised
* Alternative could be to taint nodes that register with unknown labels
* Might be useful to survey use of kubelet --node-labels flag
* authenticator interface change ([#69582](https://github.com/kubernetes/kubernetes/pull/69582))
* Plumbs context to allow cancelation of backend webhook token authn
* Add Response which includes Audience (expected audience of authn, needed for token review of non-api server audiences) and user.Info
* Old servers will ignore audience and hence not validate (so client side validation will be required for some time)
* Migrate service account volume to a projected volume ([#69848](https://github.com/kubernetes/kubernetes/pull/69848))
* Requires kubelets 1.6 or newer
* Concerns around the implicit API for SA token secret (contains both the token and the CA data, but we would like not to include the CA data and instead have a config map in the namespace/combining the data using a projected volume)
* AI: communicate that users that want to obtain service account credentials for use outside of pods should do so explicitly [with a dedicated secret](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#to-create-additional-api-tokens)
* AI: put together roadmap for:
* making it possible to stop auto-generating token secrets
* measure impact to kube/e2e/conformance as a sample of the issued users will encounter
* timeline for enabling that option by default
* timeline for removing the option to auto-generate token secrets
* Designs of note
* [KEP: authority delegation](https://github.com/kubernetes/community/pull/2794)
* Discussion topics
* [Seeding TL thread](https://groups.google.com/forum/#!topic/kubernetes-sig-auth/v0-Awf0rBOg)
* Need sub projects to merge, update owner files, and pick initial technical leads based on owner files
* Subproject PR - [#2525](https://github.com/kubernetes/community/pull/2525)
## October 3, 2018, 11a - Noon (Pacific Time)
* [Recording](https://youtu.be/9EA16cWHY7g)
* Announcements
* [liggitt] Kubernetes Third-Party Security Audit Team Formation ([link](https://github.com/kubernetes/sig-release/issues/284#issuecomment-426384132))
* [liggitt] Proposed sig-auth chair change ([thread](https://groups.google.com/forum/#!topic/kubernetes-sig-auth/kqhoYhrzYLc))
* [aishs] Update on k8s 1.13 timeline and discuss feature load
<span style="text-decoration:underline;">Features in 1.13 (from 1.12)</span>
* 1. [600: Dynamic Audit Configuration](https://github.com/kubernetes/features/issues/600) - pbarker
* 2. [22: API Audit Logging](https://github.com/kubernetes/features/issues/22) - tallclair
* 3. [542: TokenRequest API and Kubelet integration](https://github.com/kubernetes/features/issues/542) - mikedanese
* Pulls of note
*
* Discussion topics
* [pbarker] discuss changes to dynamic audit api https://github.com/kubernetes/community/pull/2738
* [enj] Should we allow admins/editors in a namespace to create events in that namespace (change default RBAC policy)?
* Audit is the system of record now (so the creation of fake events is less dangerous / they are not trusted sources of cluster information)
* Events are still useful for debugging
* Namespace scoped controller can use them to report failures
* Makes it easier to test on a cluster with limited access
* CI system could emit events to show progress or failures
* Users could falsely trust events made by a malicious party
*
## September 19, 2018, 11a - Noon (Pacific Time)
* [Recording](https://youtu.be/Ayfx3xTFmU4)
* Announcements
* v1.13 development timeline
* Subprojects:
* https://github.com/kubernetes/community/pull/2525
* Discussion topics
* Support an image pull credential flow built on bound service account tokens
* [kubernetes/kubernetes#68810](https://github.com/kubernetes/kubernetes/issues/68810)
* Bug bounty scope
* https://github.com/kubernetes/community/pull/2620
## September 5, 2018, 11a - Noon (Pacific Time)
* Cancelled, no agenda items, release is closing out
## August 22, 2018, 11a - Noon (Pacific Time)
* [Recording](https://youtu.be/VuxJwopD4nE)
* Announcements
* code slush 8/28, code freeze 9/4
* subprojects enumeration PR in progress - [#2525](https://github.com/kubernetes/community/pull/2525)
* Pulls of note
* [@pragashj] present and get feedback on [SAFE](https://github.com/cn-security/safe/blob/master/README.md), [WG proposal](https://github.com/cncf/toc/pull/146/files)
* co-chairs: Sarah Allen, Dan Shaw joined meeting to present and answer questions
* Tim Allclair has volunteered to act as liaison between the two groups
* [wteiken] Change to image review API: https://github.com/kubernetes/kubernetes/pull/64597
* [@pbarker] Dynamic audit PRs are up https://github.com/kubernetes/kubernetes/pull/67547
https://github.com/kubernetes/kubernetes/pull/67257
## August 08, 2018, 11a - Noon (Pacific Time)
* [Recording](https://www.youtube.com/watch?v=dTzDsrtjyT0)
* Announcements
* HashiCorp Vault KMS provider - [repo](https://github.com/oracle/kubernetes-vault-kms-plugin). Feedback welcome.
* Audit event type promotion to v1 - [#65891](https://github.com/kubernetes/kubernetes/pull/65891)
* Pulls of note
* New sig-auth charter: https://github.com/kubernetes/community/blob/master/sig-auth/charter.md
* Feedback welcome
* Follow up: listing subprojects & related responsibilities
* Remove basic auditing: https://github.com/kubernetes/kubernetes/pull/65862
* Part of advanced auditing going to GA
* Advanced auditing is not 100% compatible with the basic auditing log format
* Discussion
* Container-level service account: [kubernetes/community#2497](https://github.com/kubernetes/community/pull/2497)
* Concern: pod is the security boundary, separating permissions at the container level could create some unexpected attack vectors
* Useful for auditing
* Kubelet TLS Bootstrap GA [kubernetes/features#43](https://github.com/kubernetes/features/issues/43)
* client bootstrap flow to GA in 1.12
* client rotation stays in beta in 1.12
* server rotation promoted to beta in 1.12 (kubelet-only, must bring own approver)
* CSR API is still v1beta1. Some potential improvements desired before v1:
* approver has input to add/remove/modify the cert that is signed
* signing profiles
* integration to produce certs with service DNS names as SANs
## July 25, 2018, 11a - Noon (Pacific Time)
* [Recording](https://www.youtube.com/watch?v=PFGramA3F04)
* Announcements
* (kksriram) Reviewing the Vault KMS provider with HashiCorp this week. Goal is to make repo public this week.
* feature freeze is 7/31... be sure there are issues filed in [kubernetes/features](https://github.com/kubernetes/features/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Fauth) for feature work targeted at 1.12 by then
* Please check milestone labels are correct for v1.12
* [sig-auth features](https://github.com/kubernetes/features/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Fauth)
* Also if somebody might prune out anything that's there which is old/stale or done / not going to be done, that would be awesome. A lot of open 2016 and 2017 stuff for sig/auth.
* Discussion
* Discuss addition of dynamic policy to audit kep https://github.com/kubernetes/community/pull/2407
*
* Question for KEP process (take to sig-arch?)
* How do evolutions/additions to an accepted/implementable KEP fit with the provisional/implementable bit?
## July 11, 2018, 11a - Noon (Pacific Time)
* [Recording](https://www.youtube.com/watch?v=r2RoQpxXyr0)
* Discussion
* [plan for secrets](https://docs.google.com/document/d/1OVPuXDB759G_TIzTZ2jrKk-3EVJ4FUP9KNj5nMDOWZg/edit?ts=5b444461#) (@mayakacz, @immutableT)
* Improvements made:
* 1.7 - kubelet doesn't have access to arbitrary secrets when using the Node authorizer and NodeRestriction admission plugin (on by default in kubeadm and kube-up deployments)
* 1.7 - encryption at rest added in alpha state
* 1.10 - KMS extension point added in alpha state
* 1.11 - authorization of watches of individual secrets now possible (no longer require global watch authorization for controllers that only need particular secrets)
* Next steps?
* Promote encryption at rest from alpha
* https://github.com/kubernetes/kubernetes/pull/61592
* https://github.com/kubernetes/kubernetes/pull/63032
* Work with deployments to enable encryption at rest by default
* Promote KMS extension point
* need feedback from current known consumers ([Google Cloud KMS](https://github.com/GoogleCloudPlatform/k8s-cloudkms-plugin/),[ Microsoft Azure Key Vault](https://github.com/Azure/kubernetes-kms) and[ AWS KMS](https://github.com/kubernetes-sigs/aws-encryption-provider) plugins, one in the works for[ HashiCorp Vault](https://github.com/kubernetes/kubernetes/issues/49817))
* need an owner to drive this
* Continue work on audience/time-bound service account tokens in 1.12
* Stay involved with discussions of CSI volume plugins for secret injection
## June 27, 2018, 11a - Noon (Pacific Time)
* [Recording](https://www.youtube.com/watch?v=L_fnXbPhsmM)
* Announcements
* [New sig-auth chair](https://groups.google.com/forum/#!topic/kubernetes-sig-auth/R9scqXygqY8)
* New zoom meeting link (will update calendar and the link in this document)
* Demos
* Pulls of note
* [Add OIDC discovery to svcacct token issuer](https://github.com/kubernetes/community/pull/2314) (@mikedanese)
* Discussion
* Authorization length limits (@tallclair) - Do we want to support abusing the authorization interfaces for things completely unrelated to Kubernetes? For instance, many resources have a 253 character limit on names, but SubjectAccessReviews allow arbitrarily large values for name, resource, subresource, verb.
* What would the authorizer's response be if an API URL with a name segment longer than 253 chars was accessed?
* @tallclair will open issue proposing abuse limit (~8k, etc)
* Should detail behavior at each level if things that exceed that limit are presented
* Authorization layer is intentionally agnostic toward meaning of resource/subresource
* 1.12 planning/discussion deferred to next meeting because of 1.11 wrap-up
## June 13, 2018, 11a - Noon (Pacific Time)
* [Recording](https://www.youtube.com/watch?v=C5zbTKxGHR4)
* Announcements
* [1.11 release notes for review](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.11/release_notes_draft.md#sig-auth) - suggestions/pulls due by Friday, 6/15
* Demos
*
* Pulls of note
*
* Discussion
* Last call for [chair nominations](https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/kubernetes-sig-auth/_uzEMhWQDPM/7r8DsiQ2AQAJ) to fill Eric's spot
* If you are interested in this role (or would like to recommend someone), please send Tim and Jordan [an email](mailto:kubernetes-sig-auth-leads@googlegroups.com) at with references to existing contributions.
* Hope to recommend a candidate and solicit feedback from the SIG by June 15th
* Bound Service Account Tokens use case for dynamic webhook configuration (@mattmoyer/@pbarker)
* Possible to fetch/use audience-scoped tokens for use with webhooks?
* How we determine the audience is questionable
* Token could be fetched/requested, or injected
* Further discussion on dynamic audit configuration https://github.com/kubernetes/community/pull/2188 (@pbarker)
* Static, non-overrideable flag-based config (what we have today)
* Dynamic configs (namespaced and cluster-scoped? Harmonize with other policy approaches - [scheduling](https://www.google.com/url?q=https://github.com/kubernetes/community/pull/1937&sa=D&ust=1528917891000000&usg=AFQjCNFqLzgSYw0OSFTS4sqgKk4oRHePeQ), etc. More discussion in [wg-policy](https://docs.google.com/document/d/1ihFfEfgViKlUMbY2NKxaJzBkgHh-Phk5hqKTzK-NEEs/edit))
* Node agents want to add taints to themselves (@mikedanese)
* [jordan's preferred solutions](https://github.com/kubernetes/kubernetes/pull/63167#issuecomment-385473656)
* Opinion: "Conditions are unnecessary indirections; well known key prefix is hard since there will be vendor specific taints; updating node controller is hard but is probably equivalent to updating the admission controller"
* We need this for [k8s-node-termination-handler](https://github.com/GoogleCloudPlatform/k8s-node-termination-handler)
* How do we track subproject efforts? (@mikedanese)
* Project experiment: https://github.com/kubernetes/kubernetes/projects/13
* Umbrella issues (e.g. [#60392](https://github.com/kubernetes/kubernetes/issues/60392))
* Quick note: [deficiencies of CSI as it relates to pod identity](https://github.com/kubernetes/kubernetes/issues/64984)
* Next meeting: 1.12 plans
* Mike: make umbrella issue for tokenrequest work
* Jordan: make umbrella issue for node restriction work
* @x13n: make umbrella issue for audit work
* <add your planned work items/areas here for discussion>
## May 30, 2018, 11a - Noon (Pacific Time)
* [Recording](https://www.youtube.com/watch?v=FFaIUKBVgYw)
* Demos
* [kube-oidc](https://github.com/ericchiang/kube-oidc): OpenID Connect utilities for Kube [ericchiang]
* Pulls of note
* client-go: promote exec plugin support to beta ([#64482](https://github.com/kubernetes/kubernetes/pull/64482)) [ericchiang]
* dynamic audit configuration KEP ([#2188](https://github.com/kubernetes/community/pull/2188))
* NonRootGroup API Changes and Implementation ([#62216](https://github.com/kubernetes/kubernetes/pull/62216))
* For 1.11 [mikedanese]:
* Token Volume Source: https://github.com/kubernetes/kubernetes/pull/63819/
* Impl https://github.com/kubernetes/kubernetes/pull/62005
* TokenReview: https://github.com/kubernetes/kubernetes/pull/62802
* Discussion
* Review bottleneck - how can we add expand OWNERS and add more approvers in some critical areas
* https://github.com/kubernetes/kubernetes/blob/master/plugin/pkg/auth/OWNERS
* https://github.com/kubernetes/kubernetes/blob/master/pkg/auth/OWNERS
* https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/client-go/OWNERS
* https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/client-go/util/certificate/OWNERS
* https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/certificate/OWNERS
* 1.11 Release timeline:
* https://github.com/kubernetes/sig-release/blob/master/releases/release-1.11/release-1.11.md
## May 16, 2018, 11a - Noon (Pacific Time)
* [Recording](https://www.youtube.com/watch?v=qC3tM1XtV8U)
* Announcements
* [ericchiang] Call for secondary for SIG Auth representative in SIG PM
* https://github.com/kubernetes/community/issues/2122
* https://github.com/kubernetes/community/blob/master/sig-product-management/SIG%20PM%20representatives.md
* Pulls of note
* "Escalating" RBAC grants ([pull/56358](https://github.com/kubernetes/kubernetes/pull/56358))
* Discussion
* [Cluster managed ca-certs](https://github.com/kubernetes/kubernetes/issues/63726) [tallclair]
* [destijl] It's fairly easy to be in an insecure state by continuously upgrading your cluster. Whereas if you just created a new cluster the defaults are safer. There's some [back-compat cluster role bindings](https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/rbac/legacy-kubelet-user-disable/kubelet-binding.yaml#L1-L2) you need to delete, as well as ABAC disabling and other traps. How can we make this better? Should we just document the ones we know about? Only the most diligent will find and read those docs.
* [Exec auth plugin](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/auth/kubectl-exec-plugins.md) - Beta requirements (awly@)
* https://github.com/heptio/authenticator/blob/master/pkg/token/token.go
* https://github.com/kubernetes/cloud-provider-gcp/tree/master/cmd/gke-exec-auth-plugin
* https://github.com/kubernetes/kubernetes/issues/61796
* Eric to document concerns and share, make a collective decision about whether it's ready for Beta.
* Cluster managed pull secrets for infrastructure images [clayton]
* Image pull secrets for infrastructure images (pod, daemonsets) or multiple namespaces is annoying to deal with
* (a fair number of people use protected registries)
* Might make sense to have a kubelet credentialprovider for accessing a kube secret(s) for being a pull secret (kubelet --pull-secret=namespace/name)
* We already have other credential providers that deal with "infrastructure" and kubernetes is "infrastructure"
* David brought up that it should probably deal with node groups, which is a long standing problem with dynamic config for nodes (nodes that can label themselves can be anyone). If we had groups of nodes (machineset or other) then we could also have controllers that manage access / rbac group membership for nodes
## May 2, 2018, 11a - Noon (Pacific Time)
* Meeting cancelled
## April 18, 2018, 11a - Noon (Pacific Time)
* [Recording](https://www.youtube.com/watch?v=T4vUfCn_h3s)
* Announcements
* sig-auth status update @ contributor summit - [draft](https://docs.google.com/document/d/1w0DR0dMYRXQVz8unb93bN1Fs_PGLLpXtpm1FIeM0GMc/edit) [tallclair]
* Pulls of note
* No new significant pulls, previously mentioned work is still ongoing
* Designs of note
* [Security Profiles](https://docs.google.com/presentation/d/1PmRcgID9-TKX-0x3E3rkKNaijrXIe45KGTIKTLe5FC8/edit#slide=id.g36a26b6cbf_0_0) [yisui]
* Unified description of startup options (consumable by installers or manually)
* cluster-level policy (applied at setup or at profile change)
* namespace policy (continuously applied)
* Update on [ServiceAccountTokenVolumeProjection](https://github.com/kubernetes/community/pull/1973) [mikedanese]
* Presented to sig-storage
* Working through "public" configmap volume source ACL
* Discussion
* [Governance proposal](https://github.com/kubernetes/community/pull/2000)
* Lays out three leadership roles (chair, tech lead, subproject owner)
* Tech lead and subproject owner roles were made distinct to think through which responsibilities belonged where, even though initially, the same people might be filling both roles
* Defines sig-auth membership (contributors to a subproject or sig health area, docs, tests, etc), for purposes of voting if needed
* Minimal comments on doc, will send out call for lazy consensus to mailing list
* [Subprojects](https://docs.google.com/document/d/1RJvnSPOJ3JC61gerCpCpaCtzQjRcsZ2tXkcyokr6sLY/edit#heading=h.t1pscltwx2kr) (must be a member of the [sig-auth google group](https://groups.google.com/forum/#!forum/kubernetes-sig-auth) to view)
* Will convert to community PR and send out to mailing list for comments (and to ensure identified subproject owners agree they are responsible for those areas)
* [Guidelines for node-level plugin auth](https://github.com/kubernetes/kubernetes/issues/62747) [tallclair]
## April 4, 2018, 11a - Noon (Pacific Time)
* [Recording](https://www.youtube.com/watch?v=PI_Ue6WAJHo)
* Announcements
* Calendar invite updated
* Demo
* [citadel](https://github.com/enj/citadel) @enj @npmccallum: Turn an arbitrary command into a KMS GRPC server (~5 to 10 minutes)
* Feedback would be greatly appreciated
* Many systems you would want to integrate with don't use gRPC
* Citadel implements the gRPC service, then fetches the key encryption key from the external KMS
* TODO: measure performance
* Pulls of note
* [scheduling policy](https://github.com/kubernetes/community/pull/1937) (@tallclair)
* Questions about what policy should look like inside of Kubernetes
* How policies are composed, defaulting, binding, etc…
* Next policy we need to add as in tree policy
* Conversations in [policy-wg](https://github.com/kubernetes/community/tree/master/wg-policy)
* On a related note, [PodRestriction](https://github.com/kubernetes/community/pull/1950) won't go forward
* Removing node.ExternalID (@mikedanese)
* https://github.com/kubernetes/kubernetes/pull/60692
* https://github.com/kubernetes/kubernetes/pull/61877
* Removes the need for kubelets to self-delete their Node objects \o/
* Field is replaced with instanceID field
* Mutable, so kubelets never need delete/recreate to change
* Use as source-of-truth vs cloud-provider lookup optimization is being debated in other PRs
* Designs of note
* [Kubelet TLS bootstrap via TPM](https://docs.google.com/document/d/12UgErB_46iHBOi0YEKbaFbEXv9E5O6XWQihwPkwB_7s) (@awly)
* Data placed in CSR objects is not guaranteed to be confidential, need to be careful to ensure it is tightly bound to the specific CSR
* CSR attestation data doesn't have sensitive information. Even if CSR or final approved cert are leaked, they are useless without corresponding private key.
* Related to TLS client cert support for exec plugin: https://github.com/kubernetes/kubernetes/pull/61803
* How would we make this support non-exportable keys?
* Would adding non-exportable key support overload the exec plugin interface? What performance expectations do we have from TLS handshakes?
* [service account token volumes](https://github.com/kubernetes/community/pull/1973) (@mikedanese)
* Open question: how to get the CA cert to the volume?
* Possibly use kube-public namespace?
* Discussion
* [CRI streaming authentication](https://github.com/kubernetes/kubernetes/issues/36666#issuecomment-378440458)
* [Governance proposal](https://github.com/kubernetes/community/pull/2000)
* Based on the [short-form SIG governance template](https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance-template-short.md)
* Proposes leadership roles: chairs, technical leads, subproject owners
* Describes requirements for roles, ideals for how the project would run
* See also: [subproject list and status](https://docs.google.com/document/d/1RJvnSPOJ3JC61gerCpCpaCtzQjRcsZ2tXkcyokr6sLY/edit#heading=h.t1pscltwx2kr) (in progress)
* Will take feedback/comments in the PR or mailing list and discuss in the next sig-auth meeting
## March 21, 2018, 11a - Noon (Pacific Time)
* [Recording](https://www.youtube.com/watch?v=EooFi_nBA7c)
* Demo
* https://github.com/CaoShuFeng/k8s-audit-collector
* Some comments about use of service account
* Exporting SA token and using it for user-auth seems like an anti-pattern we should discourage. Where you can't distinguish code taking actions with a credential from users taking actions it complicates access control, auditing, and incident response when evaluating damage of a lost/stolen credential.
* Users should only assume service account identities during debugging. Can be achieved without service account credentials using ActAs delegation.
* Lack of guidance here?
* Action item: write this up!
* Designs of note
* [PodRestriction](https://github.com/kubernetes/community/pull/1950) (@tallclair)
* Whitelist and blacklist type of restrictions only.
* Scheduling piece of this yet to be decided.
* Enforced at namespace level.
* Feedback requested on [`BindingMode`](https://github.com/kubernetes/community/pull/1950/files#diff-4e2582430273ddd4c245083aff3b23e1R119) behaviour.
* Overlap with [policy wg](https://docs.google.com/document/d/1Ht8wpj4j9YfAA7aVv9Yn3Ci1T_MLMWt0DBr0QmxI2OM/edit#heading=h.6l8mozsiyzb1) and [opa](http://www.openpolicyagent.org/docs/kubernetes-admission-control.html)
* How does lack of defaulting working with pods that express no opinion?
* Handled through something like pod presets
* TODO: sig-scheduling and policy-wg
* [Update] [kubernetes/community#911](https://github.com/kubernetes/community/pull/911/) reduce scope of node on taints/labels (sig-node)
* Deferring work on moving reporting of node address
* Discussion
* [SIG contribx presentation](https://docs.google.com/document/d/1hESUJdDy6Q6eysNe_Wyjtq8vI5A3AnrfWCcJFP4yU6I/edit) (Paris Pittman)
* Feedback wanted
* Defining bot commands and labels
* How are you using them? Are you using them?
* Help wanted issue and beginner issues
* How do you find out about these changes?
* Contributor and developer guide
* Please review
* Suggestions for mentoring
* Formalizing feature tracking for 1.11 (@ericchiang)
* Many features were in an unclear state over 1.10
* Not just alpha/beta/stable, but what work there was to do, what work had been done
* Considering encouraging more umbrella bugs like [#60392](https://github.com/kubernetes/kubernetes/issues/60392)
* Subprojects
## ~~March 7, 2018, 11a - Noon (Pacific Time)~~
* NO SIG AUTH (busy with release)
* Announcements
* SIG-auth presenting at the Kubernetes community meeting
## February 21, 2018, 11a - Noon (Pacific Time)
* [Recording](https://www.youtube.com/watch?v=W82dsv9ITNs)
* Announcements
* 1.10 code freeze is 2/26
* Time to make progress on stalled PRs/designs if desired for 1.10
* Pulls of note
* [TokenRequest Authenticator (pull/59940)](https://github.com/kubernetes/kubernetes/pull/59940)
* Designs of note
* Needs Review
* Documenting the KMS encryption provider ([Issue](https://github.com/kubernetes/website/issues/7399), [PR](https://github.com/kubernetes/website/pull/7479)).
* 10 sig/auth PRs in the v1.10 milestone ([PRs](https://github.com/kubernetes/kubernetes/pulls?q=is%3Aopen+is%3Apr+milestone%3Av1.10+label%3Asig%2Fauth))
* Discussion
* [Container Isolation](https://docs.google.com/document/d/1QQ5u1RBDLXWvC8K3pscTtTRThsOeBSts_imYEoRyw8A/edit) (@tallclair)
* Great that this is separated from individual implementations
* Goal is to have some sort of way to expressing a workload running in a VM
* Questions about boundary being the container or the pod. Will be expressed as different APIs. (similar to [kubernetes#55435](https://github.com/kubernetes/kubernetes/issues/55435))
* [Kubernetes bug-bounty program](https://docs.google.com/document/d/1dvlQsOGODhY3blKpjTg6UXzRdPzv5y8V55RD_Pbo7ag/edit?ts=5a8ca2dd#heading=h.7t1efwpev42p) (Maya Kaczorowski)
* Warnings about spam
* Questions about cross-team coordination
* Need to give the other SIGs the heads up
* Don't do it before freeze
* Current triage
* Whoever responds first becomes the owner
* Explicit rotation
* Fix and release process
* Requires adjustments
* How do we handle scope?
* Conformance
* Questions around plugins
* Out of scope
* Outside of Kubernetes org
* What's in the Kubernetes incubator?
* Want to be programmatic about the scope
* We have descriptions about hardening, but not actual tests
* Start very narrow to start
* E.g. only in core, no plugins
* Note: someone to take over the threat model doc https://github.com/kubernetes/community/pull/504
* Action items:
* Funding
* Working with other SIGs
* Owners
## February 7, 2018, 11a - Noon (Pacific Time)
* [Recording](https://www.youtube.com/watch?v=kls1pbC71n8)
* Announcements
* 1.10 code freeze is 2/26
* Time to make progress on stalled PRs/designs if desired for 1.10
* Pulls of note
* Designs of note
* serviceaccount secrets
* Consumption of just-in-time service account tokens
* Plumbing other info for the in-cluster config (CA, etc) to the kubelet
* https://github.com/kubernetes/kubernetes/issues/48408
* https://docs.google.com/document/d/1Ki7K9rAC5XIAgyYJXUis1UpgwmtR \
q2Xz68mF3_LggEY/edit?ts=5a68cdbc
* Needs Review
* gRPC KMS extension point implementation ([#55684](https://github.com/kubernetes/kubernetes/pull/55684))
* Last call for comments this week
* External Google implementation in progress
* External Vault implementation in progress
* External client-go credential providers ([#59495](https://github.com/kubernetes/kubernetes/pull/59495))
* Last call for comments this week
* Coordinate with api-machinery / Chao as client-go owner
* Discussion
* sig lead change
* David Eads (@deads2k, Red Hat) stepping down as sig lead
* Tim Allclair (@tallclair, Google) nominated as replacement
* Long-term contributor to k8s auth/security
* Helped drive pod security policy and audit features
* Member of kubernetes product security team
* Brings container/node security expertise
* Unanimous support from other leads (Jordan Liggitt, Red Hat; Eric Chiang, CoreOS)
* Feedback on the change welcome (either public or private)
* Lead change to regain some company diversity was desired before starting to work through defining sig membership, subprojects, tech leads, etc, etc
* Discuss the [sig governance template PR](https://github.com/kubernetes/community/pull/1650) (not merged, but fairly complete) as it applies to sig-auth:
* Do we want to split out roles for sig-auth as proposed in the PR: project lead (needs a better name) that is organizational and helps set strategic direction and tech lead (heavy code, design architecture focus).
* How many of each role?
* Organizational diversity: after the acquisition of coreos all our current sig-auth leads work at the same company.
* Agreement that there is value in documenting functional areas sig-auth is involved in, and the people responsible for them
* Agreement that having people focused on strategic direction is valuable (complementing per-release work item planning)
## January 24, 2018, 11a - Noon (Pacific Time)
* [Recording](https://www.youtube.com/watch?v=hsSaYXBEKaI)
* Pulls of note
* RBAC and PSP in audit - [#58143](https://github.com/kubernetes/kubernetes/pull/58143)
* OIDC cleanup - [#58544](https://github.com/kubernetes/kubernetes/pull/58544)
* Designs of note
* Proposal: Validated Pod Annotations - [community#1604](https://github.com/kubernetes/community/pull/1604)
* Needs review:
* gRPC KMS versioning ([#55684](https://github.com/kubernetes/kubernetes/pull/55684))
* Introduce podsecuritypolicy.admission.k8s.io/v1beta1 [#54933](https://github.com/kubernetes/kubernetes/pull/54933)
* Discussion:
* Status on the client-go auth provider proposal. - [community#1503](https://github.com/kubernetes/community/pull/1503)
* Open questions:
* Format of client-go <-> plugin communications
* Call patterns (cache in memory, on 401 or expiry re-call)
* Should Audit Logging API go to v1 in 1.10? [@destijl, @crassirostris, @tallclair]
* Google: we think it should, we haven't seen problems in our usage that would require changes.
* Require passing scale tests for v1
* Issue: https://github.com/kubernetes/kubernetes/issues/53020
* Depends on: https://github.com/kubernetes/kubernetes/pull/56126
* Require specing out how the rest of the system contributes audit info
* Requirements & discussion on https://github.com/kubernetes/kubernetes/issues/58083
* [enj] Thoughts on a subject rules review API (in relation to the current self subject rules review API)
* Use case being "can x do all of [a, b, c]" or "is x an admin in namespace foo"
* Granted it would be nicer to just ask the server to do the coverage check as well
* Intent of SSRR API was advisory, not for externalizing policy rules for external authoritative evaluation
* Still building out authorizer support (webhook, node)
* Still need to reconcile with explicit deny support
* Existing PR to express explicit deny in SelfSubjectRulesReview [#53922](https://github.com/kubernetes/kubernetes/pull/53922)
* Status of TokenRequest proposal [kubernetes/community#1460](https://github.com/kubernetes/community/pull/1460)
* Expressing request for expiring vs non-expiring token
* Version of subresource (v1 vs v1alpha1)
* Reducing scope of node on node actions [community#911](https://github.com/kubernetes/community/pull/911)
* Current proposal to use initializers (fate of initializers unclear)
* Could have the approver (or signer) be cloud aware
* If signer can fill in SANs, then client doesn't need as much access to figure out its requested SANs.
## January 10, 2018, 11a - Noon (Pacific Time)
* [Recording](https://www.youtube.com/watch?v=WIVJmUoqCuA)
* Pulls of note
* TokenRequest API [kubernetes/kubernetes#58027](https://github.com/kubernetes/kubernetes/pull/58027)
* KMS provider https://github.com/kubernetes/kubernetes/pull/55684 (design from google doc https://github.com/kubernetes/community/pull/1581)
* Designs of note
* Proposal: external client-go auth providers - [community#1503](https://github.com/kubernetes/community/pull/1503)
* Needs review:
*
* Discussion:
* Kubelet TLS bootstrapping - GA in 1.10? - [features#43](https://github.com/kubernetes/features/issues/43#issuecomment-340082591) (@mattmoyer)
* Note(@ericchiang): some open questions here: [kubernetes#57164](https://github.com/kubernetes/kubernetes/issues/57164)
* Client bootstrapping
* Could interact with client-go auth provider, obtain bootstrap credential externally
* Client rotation
* Still have a lot of logic baked into the kubelet, makes it difficult to take advantage of platform-specific CSR-informing features
* Server bootstrapping
* Blocked on self-reported node address trustworthiness (API-enabling work in 1.10 - @liggitt)
* Requires refactor of kubelet startup flow and triggers of serving cert updates
* Question: externalize and make the kubelet pick up certs from disk?
* Idea for K8s vulnerability reward program [@destijl]
* Needs well-defined setup/config demonstrating current best practices
* Define boundaries well
* Initial spike of activity/responses needed
* Funnel into existing security process, use as impetus to make process and timeframes better defined
* Ongoing commitment for new releases, responding with fixes (cross-sig)
* Long-term, could inform other CNCF projects
* Cross-authorizer RBAC escalation check - [#56358](https://github.com/kubernetes/kubernetes/pull/56358) (@liggitt)
* Will rethink as specific escalate query rather than superuser subject access review (parallel to bind check)
* TokenRequest and key rotation [@mikedanese]
* Current tokens are non-expiring, but bound to service account and secret objects (by embedded uid claims)
* How to encourage applications to expect/support rotation
* Client-go/in-cluster-config libraries support rotation
* Option: separate signing keys for expiring/non-expiring
* Limits on token lifetime - min of:
* Requester expiration time (if specified)
* Admin-specified max time (if specified)
* Deletion of bound object (pod, secret, service account, etc)