Authentication And Authorization For Managed Kubernetes
Platform9 leverages Keystone, an open source component part of the OpenStack project designed to support API client authentication, service discovery, and distributed multi-tenant authorization. Each Managed Kubernetes deployment comes with a dedicated instance of Keystone. Managed Kubernetes Cluster API servers are configured to delegate every authentication and authorization request to Keystone. You can learn more about OpenStack Keystone here.
- Any Keystone user with the admin role in the Keystone tenant foo is authorized to make an namespaced resource request (e.g. create a Deployment) in the Kubernetes namespace foo. This means that user has access to namespace foo within any cluster.
- Additionally, any Keystone user with the admin role in the Keystone tenant service is authorized to make an namespaced resource request (e.g. create a Deployment) in all Kubernetes namespaces.
To allow Keystone user bob to create, update, and delete resources only in the namespace dev in the clusters cluster1 and cluster2:
- In the UI, create the tenant dev. Select cluster1 and cluster2 from the list of clusters. A dev namespace will be created in each cluster automatically.
- Give bob the admin role in the dev tenant.
To allow Keystone user alice access to all namespaces in all clusters:
- Give alice the admin role in the service tenant.
Authorization Policy Details
Kubernetes API requests fall into three categories: namespaced resources, non-namespaced resources, and non-resources. Below are the policies enforced for these categories:
Namespaced resources (e.g., pods, services)
All verbs for user with admin role in
Non-namespaced resources (e.g., nodes, persistentvolumes)
All verbs for user with admin role in service tenant. Read-only verbs for user with admin role in any other tenant.
Non-resources (e.g., /version, /swaggerapi/*)
Non-resources required for all users to use kubectl or other API clients. All verbs for user with admin role in service tenant.