Make the service-catalog chart setup more secure with RBAC #981
Conversation
…age of API Aggregation. Create RBAC rules for the apiserver and controller-manager
k8s-ci-robot
added
the
cncf-cla: yes
|
So this is code that has been lying in my fork of service-catalog for use in https://github.com/luxas/kubeadm-workshop I now noticed @MHBauer's PR that is kind of similar: #936, but not everything necessarily have to be the same. We'll just see what happens I guess... |
| caBundle: {{ .Values.apiserver.tls.ca }} | ||
| priority: 100 | ||
| {{- end }} | ||
| # Extension API Servers should have a priority value higher than the core API groups that have 100 |
There was a problem hiding this comment.
The priority field actually split to groupPriorityMinimum and versionPriority in v1beta1. See kubernetes/kubernetes#46800
The ordering was also made more comprehensible (bigger numbers have higher priority). I'd recommend something like:
groupPriorityMinimum: 1000
versionPriority: 5
There was a problem hiding this comment.
Thanks, I hadn't seen that it was updated between alpha and beta
| | `apiserver.tls.cert` | Base64-encoded x509 certificate | A self-signed certificate | | ||
| | `apiserver.tls.key` | Base64-encoded private key | The private key for the certificate above | | ||
| | `apiserver.tls.ca` | Base64-encoded CA certificate used to sign the above certificate | | | ||
| | `apiserver.tls.requestHeaderCA` | Base64-encoded CA used to validate request-header authentication, when receiving delegated authentication from an aggregator | *none (will disable requestheader authentication)* | | ||
| | `apiserver.service.type` | Type of service; valid values are `LoadBalancer` and `NodePort` | `NodePort` | | ||
| | `apiserver.service.type` | Type of service; valid values are `ClusterIP` (the most secure), `LoadBalancer` and `NodePort` | `ClusterIP` | |
There was a problem hiding this comment.
I think this change makes sense if we are going to enable this by default, as we won't have any other use for an external access of the apiserver.
There was a problem hiding this comment.
Yes, NodePort shouldn't be the default in an AA world
| @@ -1,3 +1,63 @@ | |||
| kind: ServiceAccount | |||
There was a problem hiding this comment.
It probably does make more sense to shove the rbac stuff into the deployments that need it set up.
Is there any guidance on the difference or preference for multi-yaml split by --- or using a List object?
There was a problem hiding this comment.
I prefer --- personally at least
I can definitely help out on that PR. As said, I wrote this code quite long ago, but first now realized I should upload a PR of it and didn't see yours. |
arschles
added
the
needs-rebase
|
This will need a rebase |
|
@luxas bump |
|
@kibbles-n-bytes ah, forgot about this one. I'll check what's left to do here, update and let you know. |
|
Closing - I believe this is obsolete. |
Take advantage of API Aggregation
Creates the necessary RBAC rules for the apiserver and controller-manager
cc @pmorie @liggitt