Container Infrastructure Management Service for OpenStack
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

5.1 KiB

Currently, there are several ways to access the Kubernetes API, such as RBAC, ABAC, Webhook, etc. Though RBAC is the best way for most of the cases, Webhook provides a good approach for Kubernetes to query an outside REST service when determining user privileges. In other words, we can use a Webhook to integrate other IAM service into Kubernetes. In our case, under the OpenStack context, we're introducing the intergration with Keystone auth for Kubernetes.

Since Rocky release, we introduced a new label named keystone_auth_enabled, by default it's True, which means user can get this very nice feature out of box.

Create roles

As cloud provider, necessary Keystone roles for Kubernetes cluster operations need to be created for different users, e.g. k8s_admin, k8s_developer, k8s_viewer

  • k8s_admin role can create/update/delete Kubernetes cluster, can also associate roles to other normal users within the tenant
  • k8s_developer can create/update/delete/watch Kubernetes cluster resources
  • k8s_viewer can only have read access to Kubernetes cluster resources

NOTE: Those roles will be created automatically in devstack. Below is the samples commands about how to create them.

Those roles should be public and can be accessed by any project so that user can configure their cluster's role policies with those roles.

Setup configmap for authorization policies

Given the k8s Keystone auth has been enable by default, user can get the authentication support by default without doing anything. However, user can't do anything actually before setup a default authorization policies.

The authorization policy can be specified using an existing configmap name in the cluster, by doing this, the policy could be changed dynamically without the k8s-keystone-auth service restart.

Or the policy can be read from a default policy file. In devstack, the policy file will be created automatically.

Currently, k8s-keystone-auth service supports four types of policies:

  • user. The Keystone user ID or name.
  • roject. The Keystone project ID or name.
  • role. The user role defined in Keystone.
  • group. The group is not a Keystone concept actually, it’s supported for backward compatibility, you can use group as project ID.

For example, in the following configmap, we only allow the users in project demo with k8s-viewer role in OpenStack to query the pod information from all the namespaces. So we need to update the configmap k8s-keystone-auth-policy which has been created in kube-system namespace.

Please note that the default configmap name is k8s-keystone-auth-policy, user can change it, but they have to change the config of the k8s keystone auth service configuration as well and restart the service.

Now user need to get a token from Keystone to have a kubeconfig for kubectl, user can also get the config with Magnum python client.

Here is a sample of the kubeconfig:

Now after export the Keystone token to OS_TOKEN, user should be able to list pods with kubectl.