WIP: First steps on authn #896
Conversation
|
How is this related to #851? |
| cluster.KubeAPIServer.OIDCClientID = fi.String("841205377713-dlmq2pe0n1ftkevna3r18livjljm5uct.apps.googleusercontent.com") | ||
| cluster.KubeAPIServer.OIDCUsernameClaim = fi.String("email") | ||
|
|
||
| cluster.KubeAPIServer.AuthorizationRBACSuperUser = fi.String("admin") |
There was a problem hiding this comment.
Should the super user be admin or kubecfg, since the cert kops generates and puts in your ~/.kube/config has kubecfg as the common name?
There was a problem hiding this comment.
rather than hardcoding a particular user name, if you include the system:masters group in the bootstrap superuser cert, it'll get superuser permission
|
|
||
| cluster.KubeAPIServer.RuntimeConfig["rbac.authorization.k8s.io/v1alpha1"] = "true" | ||
|
|
||
| cluster.KubeAPIServer.AuthorizationMode = fi.String("RBAC") |
There was a problem hiding this comment.
Not sure exactly where this code is exercised in the flow of kops edit cluster, but if this purely sets auth mode to RBAC, aren't system components going to have a hard time working while their service account tokens are rejected? Won't there be a chicken-egg problem where the operator can't apply the RBAC roles in your examples above to enable system accounts, since the system isn't functioning, since the system accounts haven't been authorized for things yet?
There was a problem hiding this comment.
I have the same question, since in my current setup I'm using both abac and rbac?
There was a problem hiding this comment.
there are two ways to be authorized to load any role:
- run against the unsecured localhost API server port. this skips all authentication and authorization for all API calls, including loading/modifying RBAC policy
- be in the
system:mastersgroup, which inherently has full RBAC permissions. this is the group used by the components in the API server that talk back to the API, and is the easiest way for a bootstrap superuser to get full permissions.
with respect to system components, for 1.6, we're working on a set of default roles and rolebindings that get loaded for the in-tree components (kubelet, proxy, controller-manager and various controllers)
|
there are default roles defined in-tree (and loaded at first start) for standard components and for scoped user permissions... I'd recommend using those as much as possible |
| kind: ClusterRole | ||
| apiVersion: rbac.authorization.k8s.io/v1alpha1 | ||
| metadata: | ||
| name: kube-proxy |
There was a problem hiding this comment.
see the system:node-proxier role
| kind: ClusterRole | ||
| apiVersion: rbac.authorization.k8s.io/v1alpha1 | ||
| metadata: | ||
| name: kubelet |
| name: readonly | ||
| rules: | ||
| - apiGroups: ["*"] | ||
| resources: ["*"] |
There was a problem hiding this comment.
this gives read access to secrets, which makes the role escalating. I'd recommend the view role defined in-tree instead
| kind: ClusterRole | ||
| apiVersion: rbac.authorization.k8s.io/v1alpha1 | ||
| metadata: | ||
| name: services |
There was a problem hiding this comment.
these are superuser permissions... I wouldn't use them as an example of the permissions to grant all service accounts. https://github.com/kubernetes/kubernetes/blob/master/plugin/pkg/auth/authorizer/rbac/bootstrappolicy/testdata/controller-roles.yaml has roles defined for all the core controllers, and https://github.com/kubernetes/kubernetes/blob/master/plugin/pkg/auth/authorizer/rbac/bootstrappolicy/testdata/cluster-roles.yaml has roles for superuser (cluster-admin) and namespace-scoped users (admin, edit, and view) which would be good starting points for something you might grant a service account.
| kind: ClusterRole | ||
| apiVersion: rbac.authorization.k8s.io/v1alpha1 | ||
| metadata: | ||
| name: admin |
There was a problem hiding this comment.
the name admin is used upstream for a bootstrap role intended for namespace-scoped users. cluster-admin is the equivalent superuser role.
|
@justinsb can we get an update here? If not can we close this if it's out dated? |
|
Can we close? |
|
@justinsb PR needs rebase |
k8s-github-robot
added
the
needs-rebase
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: justinsb No associated issue. Update pull-request body to add a reference to an issue, or get approval with The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
k8s-github-robot
added
the
approved
k8s-github-robot
removed
the
approved
8 participants
This change is