RBAC support

If a Role-Based Access Control (RBAC) mechanism is enabled in your Kubernetes cluster, you should perform additional steps to get your Ingress controller properly configured. This guide will provide you with the basic configurations for either RBAC-enabled clusters or RBAC-disabled clusters.

If your cluster has the RBAC configured in a specific way or if you need additional information about role-based cluster access management, refer to the official Kubernetes documentation. If you use a Kubernetes cluster from a cloud service provider, you could refer to the provider’s documentation as well.

2. Setting up Helm to Interact with Your Kubernetes Cluster

The server part named Tiller that installs directly into you Kubernetes cluster and does all the backstage work of deployment applications via Helm Charts.

Helm and Tiller communicate in an open way by default, with no encryption of any messages. You could add SSL encryption for better security. You need an OpenSSL tool if you want to do that. More information about securing Helm and Tiller can be obtained here.

Depending on whether RBAC is enabled in your cluster, you should take different approaches while configuring Helm.

If you Kubernetes cluster is RBAC-enabled, do the following to set up Helm:

Make sure that the Kubectl tool works in the context with the necessary permissions (Kubectl should be run by the user whose account has been correctly assigned a cluster-admin role in your cluster).

Some Kubernetes cluster service providers (e.g., Microsoft) create and bind the cluster-admin role to the user account while the Kubectl tool is being initialized, whereas others do not. In the latter case, it is necessary to manually create the role binding. For example, if you use Google Kubernetes Engine, bind the role to your account by executing the following command:

The service account tiller-account is specified here and is bound to the cluster role cluster-admin.

Apply the configuration from the file helm-rbac.yaml by executing the following command:

$ kubectl apply -f helm-rbac.yaml

You should be provided with the following output:

serviceaccount "tiller-account" created
clusterrolebinding.rbac.authorization.k8s.io "tiller-admin-binding" created

To initialize Tiller with the privilege level of the created service account tiller-account, execute the command helm init --service-account=tiller-account.

If the command helm init was successfully executed, you will be presented with an output similar to the following:

Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.
Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.
To prevent this, run `helm init` with the --tiller-tls-verify flag.
For more information on securing your installation see: https://docs.helm.sh/using_helm/#securing-your-helm-installation
Happy Helming!

Check if Helm is in an operational state by executing the command helm ls --all.
The output of the command must contain no errors but include the list of all Helm Chart deployments in your cluster (note that the list might be empty; this is normal).

3. Creating a Kubernetes Secret to Access Your Docker Registry

Helm requires a Kubernetes secret to access your Docker registry. Provided with the secret, Helm will be able to pull the Wallarm NGINX Ingress Plus controller Docker image from your private repository during the deployment process.

A secret to access a Docker registry comprises the registry name and the credentials used to access the registry (a login and password pair for the Docker registry).

To create the Kubernetes secret for a Docker registry, execute the following command:

Set the path to your private Docker repository (containing the Docker image of Wallarm NGINX Ingress Plus controller) as the value of the controller.image.repository parameter. Additionally, make sure that the version of the Docker image (or tag) hosted in your repository is identical to the value of the controller.image.tag parameter:

An Ingress controller works in conjunction with an Ingress resource that describes the incoming HTTP and HTTPS traffic routing rules, thereby allowing the traffic to reach your services deployed in the Kubernetes cluster.

As your next step, you should deploy the Ingress resource for the Ingress controller to work.