kiosk 适用于 Kubernetes 的多租户扩展 - 安全集群共享和自助服务命名空间配置
This product is no longer actively maintained, but thank you for all those who have used it! We have archived the repo to provide clear guidance on current expectations.
Kubernetes is designed as a single-tenant platform, which makes it hard for cluster admins to host multiple tenants in a single Kubernetes cluster. However, sharing a cluster has many advantages, e.g. more efficient resource utilization, less admin/configuration effort or easier sharing of cluster-internal resources among different tenants.
While there are hundreds of ways of setting up multi-tenant Kubernetes clusters and many Kubernetes distributions provide their own tenancy logic, there is no lightweight, pluggable and customizable solution that allows admins to easily add multi-tenancy capabilities to any standard Kubernetes cluster.
kiosk adds two groups of resources to extend the Standard API Groups of Kubernetes:
Custom Resources: config.kiosk.sh
Custom Resource Definitions (CRDs) for configuring kiosk. These resources are persisted in etcd just like any other Kubernetes resources and are managed by an operator which runs inside the cluster.
Show List of Custom Resources
API Extension: tenancy.kiosk.sh
Virtual resources which are accessible via an API Server Extension and will not be persisted in etcd. These resources are similar to views in a relational database. The benefit of providing these resources instead of only using CRDs is that we can calculate access permissions dynamically for every request. That means that it does not only allow to list, edit and manage Spaces (which map 1-to-1 to Namespaces), it also allows to show a different set of Spaces for different Account Users depending on the Accounts they are associated with or in other words: this circumvents the current limitation of Kubernetes to show filtered lists of cluster-scoped resources based on access rights.
Show List of API Extension Resources
kubectl: Follow this guide to install it.helm version 3: Follow this guide to install it.kiosk supports Kubernetes version: v1.14 and higher. Use kubectl version to determine the Server Version of your cluster. While this getting started guide should work with most Kubernetes clusters out-of-the-box, there are certain things to consider for the following types of clusters:
Docker Desktop Kubernetes
All ServiceAccounts have cluster-admin role by default, which means that emulating users with ServiceAccounts is not a good idea. Use impersonation instead.
Digital Ocean Kubernetes (DOKS)
All users in DOKS have cluster-admin role by default which means that when using impersonation, every user will have admin access. To see kiosk-based multi-tenancy in action, create ServiceAccounts to emulate different users.
Google Kubernetes Engine (GKE)
Your kube-context will by default not have cluster-admin role. Run the following command to get your google email address and to make your user cluster admin:
# GKE: make yourself admin
GKE_USER=$(gcloud config get-value account)
kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user $GKE_USER
You need a kube-context with admin rights.
If running all the following commands returns yes, you are most likely admin:
kubectl auth can-i "*" "*" --all-namespaces
kubectl auth can-i "*" namespace
kubectl auth can-i "*" clusterrole
kubectl auth can-i "*" crd
# Install kiosk with helm v3
kubectl create namespace kiosk
helm install kiosk --repo https://charts.devspace.sh/ kiosk --namespace kiosk --atomic
To verify the installation make sure the kiosk pod is running:
$ kubectl get pod -n kiosk
NAME READY STATUS RESTARTS AGE
kiosk-58887d6cf6-nm4qc 2/2 Running 0 1h
In the following steps, we will use Kubernetes user impersonation to allow you to quickly switch between cluster admin and simple account user roles. If you are cluster admin and you want to run a kubectl command as a different user, you can impersonate this user by adding the kubectl flags --as=[USER] and/or --as-group=[GROUP].
In this getting started guide, we assume two user roles:
kubectl commands without --as flag)john: use your admin-context to impersonate a user (kubectl commands with --as=john)If you are using Digital Ocean Kubernetes (DOKS), follow this guide to simulate a user using a Service Account.
To allow a user to create and manage namespaces, they need a kiosk account. Run the following command to create such an account for our example user john:
# Run this as cluster admin:
kubectl apply -f https://raw.githubusercontent.com/kiosk-sh/kiosk/master/examples/account.yaml
# Alternative: ServiceAccount as Account User (see explanation for account-sa.yaml below)
# kubectl apply -f https://raw.githubusercontent.com/kiosk-sh/kiosk/master/examples/account-sa.yaml
View: account.yaml
apiVersion: tenancy.kiosk.sh/v1alpha1
kind: Account
metadata:
name: johns-account
spec:
subjects:
- kind: User
name: john
apiGroup: rbac.authorization.k8s.io
As you can see in this example, every account defines subjects which are able to use this account. In this example, there is only one subject which is a User with name john. However, Accounts can also have multiple subjects.
Subjects for kiosk Accounts are defined in the exact same way as subjects in RoleBindings. Subjects can be a combination of:
account-sa.yaml)View: account-sa.yaml (alternative for ServiceAccounts, e.g. Digital Ocean Kubernetes)
If you want to assign an Account to a ServiceAccount (e.g. when using Digital Ocean Kubernetes / DOKS), please use the following alternative:
# Run this as cluster admin:
kubectl apply -f https://raw.githubusercontent.com/kiosk-sh/kiosk/master/examples/account-sa.yaml
apiVersion: tenancy.kiosk.sh/v1alpha1
kind: Account
metadata:
name: johns-account
spec:
subjects:
- kind: ServiceAccount
name: john
namespace: kiosk
Learn more about User Management and Accounts in kiosk.
All Account Users are able to view their Account through their generated ClusterRole. Let's try this by impersonating john:
# View your own accounts as regular account user
kubectl get accounts --as=john
# View the details of one of your accounts as regular account user
kubectl get account johns-account -o yaml --as=john
Spaces are the virtual representation of namespaces. Each Space represents exactly one namespace. The reason why we use Spaces is that by introducing this virtual resource, we can allow users to only operate on a subset of namespaces they have access to and hide other namespaces they shouldn't see.
By default, Account Users cannot create Spaces themselves. They can only use the Spaces/Namespaces that belong to their Accounts. That means a cluster admin would need to create the Spaces for an Account and then the Account Users could work with these Spaces/Namespaces.
To allow all Account Users to create Spaces for their own Accounts, create the following RBAC ClusterRoleBinding:
# Run this as cluster admin:
kubectl apply -f https://raw.githubusercontent.com/kiosk-sh/kiosk/master/examples/rbac-creator.yaml
View: rbac-creator.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: kiosk-creator
subjects:
- kind: Group
name: system:authenticated
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: kiosk-edit
apiGroup: rbac.authorization.k8s.io
Of course, you can also adjust this ClusterRoleBinding in a way that only certain subjects/users can create Spaces for their Accounts. Just modify the
subjectssection.
After granting Account Users the right to create Spaces for their Accounts (see ClusterRoleBinding in 3.1.), all Account Users are able to create Spaces. Let's try this by impersonating john:
kubectl apply -f https://raw.githubusercontent.com/kiosk-sh/kiosk/master/examples/space.yaml --as=john
View: space.yaml
apiVersion: tenancy.kiosk.sh/v1alpha1
kind: Space
metadata:
name: johns-space
spec:
# spec.account can be omitted if the current user only belongs to a single account
account: johns-account
As you can see in this example, every Space belongs to exactly one Account which is referenced by
spec.account.
Let's take a look at the Spaces of the Accounts that User john owns by impersonating this user:
# List all Spaces as john:
kubectl get spaces --as=john
# Get the defails of one of john's Spaces:
kubectl get space johns-space -o yaml --as=john
Every Space is the virtual representation of a regular Kubernetes Namespace. That means we can use the associated Namespace of our Spaces just like any other Namespace.
Let's impersonate john again and create an nginx deployment inside johns-space:
kubectl apply -n johns-space --as=john -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/application/deployment.yaml
That's great, right? A user that did not have any access to the Kubernetes cluster, is now able to create Namespaces on-demand and gets restricted access to these Namespaces automatically.
暂无开放 Issues，或尚未同步最近议题。