Limit access Dashboard actual articles of the kubernetes

Series catalog

In front of our example, ServiceAccount we create is bound and cluster-admin, the default user has the highest authority, the actual production environment, often require different pre-assigned different permissions for operation and maintenance personnel. And according to the actual situation You may be given permission to read-only developer. in this section we will describe how to create different user privileges.

Before we start, we first understand some basic concepts about kubernetes RABA's.

• Role

Role express permission is a set of rules, can only accumulate, Role can be defined in a namespace, it can only be used to grant permission for a single namespace of access to resources. For example, we create a default namespace on the role Pods have access to:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

• ClusterRole

ClusterRole have the same privileges Role roles control, the difference is ClusterRole is the cluster level, it can be used for:

• Cluster-level resource control (for example access node)

• Non-resource-based endpoints (for example, / healthz access)

• All namespace resource control (such as pods)

For example, we want to create an authorization for a particular namespace or all namespaces (depending on the binding mode) to access secrets cluster roles:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

• RoleBinding和ClusterRoleBinding

RoloBinding permission roles defined can be granted to users or groups of users, RoleBinding contains a set of permissions list (subjects), contains a list of permissions granted permission to be different forms of resource types (users, groups, service accounts), RoleBinding FOR A within a namespace authorization, and ClusterRoleBinding apply to cluster-wide authorization.

For example, we will default pod-reader role namespaces granted to the user jane, so the default permissions after the user namespace will have the pod-reader:

# This role binding allows "jane" to read pods in the "default" namespace.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

RoleBinding can also be referenced ClusterRole authorized namespace within the current user, user group or ServiceAccount, this operation allows cluster administrators to define some general ClusterRole throughout the cluster, and then use a different namespace RoleBinding to refer

For example, the following RoleBinding quoted a ClusterRole, this ClusterRole have access to the secrets of the entire cluster; but it only authorized users to access dave development space secrets (because RoleBinding defined namespace in development)

# This role binding allows "dave" to read secrets in the "development" namespace.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secrets
  namespace: development # This only grants permissions within the "development" namespace.
subjects:
- kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding may authorize the use of all namespaces resource permissions entire cluster; ClusterRoleBinding The following example shows all users within the group manager authorized access to secrets in all of the namespace

# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Restrict user rights dashboard

With the theoretical basis of the above, since we can create a new user, assign specific access rights for a user, such as we are to achieve the following functions:

• Add a new user tyler (tyler.yml)

• The user can only kube-system following namespaces pods deployments and manage

• First, let's create theServiceAccount

kubectl to create tyler -n-kube system

• Then we create a new role role-tyler (role-tyler.yml)

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: kube-system
  name: role-tyler
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
- apiGroups: ["extensions", "apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Note that the above rules rule: the management authority pods and deployments.

Then we create a role bindings, bind a user to a role-tyler tyler role, so users have the authority roles.

Execute command to create a file

$ kubect create -f tyler.yml
$ kubect create -f role-tyler.yml

The previous one we are using a command to create roles and the existing role binding, this method is simple and quick to do, but not as easy here as complicated choreography operation authority, not easy version management more complex choreography rights yml recommend created using declarative way.

Create a login using token

As we have said, a user's secret name for the 用户名-token-随机字符串format. We can use kubectl describe secret secret名称 -n=kube-systemway to view secret, and then copy the token to token dashboard landing page where you can landed.