Caution
Kubernetes support termination notice
Starting with the MCP 2019.2.5 update, the Kubernetes component is no longer supported as a part of the MCP product. This implies that Kubernetes is not tested and not shipped as an MCP component. Although the Kubernetes Salt formula is available in the community driven SaltStack formulas ecosystem, Mirantis takes no responsibility for its maintenance.
Customers looking for a Kubernetes distribution and Kubernetes lifecycle management tools are encouraged to evaluate the Mirantis Kubernetes-as-a-Service (KaaS) and Docker Enterprise products.
After you enable the role-based access control (RBAC) on your Kubernetes
cluster as described in Deployment Guide: Enable RBAC,
you can start controlling system access to authorized users by creating,
changing, or restricting user or services roles as required. Use the
kubernetes.control.role state to orchestrate the role and role binding.
The following example illustrates a configuration of a brand-new role and role binding for a service account:
control:
role:
etcd-operator:
kind: ClusterRole
rules:
- apiGroups:
- etcd.coreos.com
resources:
- clusters
verbs:
- "*"
- apiGroups:
- extensions
resources:
- thirdpartyresources
verbs:
- create
- apiGroups:
- storage.k8s.io
resources:
- storageclasses
verbs:
- create
- apiGroups:
- ""
resources:
- replicasets
verbs:
- "*"
binding:
etcd-operator:
kind: ClusterRoleBinding
namespace: test # <-- if no namespace, then it is ClusterRoleBinding
subject:
etcd-operator:
kind: ServiceAccount
The following example illustrates a configuration of the test edit
permissions for a User in the test namespace:
kubernetes:
control:
role:
edit:
kind: ClusterRole
# No rules defined, so only binding will be created assuming role
# already exists.
binding:
test:
namespace: test
subject:
test:
kind: User