adds patch privileges to RBAC rules #46
Conversation
| resources: | ||
| - nodes | ||
| verbs: | ||
| - patch |
There was a problem hiding this comment.
This does not seem to do the trick. The errors are the same. I found kubernetes/kops#3551 (comment) but I am not sure this goes into the right direction. @giantswarm/sre feedback please. <3
There was a problem hiding this comment.
I noticed that this does not work because the RBAC rules here define access to the host cluster. The access issues we have are with guest clusters. So what do we need to do within the guest clusters to fix the problem of not being able to patch the guest cluster nodes via node-operator?
There was a problem hiding this comment.
Yes, exactly we need permission in the guest cluster. The first question would be what kind of access we use for node operator? which certs are used?
There was a problem hiding this comment.
We use the certs issued for node-operator. See
cluster-operator. See https://github.com/giantswarm/cluster-operator/blob/4c171e4fdeb3636cfe80170d9ad032dd96fb52ca/pkg/v4/resource/certconfig/desired.go#L364-L396. To me it looks like there is not really anything we can do with the certs. I think the certs work and aren't the problem. The problem is some cluster role binding magic in the guest cluster, which is missing I guess. I wonder why though and how we want to address this.
There was a problem hiding this comment.
So the certs have organization on which then the RBAC rules are bind.
I checked random node-operator certs and it seems they have organization: null so I am wondering how this could work at all.
There was a problem hiding this comment.
I see. We only set the system:masters org for the API certs. See https://github.com/giantswarm/cluster-operator/blob/4c171e4fdeb3636cfe80170d9ad032dd96fb52ca/pkg/v4/resource/certconfig/desired.go#L185. Do you think we should go with this? The weird thing is that this grants like everything. Can we just scope this down a little bit? I think I can setup some tests to get this straight.
There was a problem hiding this comment.
So the CRD has no organization but generated cert has
O=node-operator
Yeah this is the default for all components.
There was a problem hiding this comment.
Cant find any binding to that organization in k8scloudconfig
There was a problem hiding this comment.
I reckon so. We just add the component name by default. Do you think the proper solution would be to add some role binding in k8scc for node-operator for the nodes scope?
There was a problem hiding this comment.
yes, if something needs to access the api of the guest cluster it needs to be allowed the actions it needs to do, e.g. node-operator needs to be able to use get, drain,... verbs on node resource, maybe even more.
|
This is not fixing the problem. |
Towards https://github.com/giantswarm/giantswarm/issues/3450#issuecomment-398461546.