Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

enable kubelet csr bootstrap in GCE/GKE #40760

Merged
merged 2 commits into from
Jun 4, 2017

Conversation

mikedanese
Copy link
Member

@mikedanese mikedanese commented Jan 31, 2017

@jcbsmpsn @pipejakob

Fixes #31168

Enable kubelet csr bootstrap in GCE/GKE

@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Jan 31, 2017
@k8s-github-robot k8s-github-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. release-note-label-needed labels Jan 31, 2017
@mikedanese mikedanese added release-note-none Denotes a PR that doesn't merit a release note. and removed release-note-label-needed labels Jan 31, 2017
@mikedanese mikedanese changed the title enable kubelet csr bootstrap in GCE. enable kubelet csr bootstrap in GCE GCI. Jan 31, 2017
@k8s-reviewable
Copy link

This change is Reviewable

ObjectMeta: metav1.ObjectMeta{Name: "system:kube-csr"},
Rules: []rbac.PolicyRule{
eventsRule(),
rbac.NewRule("get", "create", "list", "watch").Groups(certificatesGroup).Resources("certificatesigningrequests").RuleOrDie(),
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what do about the RBAC permissions for creating and reading CSRs. Is it ok to create a system role for this? @liggitt @cjcullen

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could alternatively give this permission to user.AllAuthenticated instead of creating a new group.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there's already a role: system:node-bootstrapper (added in https://github.com/kubernetes/kubernetes/pull/40034/files)

it is not bound to any users by default.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd expect the thing starting the cluster and setting up the bootstrap credential to grant this role to that user or group

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

node-bootstrapper is a pretty bad name for a permission that I hope will be used more broadley than node-bootstrapping. Can we change it to something like csrequestor and bind it to all authenticated users or a csrquestor group?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

node-bootstrapper is a pretty bad name for a permission that I hope will be used more broadley than node-bootstrapping.

I anticipate that there might be additional permissions in the future we'd want to add to the node bootstrapper role (like being able to get a node to see if there is already a record for itself, etc), so I'd rather give the bootstrapper role to the bootstrap credential for now.

Can we change it to something like csrequestor

If we want an additional separate role that is limited in purpose to requesting a certificate, that could make sense as well

bind it to all authenticated users or a csrquestor group?

I wouldn't expose cert requests to all authenticated users or a fixed group yet...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I see that node-bootstrapper also has node get permissions...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will use node-bootstrapper role for now then.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the longer term we want this thing to not be able to get nodes, right?

@@ -38,7 +38,7 @@ KUBE_DELETE_NODES=${KUBE_DELETE_NODES:-true}
KUBE_DELETE_NETWORK=${KUBE_DELETE_NETWORK:-false}

MASTER_OS_DISTRIBUTION=${KUBE_MASTER_OS_DISTRIBUTION:-${KUBE_OS_DISTRIBUTION:-gci}}
NODE_OS_DISTRIBUTION=${KUBE_NODE_OS_DISTRIBUTION:-${KUBE_OS_DISTRIBUTION:-debian}}
NODE_OS_DISTRIBUTION=${KUBE_NODE_OS_DISTRIBUTION:-${KUBE_OS_DISTRIBUTION:-gci}}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will revert.

@deads2k
Copy link
Contributor

deads2k commented Jan 31, 2017

@liggitt I suspect you're closer to this than I am. If you don't get to it, I'll look tomorrow AM.

@k8s-github-robot k8s-github-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 1, 2017
@k8s-github-robot k8s-github-robot removed the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 1, 2017
name: system:node-bootstrapper
- apiVersion: rbac/v1beta1
kind: Group
name: system:node
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was this supposed to be system:nodes? Once a node has a credential in this group, isn't it done bootstrapping?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jcbsmpsn is working on implementing rotation that will use the kubelet's certificate as credentials. I can omit this until it is impelmented.

Copy link
Member

@liggitt liggitt Feb 2, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we expect nodes to request certs as themselves (for rotation, or for requesting serving certs), let's add the csr permissions to the system:node role as well

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok.

subjects:
- apiVersion: rbac/v1beta1
kind: Group
name: system:node-bootstrapper
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What creates this group? Under what circumstances are the RBAC addons created?

Copy link
Member Author

@mikedanese mikedanese Feb 2, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@liggitt the addon manager creates this and it will be enabled in GCE kube-up.sh deployments only. It will be a enabled in all GCE clusters

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds reasonable for GCE, but I would avoid the system: prefix on the bootstrap user/group name if it's not something we intend to standardize

@@ -1099,9 +1130,13 @@ function start-kube-addons {
local -r src_dir="${KUBE_HOME}/kube-manifests/kubernetes/gci-trusty"
local -r dst_dir="/etc/kubernetes/addons"

# TODO(mikedanese): only enable these in e2e
# prep the additional bindings that are particular to e2e users and groups
setup-addon-manifests "addons" "e2e-rbac-bindings"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's possible some of these are no longer needed, actually

@liggitt
Copy link
Member

liggitt commented Feb 2, 2017

@cjcullen: In the longer term we want this thing to not be able to get nodes, right?

I think so, yes. Originally it was just CSR permissions. kubeadm does an early get of the anticipated node during bootstrap, but on reflection I think that is incorrect. @luxas, I'll open a PR to remove that usage and tighten this role back to CSR only.

I do anticipate using the authorizer to replace the hard coded autoapprove group (do an authorization check on the subject that requested a node client cert to see if they are allowed to join nodes)

@@ -239,6 +240,10 @@ function create-master-auth {
if [[ -n "${KUBE_PROXY_TOKEN:-}" ]]; then
replace_prefixed_line "${known_tokens_csv}" "${KUBE_PROXY_TOKEN}," "system:kube-proxy,uid:kube_proxy"
fi
if [[ -n "${KUBE_CSR_TOKEN:-}" ]]; then
replace_prefixed_line "${known_tokens_csv}" "${KUBE_CSR_TOKEN}," "system:node-bootstrap-secret,uid:node-bootstrap-secret,system:node-bootstrapper"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if this isn't a username or group we intend to standardize (and I don't think it is), then omit the system: prefix... it's GCE-specific, like the admin username above.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

subjects:
- apiVersion: rbac/v1beta1
kind: Group
name: system:node-bootstrapper
Copy link
Member

@liggitt liggitt Feb 2, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

heh, other way around. role is standard (system:...), particular group used by kube-up.sh is not.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gaah, thanks.

@@ -698,7 +698,8 @@ function create-salt-master-auth() {
(umask 077;
echo "${KUBE_BEARER_TOKEN},admin,admin" > "${KNOWN_TOKENS_FILE}";
echo "${KUBELET_TOKEN},kubelet,kubelet" >> "${KNOWN_TOKENS_FILE}";
echo "${KUBE_PROXY_TOKEN},kube_proxy,kube_proxy" >> "${KNOWN_TOKENS_FILE}")
echo "${KUBE_PROXY_TOKEN},kube_proxy,kube_proxy" >> "${KNOWN_TOKENS_FILE}";
echo "${KUBE_CSR_TOKEN},kube-csr,kube-csr" >> "${KNOWN_TOKENS_FILE}")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this will make the username kube-csr... is that right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope. This change is not necessary, removed.

@k8s-github-robot k8s-github-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 2, 2017
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: beta:gce:kubelet-certificate-rotation
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this role isn't defined, right?

@liggitt
Copy link
Member

liggitt commented May 31, 2017

this LGTM, just the one question about managed files in salt, and the note that letting nodes renew their own credentials automatically makes revoking a node's credentials a race (though without CRL support, revoking cert credentials is largely theoretical at the moment). I'm ok iterating on this.

@mikedanese mikedanese changed the title enable kubelet csr bootstrap in GCE GCI. enable kubelet csr bootstrap in GCE/GKE May 31, 2017
@k8s-github-robot k8s-github-robot removed the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 1, 2017
@mikedanese
Copy link
Member Author

mikedanese commented Jun 1, 2017

@liggitt can you review and approve the change to bootstrap controller policy I needed to add to allow the SAR approver to create subject access reviews?

@liggitt
Copy link
Member

liggitt commented Jun 1, 2017

policy change LGTM

@liggitt
Copy link
Member

liggitt commented Jun 1, 2017

/approve

@cjcullen
Copy link
Member

cjcullen commented Jun 1, 2017

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jun 1, 2017
@k8s-github-robot k8s-github-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 1, 2017
@k8s-github-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cjcullen, falenn, liggitt, mikedanese

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

Needs approval from an approver in each of these OWNERS Files:

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

@mikedanese mikedanese added release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed release-note-none Denotes a PR that doesn't merit a release note. labels Jun 3, 2017
@mikedanese
Copy link
Member Author

@k8s-bot pull-kubernetes-e2e-gce-etcd3 test this

@k8s-github-robot
Copy link

@k8s-bot test this [submit-queue is verifying that this PR is safe to merge]

@liggitt
Copy link
Member

liggitt commented Jun 4, 2017

@k8s-bot pull-kubernetes-federation-e2e-gce test this
@k8s-bot pull-kubernetes-kubemark-e2e-gce test this

@k8s-github-robot
Copy link

Automatic merge from submit-queue (batch tested with PRs 40760, 46706, 46783, 46742, 46751)

@k8s-github-robot k8s-github-robot merged commit 4c7e159 into kubernetes:master Jun 4, 2017
@k8s-ci-robot
Copy link
Contributor

@mikedanese: The following test failed, say /retest to rerun them all:

Test name Commit Details Rerun command
pull-kubernetes-federation-e2e-gce f533bf7 link @k8s-bot pull-kubernetes-federation-e2e-gce test this

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

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. I understand the commands that are listed here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/auth Categorizes an issue or PR as relevant to SIG Auth. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants