docs/doc/source/security/kubernetes/configure-remote-helm-client-for-non-admin-users.rst

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_cli_wd

1. Set the namespace.

   ~(keystone_admin)]$ NAMESPACE=default

2. Set up accounts, roles and bindings.

   1. Execute the following commands.

      Note

      These commands could be run remotely by the non-admin user who has access to the default namespace.

      ~(keystone_admin)]$ 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
      ~(keystone_admin)]$ kubectl apply -f default-tiller-sa.yaml

   2. 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

3. 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 --home "./.helm"

   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_cli_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>

Using Container-backed Remote CLIs and Clients <using-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>