harden the default RBAC discovery clusterrolebindings

[dekkagaijin]

Implements kubernetes/enhancements#789

/kind feature

Default RBAC policy no longer grants access to discovery and permission-checking APIs (used by `kubectl auth can-i`) to *unauthenticated* users. Upgraded clusters preserve prior behavior, but cluster administrators wishing to grant unauthenticated users access in new clusters will need to explicitly opt-in to expose the discovery and/or permission-checking APIs:
* `kubectl create clusterrolebinding anonymous-discovery --clusterrole=system:discovery --group=system:unauthenticated`
* `kubectl create clusterrolebinding anonymous-access-review --clusterrole=system:basic-user --group=system:unauthenticated`

[k8s-ci-robot]

Hi @dekkagaijin. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[dekkagaijin]

/assign @liggitt

[liggitt]

/ok-to-test

[dekkagaijin]

@liggitt OK to review what I have now, don't really know the most sane way to test the storage_rbac change. I'll flesh out the release note to include the possible pitfalls and the sample kubectl escape hatches

[liggitt]

instead of hard-coding role names here, get a set of map[string]ClusterRoleBinding (source name -> destination clusterrolebinding template) from the bootstrap policy data (e.g. SplitClusterRoleBindings()), then iterate over them in primeSplitClusterRoleBindings

inside that method, make a DeepCopy() of the destination clusterrolebinding template and actually copy over the labels/annotations/subjects from the source clusterrolebinding if present

[liggitt]

still outstanding

[dekkagaijin]

done

[liggitt]

don't really know the most sane way to test the storage_rbac change

@jennybuckley has a great example of an integration test that:

1. starts a shared etcd
2. starts an apiserver and lets it come up
3. monkeys with stuff
4. shuts down the apiserver and starts a new one against the same etcd data
5. verifies stuff

that sounds like exactly what you want

[dekkagaijin]

@liggitt thanks, I'll finish this up tomorrow (crosses fingers) after perf/promo is done

[liggitt]

a couple comments on the test, and one outstanding comment on where the old binding -> new binding data should live. lgtm otherwise

[dekkagaijin]

done, PTAL @liggitt

[dekkagaijin]

/test pull-kubernetes-verify

[liggitt]

an attempt was made to switch to go1.12 last night... govet failure is spurious, retest should resolve it

[dekkagaijin]

@liggitt that was the trick, PTAL :)

[liggitt]

the return nil lines inside the loop should be continue statements

[dekkagaijin]

good catch

[liggitt]

/lgtm
/approve
/milestone v1.14

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dekkagaijin, liggitt

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• pkg/registry/rbac/OWNERS [liggitt]
• plugin/pkg/auth/authorizer/OWNERS [liggitt]
• test/OWNERS [liggitt]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[redbaron]

Release notes say "Upgraded clusters preserve prior behavior", how can administrators of upgraded clusters move to hardened RBAC?

[dekkagaijin]

@redbaron (nice username btw) one only need remove the system:authenticated Subject group form the system:discovery and system:basic-user ClusterRoleBindings.

I don't think that there's a universal, one- or two-line command to trim the old Bindings since kubectl patch isn't overly smart about array elements, but if a general description of the change is fine then I can add the previous sentence to the release notes.

[liggitt]

I don't think that there's a universal, one- or two-line command to trim the old Bindings since kubectl patch isn't overly smart about array elements

kubectl auth reconcile --remove-extra-subjects -f ... was made for this, but needs an input file containing only the trimmed clusterrolebindings

[dekkagaijin]

@redbaron Here's something I came up with to harden upgraded clusters to the new RBAC discovery roles:

cat <<EOF | kubectl auth reconcile --remove-extra-subjects -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: system:basic-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:basic-user
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: system:discovery
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:discovery
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated
EOF