Granting Access to Kubernetes and Konvoy Resources

Granting Access to External Users

Users and groups from an external identity provider initially have no access to kubernetes resources. Privileges must be granted explicitly by interacting with the RBAC API. This section provides some basic examples for general usage. More information about the RBAC API can be found in the Kubernetes documentation.

The Basics

Kubernetes does not provide an identity database for standard users. Users and group membership must be provided by a trusted identity provider. In Kubernetes, RBAC policies are additive. This means that a subject (user, group, or service account) is denied access to a resource unless explicitly granted access by a cluster administrator. Access is granted by binding a subject to a role which grants some level of access to one or more resources. Kubernetes ships with some default roles which aid in creating broad access control policies.

As an example, if we wanted to make mary@example.com a cluster administrator, we would bind her username to the cluster-admin default role:

cat << EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: mary-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: mary@example.com
EOF

This user now has the highest level of access which can be achieved. Use the cluster-admin role and system:masters group sparingly.

Restricting a User to Namespace

A more common example would be to grant a user access to a specific namespace. This is done by creating a RoleBinding (RoleBindings are namespaced scoped). For example, to make the user bob@example.com a reader of the baz namespace, bind the user to the view role:

cat << EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: bob-view
  namespace: baz
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: bob@example.com
EOF

The user can now perform non-destructive operations targeting resources in the baz namespace only.

Groups

If your external identity provider supports group claims, you can also bind groups to roles. To make the devops LDAP group administrators of the production namespace bind the group to the admin role:

cat << EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: devops-admin
  namespace: production
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: oidc:devops
EOF

One important distinction from adding users is that all external groups are prefixed with oidc:. Therefore, our group name becomes oidc:devops. This is needed to prevent collision with locally defined groups.

Portal Authorization

The Operations Portal, and other HTTP applications protected by Konvoy forward authentication, are also authorized by the Kubernetes RBAC API. In addition to kubernetes API resources, it is possible to define rules which map to HTTP URIs and HTTP verbs. Kubernetes RBAC calls these nonResourceURLs, Konvoy forward authentication uses these rules to grant or deny access to HTTP endpoints.

Default Roles

Roles have been created for granting access to the operations portal and select addons which expose an HTTP server through the ingress controller. The cluster-admin role is actually a system role that defines grants permission to all actions (verbs) on any resource; including non-resource URLs. The default operations portal user is bound to this role.

NOTE: Granting user admin privileges on /ops/portal/* grants admin privileges to all sub-resources, even if bindings exist for sub-resources with less privileges

This section provides a few examples of binding subjects to the default roles defined for the operations portal endpoints.

Examples

To grant the user mary@example.com administrative access to all operations portal resources, bind the user to the opsportal-admin role:

cat << EOF | kubectl apply -f -
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: opsportal-admin-mary
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: opsportal-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: mary@example.com
EOF

If we inspect the role, we can see what access has been granted:

kubectl describe clusterroles opsportal-admin
describe clusterroles opsportal-admin

Name:         opsportal-admin
Labels:       app.kubernetes.io/instance=opsportal-kubeaddons
              app.kubernetes.io/managed-by=Tiller
              app.kubernetes.io/version=1.0.0
Annotations:  <none>
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
             [/ops/portal/*]    []              [delete]
             [/ops/portal]      []              [delete]
             [/ops/portal/*]    []              [get]
             [/ops/portal]      []              [get]
             [/ops/portal/*]    []              [head]
             [/ops/portal]      []              [head]
             [/ops/portal/*]    []              [post]
             [/ops/portal]      []              [post]
             [/ops/portal/*]    []              [put]
             [/ops/portal]      []              [put]

The user can now use the HTTP verbs HEAD, GET, DELETE, POST, and PUT when accessing any URL at or under /ops/portal. Provided the downstream application follows REST conventions, this effectively allows read, edit, and delete privileges.

NOTE: In order to allow users to access the Kommander UI, ensure they are granted the appropriate opsportal-kommander- role in addition to the Kommander roles granted in the Kommander UI. In future versions of Kommander, this capability may be added to all built in Kommander roles. For more information, see the Access Control section of the Kommander documentation.

Groups

In order to grant view access to the /ops/portal/* endpoints and edit access to the kibana endpoint to group kibana-ops, create the following ClusterRoleBindings:

cat << EOF | kubectl apply -f -
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: opsportal-view-kibana-ops
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: opsportal-view
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: oidc:kibana-ops
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: opsportal-kibana-edit-kibana-ops
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: opsportal-kibana-edit
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: oidc:kibana-ops
EOF

Note: external groups must be prefixed by oidc:

Members of kibana-ops are now able to view all resources under /ops/portal and edit all resources under /ops/portal/kibana

Accessing the Kubernetes Dashboard

The Kubernetes dashboard offloads authorization directly to the Kubernetes API server. Once authenticated, all users may access the dashboard at /ops/portal/kubernetes without needing an opsportal role. However, access to the underlying kubernetes resources exposed by the dashboard are protected by the cluster RBAC policy.

Further Reading

This page has provides some basic examples of operations which provide the building blocks of creating an access control policy. For information about creating your own roles and more advanced policies, we highly recommend reading the Kubernetes RBAC documentation.