Getting Started • Architecture • Contributing • Roadmap
- Accounts & Account Users to separate tenants in a shared Kubernetes cluster
- Self-Service Namespace Provisioning for account users
- Account Limits to ensure quality of service and fairness when sharing a cluster
- Namespace Templates for secure tenant isolation and self-service namespace initialization
- Multi-Cluster Tenant Management for sharing a pool of clusters (soon)
#TODO: insert gif
- Why kiosk?
- Architecture
- Getting Started
- Uninstall kiosk
- Extra: User Management & Authentication
- Roadmap
- Contributing
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 is designed to be:
- 100% Open-Source: CNCF compatible Apache 2.0 license
- Pluggable: easy to install into any existing cluster and suitable for different use cases
- Fast: emphasizing automation and self-service for tenants
- Secure: offering default configurations for different levels of tenant isolation
- Extensible: providing building blocks for higher-level Kubernetes platforms
The core idea of kiosk is to use Kubernetes namespaces as isolated workspaces where tenant applications can run isolated from each other. To minimize admin overhead, cluster admins are supposed to configure kiosk which then becomes a self-service system for provisioning Kubernetes namespaces for tenants.
The following diagram shows the main actors (Cluster Admins and Account Users) as well as the most relevant Kubernetes resources and their relationships.
Click on the following links to view the description for each of the actors and kiosk components:
Cluster Admins
Cluster Admins have the permission to perform CRUD operations for cluster-wide / non-namespaced resources (especially RBAC related resources as well as the custom resources Account, AccountQuota, AccountQuotaSet, and Template). Cluster Admins configure kiosk by creating and managing Accounts, AccountQuotas, AccountQuotaSets, and Templates. They can also see and configure all Spaces owned by all Accounts.
Account
Every tenant is represented by an Account. Cluster Admins define and manage Accounts and assign Account Users (Users, Groups, ServiceAccounts) to Accounts - similar to assigning RBAC Roles to subjects as part of a RoleBinding configuration.
Account User
Account Users perform actions within the Kubernetes cluster via API server requests while using a certain Account. Cluster Admins can assign the same Account User to multiple Accounts. Account Users have access to Spaces that belong to the Accounts they are using. If assigned the default kiosk ClusterRole, every Account User has the permission to list/get/create/delete Spaces for the respective Account, however, this can be changed via RBAC RoleBindings.
Space
A Space is a non-persistent, virtual resource that represents exactly one Kubernetes namespace. Every space belongs to exactly one Account which is the owner of this Space. When Account Users create a Space, they define which Account owns this Space. For all Account Users, a RoleBinding will be created that grants access rights for the Account Users regarding the newly created Space as well as regarding its underlying Namespace. Which access rights will be granted can be configured with an RBAC ClusterRole. Spaces can be accessed if a user has rights to access the underlying Namespace, hence besides Account Users, other actors (User, Group, ServiceAccount) can also access a namespace if an Account User or any other Cluster Admin grants this access via additional Kubernetes RBAC Roles and RoleBindings. To populate a Space with a predefined set of resources, Templates can be applied to the Space during Space creation. Certain Templates may be applied by default if a Cluster Admin configured them as defaultTemplates within the Account configuration.
Namespace
A Namespace is a regular Kubernetes Namespace that can be accessed by anyone who has the appropriate RBAC rules to do so. Namespaces are provisioned and managed by kiosk and have a 1-to-1 relationship to the resource Space which is a custom resource of kiosk. By default, Account Users have the permission to operate within all Namespaces that are represented by Spaces which belong to one of their Accounts.
Template
Templates are defined and managed by Cluster Admins. Templates are used to initialize Spaces/Namespaces with a set of Kubernetes resources (defined as manifests or as part of a Helm chart). Templates can be created using a different ClusterRole than the Account User uses, so they can be used to create resources that are not allowed to be created by actors of the Space/Namespace, e.g. to set up certain isolation resources (e.g. Network Policies, Pod Security Policies etc.). Cluster Admins can define default Templates within the Account configuration which automatically applies these templates to each Space that is created using the respective Account. Additionally, Account Users can state other non-mandatory Templates that should also be applied when creating a Space.
TemplateInstance
When a Template is applied to a Space, kiosk creates a TemplateInstance to keep track of which Templates have been applied to the Space. A TemplateInstance contains information about the Template as well as about the parameters used to instantiate it. Additionally, TemplateInstances can be configured to sync with Templates, i.e. the TemplateInstance will update the resources whenever the Template changes that has been used to create these resources.
AccountQuota
AccountQuotas are defined and managed by Cluster Admins. AccountQuotas define cluster-wide aggregated limits for Accounts. The resources of all Spaces/Namespaces that belong to an Account count towards the aggregated limits defined in the AccountQuota. Similar to Namespaces which can be limited by multiple ResourceQuotas, an Account can be limited by multiple AccountQuotas. If the same limit (e.g. total CPU per Account) is defined by multiple AccountQuotas, the Account will be limited according to the lowest value.
AccountQuotaSet
An AccountQuotaSet defines a set of AccountQuotas which are managed by the AccountQuotaSet. It is comparable to a StatefulSet which creates and manages Pods in a Kubernetes namespace. An AccountQuotaSet consists of an accountLabelSelector and a template for an AccountQuota. For each Account that is selected by the AccountQuota, the AccountQuotaSet creates a new AccountQuota for the selected Account.
When installing kiosk in a Kubernetes cluster, these components will be added to the cluster:
- CRDs for Account, AccountQuota, AccountQuotaSet, Template, TemplateInstance
- Controller for kiosk Custom Resources (runs inside the cluster)
- API Server Extension (runs inside the cluster similar to the Controller)
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
- config.kiosk.sh/Account
- config.kiosk.sh/AccountQuota
- config.kiosk.sh/AccountQuotaSet (soon)
- config.kiosk.sh/Template
- config.kiosk.sh/TemplateInstance
-
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 using CRDs only 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
- tenancy.kiosk.sh/Account
- tenancy.kiosk.sh/AccountQuota
- tenancy.kiosk.sh/Space
- tenancy.kiosk.sh/TemplateInstance
kubectl: Follow this guide to install it.helmversion 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_USERYou 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 "*" crdkiosk needs cert-manager. You can install it into your cluster using helm v3:
# Install cert-manager with helm v3
kubectl create namespace cert-manager
helm install cert-manager --repo https://charts.jetstack.io cert-manager --version v0.12.0 --namespace cert-manager# Install kiosk with helm v3
kubectl create namespace kiosk
helm install kiosk --repo https://charts.devspace.sh/ kiosk --namespace kioskTo 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 1hIn 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:
- Cluster Admin: use your admin-context as current context (
kubectlcommands without--asflag) - Account User
john: use your admin-context to impersonate a user (kubectlcommands 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.yamlView: account.yaml
apiVersion: tenancy.kiosk.sh/v1alpha1
kind: Account
metadata:
name: johns-account
spec:
subjects:
- kind: User
name: john
apiGroup: rbac.authorization.k8s.ioAs 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:
- Users
- Groups
- ServiceAccounts (see example below:
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.yamlapiVersion: tenancy.kiosk.sh/v1alpha1
kind: Account
metadata:
name: johns-account
spec:
subjects:
- kind: ServiceAccount
name: john
namespace: johnLearn more about User Management and Accounts in kiosk.
By default, only cluster admins can view accounts. Account users cannot list or view any accounts. Run the following command to add an RBAC ClusterRoleBinding to allow users to view their own accounts:
# Run this as cluster admin:
kubectl apply -f https://raw.githubusercontent.com/kiosk-sh/kiosk/master/examples/rbac-viewer.yamlView: rbac-viewer.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: kiosk-viewer
subjects:
- kind: Group
name: system:authenticated
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: kiosk-view
apiGroup: rbac.authorization.k8s.io
Of course, you can also adjust this ClusterRoleBinding in a way that only certain subjects/users can list or view their Accounts. Just modify the
subjectssection.
After granting Account Users viewer access to their Accounts (see ClusterRoleBinding in 2.2.), all Account Users are able to view their Account. 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=johnSpaces 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 create/list/delete this resource without having to give them cluster-wide access for the actual namespaces.
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.yamlView: 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.ioOf 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=johnView: space.yaml
apiVersion: tenancy.kiosk.sh/v1alpha1
kind: Space
metadata:
name: johns-space
spec:
account: johns-accountAs 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=johnBy default, Account Users cannot list their Spaces. However, we created the RBAC ClusterRoleBinding in 2.2. for the kiosk default Role kiosk-view and this Role does not only allow subjects to view their own Accounts, it also allows subjects to view all Spaces that belong to their Accounts.
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.yamlThat'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.
To allow Account Users to delete all Spaces/Namespace that they create, you need to set the spec.spaceClusterRole field in the Account to kiosk-space-admin.
When creating a Space, kiosk creates the according Namespace for the Space and then creates a RoleBinding within this Namespace which binds the standard Kubernetes ClusterRole
adminto every Account User (i.e. allsubjectslisted in the Account). While this ClusterRole allows full access to this Namespace, it does not allow to delete the Space/Namespace.
As john can be User of multiple Accounts, let's create a second Account which allows john to delete Spaces/Namespaces that belong to this Account:
# Run this as cluster admin:
# Create Account johns-account-deletable-spaces
kubectl apply -f https://raw.githubusercontent.com/kiosk-sh/kiosk/master/examples/account-deletable-spaces.yamlView: account-deletable-spaces.yaml
apiVersion: tenancy.kiosk.sh/v1alpha1
kind: Account
metadata:
name: johns-account-deletable-spaces
spec:
spaceClusterRole: kiosk-space-admin
subjects:
- kind: ServiceAccount
name: john
namespace: kioskIf you are using ServiceAccounts instead of impersonation, adjust the
subjectssection of this Account similar toaccount-sa.yamlin 2.1.
Now, let's create a Space for this Account:
# Run this as cluster admin:
# Create Space johns-space-deletable
kubectl apply -f https://raw.githubusercontent.com/kiosk-sh/kiosk/master/examples/space-deletable.yamlView: space-deletable.yaml
apiVersion: tenancy.kiosk.sh/v1alpha1
kind: Space
metadata:
name: johns-space-deletable
spec:
account: johns-account-deletable-spacesIf a Space belongs to an Account that allows Account Users to delete such Spaces, an Account User can simply delete the Space using kubectl:
kubectl get spaces --as=john
kubectl delete space johns-space-deletable --as=john
kubectl get spaces --as=johnDeleting a Space also deletes the underlying Namespace.
With kiosk, you have two options to limit Accounts:
- Limit Number of Spaces for an Account
- Set Account Quotas = maximum values for resources aggregated across all Spaces of an Account (e.g. total number of Pods combined in all Spaces)
By setting the spec.spaceLimit in an Account, Cluster Admins can limit the number of Spaces that Account Users can create for a certain Account.
Let's run the following command to update the existing Account johns-account and apply a spaceLimit: 2:
# Run this as cluster admin:
kubectl apply -f https://raw.githubusercontent.com/kiosk-sh/kiosk/master/examples/account-space-limit.yamlView: account-space-limit.yaml
apiVersion: tenancy.kiosk.sh/v1alpha1
kind: Account
metadata:
name: johns-account
spec:
spaceLimit: 2
subjects:
- kind: User
name: john
apiGroup: rbac.authorization.k8s.ioNow, let's try to create more than 2 Spaces (note that you may have already created a Space for this Account during earlier steps of this getting started guide):
# List existing spaces:
kubectl get spaces --as=john
# Create space-2 => should work if you had only one Space for this Account so far
kubectl apply -f https://raw.githubusercontent.com/kiosk-sh/kiosk/master/examples/space-2.yaml --as=john
# Create space-3 => should result in an error
kubectl apply -f https://raw.githubusercontent.com/kiosk-sh/kiosk/master/examples/space-3.yaml --as=johnAccountQuotas allow you to define limits for an Account which are aggregated across all Spaces of this Account.
Let's create an AccountQuota for johns-account which will set the aggregated number of Pods across all Spaces to 2 and the aggregated maximum of limits.cpu across all Pods in all Spaces to 4 CPU Cores (see Kubernetes resource limits):
# Run this as cluster admin:
kubectl apply -f https://raw.githubusercontent.com/kiosk-sh/kiosk/master/examples/accountquota.yamlView: accountquota.yaml
apiVersion: config.kiosk.sh/v1alpha1
kind: AccountQuota
metadata:
name: default-user-limits
spec:
account: johns-account
quota:
hard:
pods: "2"
limits.cpu: "4"AccountQuotas allow you to restrict the same resources as Kubernetes ResourceQuotas but unlike ResourceQuotas, AccountQuotas are not restricted to a single Namespace. Instead, AccountQuotas add up all used resources across all Spaces of an Account to generate an aggregated value which is then compared to the max value defined in the AccountQuota.
If there are multiple AccountQuotas referencing the same Account via spec.account, kiosk merges the Quotas. In case multiple AccountQuotas define different limits for the same resource type, kiosk uses the lowest value.
Templates in kiosk are used to initialize Namespaces. When creating a Space, kiosk will use these Templates to populate the newly created Namespace for this Space. Templates:
- can either contain one or more Kubernetes manifests or alternatively a Helm chart
- can either be mandatory or optional (depending on the Account configuration)
- are being tracked by TemplateInstances in each Namespace they are applied to
The easiest option to define a Template is by specifying an array of Kubernetes manifests which should be applied when the Template is being instantiated.
The following command will create a Template called space-restrictions which defined 2 manifests, a PodSecurityPolicy which will make sure that the users of this Space/Namespace cannot create privileged containers and a LimitRange for default CPU limits of containers in this Namespace:
# Run this as cluster admin:
kubectl apply -f https://raw.githubusercontent.com/kiosk-sh/kiosk/master/examples/template-manifests.yamlView: template-manifests.yaml
apiVersion: config.kiosk.sh/v1alpha1
kind: Template
metadata:
name: space-restrictions
resources:
manifests:
- apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: space-security-policy
spec:
privileged: false
- apiVersion: v1
kind: LimitRange
metadata:
name: space-limit-range
spec:
limits:
- default:
cpu: 1
defaultRequest:
cpu: 0.5
type: ContainerInstead of manifests, a Template can specify a Helm chart that will be installed when the Template is being instantiated. Let's create a Template called redis which installs the stable/redis Helm chart:
# Run this as cluster admin:
kubectl apply -f https://raw.githubusercontent.com/kiosk-sh/kiosk/master/examples/template-helm.yamlView: template-helm.yaml
apiVersion: config.kiosk.sh/v1alpha1
kind: Template
metadata:
name: redis
resources:
helm:
releaseName: redis
chart:
repository:
name: stable/redis
values:
redisPort: 6379To get a list of available Templates, run the following command:
kubectl get templates --as=johnTemplates can either be mandatory or optional. By default, all Templates are optional. Cluster Admins can make Templates mandatory by adding them to the spec.spaceDefaultTemplates array within the Account configuration. All Templates listed in spec.spaceDefaultTemplates will always be instantiated within every Space/Namespace that is created for the respective Account.
Let's see this in action by updating the Account johns-account and adding our space-restrictions Template from 5.1. to spec.spaceDefaultTemplates:
# Run this as cluster admin:
kubectl apply -f https://raw.githubusercontent.com/kiosk-sh/kiosk/master/examples/account-default-template.yamlView: account-default-template.yaml
apiVersion: tenancy.kiosk.sh/v1alpha1
kind: Account
metadata:
name: johns-account-deletable-spaces
spec:
spaceClusterRole: kiosk-space-admin
spaceDefaultTemplates:
- space-restrictions
subjects:
- kind: User
name: john
apiGroup: rbac.authorization.k8s.ioIf you are using ServiceAccounts instead of impersonation, adjust the
subjectssection of this Account similar toaccount-sa.yamlin 2.1.
Now, let's create a Space without specifying any templates and see how this Template will automatically be instantiated:
kubectl apply -f https://raw.githubusercontent.com/kiosk-sh/kiosk/master/examples/space-template-mandatory.yaml --as=johnView: space-template-mandatory.yaml
apiVersion: tenancy.kiosk.sh/v1alpha1
kind: Space
metadata:
name: johns-space-template-mandatory
spec:
account: johns-accountNow, we can run the following command to see that the two resources (PodSecurityPolicy and LimitRange) defined in our Template space-restrictions have been created inside the Space/Namespace:
# Run this as cluster admin:
kubectl get podsecuritypolicy,limitrange -n johns-space-template-mandatoryMandatory Templates are generally used to enforce security restrictions and isolate namespaces from each other while Optional Templates often provide a set of default applications that a user might want to choose from when creating a Space/Namespace (see example in 5.2).
To keep track of resources created from Templates, kiosk creates a so-called TemplateInstance for each Template that is being instantiated inside a Space/Namespace.
To view the TemplateInstances of the namespace johns-space-template-mandatory, run the following command:
# Run this as cluster admin:
kubectl get templateinstances -n johns-space-template-mandatoryTemplateInstances allow admins and user to see which Templates are being used within a Space/Namespace and they make it possible to upgrade the resources created by a Template if there is a newer version of the Template (coming soon).
helm delete kiosk -n kioskkiosk does not provide a built-in user management system.
To manage users in your cluster, you can either use vendor-neutral solutions such as dex or DevSpace Cloud or alternatively, if you are in a public cloud, you may be able to use provider-specific solutions such as AWS IAM for EKS or GCP IAM for GKE.
If you like to use ServiceAccounts for a small and easy to set up authentication and user management, you can use the following instructions to create new users / kube-configs.
Use
bashto run the following commands.
USER_NAME="john"
kubectl -n kiosk create serviceaccount $USER_NAME# If not already set, then:
USER_NAME="john"
KUBECONFIG_PATH="$HOME/.kube/config-kiosk"
kubectl config view --minify --raw >$KUBECONFIG_PATH
export KUBECONFIG=$KUBECONFIG_PATH
CURRENT_CONTEXT=$(kubectl config current-context)
kubectl config rename-context $CURRENT_CONTEXT kiosk-admin
CLUSTER_NAME=$(kubectl config view -o jsonpath="{.clusters[].name}")
ADMIN_USER=$(kubectl config view -o jsonpath="{.users[].name}")
SA_NAME=$(kubectl -n kiosk get serviceaccount $USER_NAME -o jsonpath="{.secrets[0].name}")
SA_TOKEN=$(kubectl -n kiosk get secret $SA_NAME -o jsonpath="{.data.token}" | base64 -d)
kubectl config set-credentials $USER_NAME --token=$SA_TOKEN
kubectl config set-context kiosk-user --cluster=$CLUSTER_NAME --user=$USER_NAME
kubectl config use-context kiosk-user
# Optional: delete admin context and user
kubectl config unset contexts.kiosk-admin
kubectl config unset users.$ADMIN_USER
export KUBECONFIG=""# If not already set, then:
KUBECONFIG_PATH="$HOME/.kube/config-kiosk"
export KUBECONFIG=$KUBECONFIG_PATH
kubectl ...export KUBECONFIG=""
kubectl ...| YYYY-MM-DD | Work Item |
|---|---|
| TBD | Project: inaugural Zoom call with all initial design partners & future contributors* |
| TBD | Project: set up docs page with docusaurus |
| TBD | Project: create landing page |
| 2020-03-02 | TemplateInstance: implement logic to keep TemplateInstances in sync |
| 2020-03-16 | Project: add project to CNCF landscape |
| 2020-03-25 | AccountQuota: implement all ResourceQuota hard limits |
| TBD | Multi-Cluster: proposal for config resources and general workflow |
| TBD | Project: suggest kiosk as CNCF sandbox project |
* Send an email to Lukas if you would like an invite to the call.
The following questions are currently being discussed. Suggestions are highly appreciated.
- How can we achieve that Account Users will be able to install CRDs and controllers into the cluster without having to go through the admin?
- How can we achieve that Account Users will be able to install CRDs just for their own Account instead of for all cluster users? (virtual cluster approach, via API Server extension?)
- How can we make it easier for an Account User or even just a Namespace User to get cluster access? (Current assumption is that all users have cluster access via preconfigured kube-config.)
There are many ways to get involved:
- Open an issue for questions, to report bugs or to suggest new features
- Open a pull request to contribute improvements to the code base or documentation
- Email one of the maintainers (Lukas, Fabian) for an invite to the bi-weekly conference call, to be added to the Slack channel or to find out more about the project and how to get involved
For more detailed instructions, see our Contributing Guide.
This is a very new project, so we are actively looking for contributors and maintainers. Reach out if you are interested.
1. Install DevSpace
kubectl create namespace cert-manager
helm install cert-manager cert-manager --repo https://charts.jetstack.io --version v0.12.0 --namespace cert-manager# Start Development Mode
devspace run dev
# In the terminal start the application with
go run -mod vendor main.gomake
make install
make run ENABLE_WEBHOOKzooS=falsekiosk is an open-source project licensed under Apache-2.0 license. The project will be contributed to CNCF once it reaches the required level of popularity and maturity. The first version of kiosk was developed by DevSpace Technologies as core component for their DevSpace Cloud on-premise edition.