
Re-organized topic hierarchy Tiny edit to restart review workflow. Squashed with Resolved index.rst conflict commit Change-Id: I13472792cb19d1e9975ac76c6954d38054d606c5 Signed-off-by: Keane Lim <keane.lim@windriver.com> Signed-off-by: MCamp859 <maryx.camp@intel.com>
5.1 KiB
Configure Remote Helm Client for Non-Admin Users
For non-admin users (i.e. users without access to the default Tiller server running in kube-system namespace), you must create a Tiller server for this specific user in a namespace that they have access to.
By default, helm communicates with the default Tiller server in the kube-system namespace. This is not accessible by non-admin users.
For non-admin users use of the helm client, you must create your own Tiller server, in a namespace that you have access to, with the required capabilities and optionally protection.
To create a Tiller server with permissions within the default namespace, complete the following steps on the controller: Except where indicated, these commands can be run by the non-admin user, locally or remotely.
Note
If you are using container-backed helm CLIs and clients (method 1), ensure you change directories to <$HOME>/remote_wd
Set the namespace.
~(keystone_admin)$ NAMESPACE=default
Set up accounts, roles and bindings.
Execute the following commands.
Note
These commands could be run remotely by the non-admin user who has access to the default namespace.
% cat <<EOF > default-tiller-sa.yaml apiVersion: v1 kind: ServiceAccount metadata: name: tiller namespace: default --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: tiller namespace: default rules: - apiGroups: ["*"] resources: ["*"] verbs: ["*"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: tiller namespace: default roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: tiller subjects: - kind: ServiceAccount name: tiller namespace: default EOF % kubectl apply -f default-tiller-sa.yaml
Execute the following commands as an admin-level user.
~(keystone_admin)$ kubectl create clusterrole tiller --verb get --resource namespaces ~(keystone_admin)$ kubectl create clusterrolebinding tiller --clusterrole tiller --serviceaccount ${NAMESPACE}:tiller
Initialize the Helm account.
~(keystone_admin)$ helm init --service-account=tiller --tiller-namespace=$NAMESPACE --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | sed 's@ replicas: 1@ replicas: 1\n \ selector: {"matchLabels": {"app": "helm", "name": "tiller"}}@' > helm-init.yaml ~(keystone_admin)$ kubectl apply -f helm-init.yaml ~(keystone_admin)$ helm init –client-only
Note
Ensure that each of the patterns between single quotes in the above
sed
commands are on single lines when run from your command-line interface.Note
Add the following options if you are enabling TLS for this Tiller:
--tiller-tls
-
Enable TLS on Tiller.
--tiller-tls-cert <certificate\_file>
-
The public key/certificate for Tiller (signed by
--tls-ca-cert
). --tiller-tls-key <key\_file>
-
The private key for Tiller.
--tiller-tls-verify
-
Enable authentication of client certificates (i.e. validate they are signed by
--tls-ca-cert
). --tls-ca-cert <certificate\_file>
-
The public certificate of the used for signing Tiller server and helm client certificates.
You can now use the private Tiller server remotely or locally by
specifying the --tiller-namespace
default option on all
helm CLI commands. For example:
helm version --tiller-namespace default
helm install --name wordpress stable/wordpress --tiller-namespace default
Note
If you are using container-backed helm CLI and Client (method 1), then you change directory to <$HOME>/remote_wd and include the following option on all helm commands:
—home "./.helm"
Note
Use the remote Windows Active Directory server for authentication of
remote kubectl
commands.
Configure Container-backed Remote CLIs and Clients
<security-configure-container-backed-remote-clis-and-clients>
Install Kubectl and Helm Clients Directly on a Host
<security-install-kubectl-and-helm-clients-directly-on-a-host>