kubernetes/kops: Default user and permissions

Question

using kubectl and kops 1.8

When spinning of a cluster in aws using kops the client certificate (present as string in the client-certificate-data field of ~/.kube/config) created has the following values:

    Subject: O=system:masters, CN=kubecfg

Unless I am wrong, starting from kubernetes 1.4, the value for Organitazion is interpeted as group information (string associated with CN value is the so-called user, since k8s does not inherently have such a concept)

1: How can I see what permissions are associated with the system:masters group and/or the kubecfg user?

• (related to the above): what is the out-of-the-box authorization method I am using now? RBAC? How can I check this?

2: Why the entries in my ~/.kube/config do not incorporate a kubecfg user? (but rather a user bearing my cluster name and another user named admin?)

$ kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: <server_url>
  name:  <my_cluster_name>
contexts:
- context:
    cluster:  <my_cluster_name>
    user:  <my_cluster_name>
  name:  <my_cluster_name>
current-context:  <my_cluster_name>
kind: Config
preferences: {}
users:
- name: <my_cluster_name>
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
    password: <some_pass>
    username: admin
- name: <my_cluster_name>.local-basic-auth
  user:
    password: <some_pass>
    username: admin

At the end of the day, what user I am performing api calls with, when executing kubectl commands?

update: I tried to mess up the value of client-certificate-data in my ~/.kube/config and I got

error: tls: private key does not match public key

I am assuming this means I am using a x509 based auth (?)

So I am making api calls as kubecfg ?

Answer 1

Note that there is a difference between authentication and authorization.

• Authentication ensures that a user is who they say they are. Calls to the Kubernetes API always requires successful authentication.
• Authorization determines whether a user has access to specific Kubernetes API resources (via RBAC). RBAC must be explicitly enabled as a configuration option to the kube-apiserver server.

Kubernetes Authentication

• In Kubernetes, there are many mechanisms which may be used to to authenticate a user such as tokens, passwords, OIDC connect tokens, and SSL x509 client certs.

• As you have discovered above, kops will auto-generate a ~/.kube/config file with an embedded SSL x509 client certificate. Presenting the client certificate along with any REST call to the kube-apiserver allows the kube-apiserver to authenticate the caller by validating that the client certificate has been signed by the cluster Certificate Authority (CA). If the client cert has been properly signed, then the caller is who they say they are.

• The identity of the holder of the client certificate is determined by the Subject field of the SSL x509 client certificate.

  • Subject Common Name determines the user identity. (e.g. CN=Bob)
  • Subject Organization determines the user's groups. (e.g. O=admins, O=system:masters). Note that multiple organizations (i.e. groups) may be specified.
• Please note that user name in the kubeconfig file is just an opaque value user for the convenience of the kubectl tool. The real identity of the user is that which has been embedded in the SSL x509 client certificate or any other token.
• Be aware that each instance of every component (e.g. kubelet, scheduler, etcd) in a typical Kubernetes deployment has its own SSL x509 client certificate, which it uses to authenticate when communicating with other components. See this link

Kubernetes Authorization

• In Kubernetes, RBAC roles and rolebindings determine exactly what kube-apiserver REST endpoints a particular user may access, and what verb operations are allowed (e.g. "get", "list", "watch", "create", "update", "patch", "delete").
• One may create a role which is a set of permissions that define access to kube-apiserver REST endpoints.
• One may then create a rolebinding which binds a user id or a group id to a specific role.
• Please note there are both cluster-wide and namespace-wide rolebindings available.
• Here's an example:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: role-grantor
    rules:
    - apiGroups: ["rbac.authorization.k8s.io"]
      resources: ["rolebindings"]
      verbs: ["create"]
    - apiGroups: ["rbac.authorization.k8s.io"]
      resources: ["clusterroles"]
      verbs: ["bind"]
      resourceNames: ["admin","edit","view"]
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: role-grantor-binding
      namespace: user-1-namespace
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: role-grantor
    subjects:
    - apiGroup: rbac.authorization.k8s.io
      kind: User
      name: user-1

• RBAC is only one possible authorization mechanism. Kubernetes ABAC is less popular.

Checking if you have RBAC enabled

Simply verify the kube-apiserver startup options. If kube-apiserver is running as a pod, you can check it like this:

$ kubectl get po kube-apiserver-ubuntu-18 -n kube-system -o name |grep api
pod/kube-apiserver-ubuntu-18

$ kubectl get po kube-apiserver-ubuntu-18 -n kube-system  -o yaml
# THEN SEARCH FOR RBAC
spec:
  containers:
  - command:
    - kube-apiserver
    - --authorization-mode=Node,RBAC