-
Notifications
You must be signed in to change notification settings - Fork 39.8k
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
Conversation
ObjectMeta: metav1.ObjectMeta{Name: "system:kube-csr"}, | ||
Rules: []rbac.PolicyRule{ | ||
eventsRule(), | ||
rbac.NewRule("get", "create", "list", "watch").Groups(certificatesGroup).Resources("certificatesigningrequests").RuleOrDie(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
cluster/gce/config-default.sh
Outdated
@@ -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}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will revert.
@liggitt I suspect you're closer to this than I am. If you don't get to it, I'll look tomorrow AM. |
6aa76e1
to
d7fc8de
Compare
name: system:node-bootstrapper | ||
- apiVersion: rbac/v1beta1 | ||
kind: Group | ||
name: system:node |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
cluster/gce/gci/configure-helper.sh
Outdated
@@ -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" |
There was a problem hiding this comment.
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
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) |
cluster/gce/gci/configure-helper.sh
Outdated
@@ -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" |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
fca9ccc
to
1344778
Compare
subjects: | ||
- apiVersion: rbac/v1beta1 | ||
kind: Group | ||
name: system:node-bootstrapper |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gaah, thanks.
cluster/gce/configure-vm.sh
Outdated
@@ -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}") |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
b393102
to
f76630a
Compare
roleRef: | ||
apiGroup: rbac.authorization.k8s.io | ||
kind: ClusterRole | ||
name: beta:gce:kubelet-certificate-rotation |
There was a problem hiding this comment.
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?
f123d3c
to
97d7c37
Compare
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. |
@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? |
policy change LGTM |
/approve |
/lgtm |
[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 |
@k8s-bot pull-kubernetes-e2e-gce-etcd3 test this |
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
Automatic merge from submit-queue (batch tested with PRs 40760, 46706, 46783, 46742, 46751) |
@mikedanese: The following test failed, say
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. |
@jcbsmpsn @pipejakob
Fixes #31168