Helm based Installation

Prerequisites

Before installing K10 on Red Hat OpenShift, please ensure that the install prerequisites are met.

K10 Install

Depending on your OpenShift infrastructure provider, you might need to provide access credentials as specified elsewhere for public cloud providers.

You will also need to add the following argument to create the SecurityContextConstraints for K10 ServiceAccounts.

$ helm install k10 kasten/k10 --namespace=kasten-io \
    --set scc.create=true

OpenShift on AWS

When deploying OpenShift on AWS without using the EBS CSI driver for persistent storage, make sure that you configure these policies before executing the installation command provided below:

$ helm install k10 kasten/k10 --namespace=kasten-io \
    --set scc.create=true \
    --set secrets.awsAccessKeyId="${AWS_ACCESS_KEY_ID}" \
    --set secrets.awsSecretAccessKey="${AWS_SECRET_ACCESS_KEY}"

OpenShift on Azure

When running OpenShift on Azure, you need to specify the credential of a service principal that has a contributor role on the resource group. You also need to specify the resource group of the openshift nodes and the subscription id.

$ helm install k10 kasten/k10 --namespace=kasten-io \
    --set scc.create=true \
    --set secrets.azureTenantId=<tenantID> \
    --set secrets.azureClientId=<azureclient_id> \
    --set secrets.azureClientSecret=<azureclientsecret> \
    --set secrets.azureResourceGroup=<resource_group_name> \
    --set secrets.azureSubscriptionID=<subscription_id>

Accessing Dashboard via Route

As documented here, the K10 dashboard can also be accessed via an OpenShift Route.

Authentication

OpenShift OAuth server

As documented here, the OpenShift OAuth server can be used to authenticate access to K10.

Using OAuth Proxy

As documented here, the OpenShift OAuth proxy can be used for authenticating access to K10.

Securing K10 with SecurityContextConstraints

K10 installs customized SecurityContextConstraints (SCC) to ensure that all workloads associated with K10 have just enough privileges to perform their respective tasks.

For additional information about SCCs, please refer to the official OpenShift documentation

`SecurityContextConstraints` customization

The value of the Priority field in SecurityContextConstraints (SCC) can be adjusted to align the priority with the existing cluster configuration.

To set the desired Priority value in an Operator-managed installation, modify the YAML of the K10 Operand configuration with the parameters below:

scc:
  priority: <priority_value>

This customization can be achieved in a Helm-based installation by adding the following parameter to the Helm command:

--set scc.priority=<priority_value>

`SecurityContextConstraints` Leakage

Openshift assigns SCC to workloads automatically. By default, the most restrictive SCC matching a workload security requirements will be selected and assigned to that workload. One of the criteria for SCC selection is availability of the SCC to a User or ServiceAccount. SCC leakage means that some workloads might get an SCC applied to them which was not the intended one.

K10 protects its SCC from leaking onto other workloads by limiting access only to its dedicated ServiceAccount:

users:
  - system:serviceaccount:kasten-io:k10-k10

Note

In this example, and in the rest of this page, K10 is installed into the namespace kasten-io (default), the ServiceAccount name is the default one - k10-k10, and the SCC name is also the default one - k10-scc. If the cluster being considered has a different configuration, those values need to be adapted to match the values used during K10's installation in this cluster.

Despite the usage restrictions, it is still possible to get K10's SCC assigned to other workloads. This could happen when a workload is started by a cluster admin or by any other user with allowed use action on all SCCs(*) or on K10's specific SCC(k10-scc). This is because users with the ClusterRole cluster-admin bound to them have unlimited access to all available SCCs, without any restrictions.

K10's SCC may be unexpectedly applied to workloads it wasn't intended for under the following conditions:

The workload is initiated by a user with cluster admin privileges
The user initiating the workload has a role that grants access to all SCCs

How to verify if access to a specific `SecurityContextConstraints` is granted

OpenShift's command line (CLI) client, oc, has a can-i command that can be used with impersonation to check if a user can perform a specific action on a specific resource. Alternatively, the standard kubectl CLI client also has the same command built-in and can be used to perform the same check. Simply replace oc by kubectl in the command below.

To check if a user can use/access K10's SCC the following command can be used:

oc auth can-i use securitycontextconstraints/k10-scc --as=<your_username>

The output will contain yes if the specified user is able to use K10's SCC or no if it is not. For example the output for the following check, "Can K10's ServiceAccount use K10's SCC", should be yes:

oc auth can-i use securitycontextconstraints/k10-scc --as=system:serviceaccount:kasten-io:k10-k10

Detailed information about can-i and impersonation can be found in the official Kubernetes documentation.

Validating the Install

To validate that K10 has been installed properly, the following command can be run in K10's namespace (the install default is kasten-io) to watch for the status of all K10 pods:

$ kubectl get pods --namespace kasten-io --watch

It may take a couple of minutes for all pods to come up but all pods should ultimately display the status of Running.

$ kubectl get pods --namespace kasten-io
NAMESPACE     NAME                                    READY   STATUS    RESTARTS   AGE
kasten-io     aggregatedapis-svc-b45d98bb5-w54pr      1/1     Running   0          1m26s
kasten-io     auth-svc-8549fc9c59-9c9fb               1/1     Running   0          1m26s
kasten-io     catalog-svc-f64666fdf-5t5tv             2/2     Running   0          1m26s
...

In the unlikely scenario that pods that are stuck in any other state, please follow the support documentation to debug further.

Validate Dashboard Access

By default, the K10 dashboard will not be exposed externally. To establish a connection to it, use the following kubectl command to forward a local port to the K10 ingress port:

$ kubectl --namespace kasten-io port-forward service/gateway 8080:80

The K10 dashboard will be available at http://127.0.0.1:8080/k10/#/.

For a complete list of options for accessing the Kasten K10 dashboard through a LoadBalancer, Ingress or OpenShift Route you can use the instructions here.