Helm based Installation

Prerequisites

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

Veeam Kasten Installation

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 Veeam Kasten 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 Veeam Kasten 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 Veeam Kasten.

Using an OAuth Proxy

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

Securing Veeam Kasten with SecurityContextConstraints

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

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

Note

Starting with OpenShift 4.14, a new openshift.io/required-scc annotation was introduced. Veeam Kasten applies this annotation to its own pods to ensure that the correct SecurityContextConstraints (SCC) have been applied.

Please note that pods created for Kanister Execution Hooks execution will not receive the openshift.io/required-scc annotation. For more information, visit the Managing security context constraints.

`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 Veeam Kasten 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 requirement will be selected and assigned to that workload. One of the criteria for SCC selection is the 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.

Veeam Kasten 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, Veeam Kasten 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 Veeam Kasten's installation in this cluster.

Despite the usage restrictions, it is still possible to get Veeam Kasten's SCC assigned to other workloads. This could happen when a workload is started by a cluster admin or any other user with an allowed use action on all SCCs (*) or on Veeam Kasten'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.

Veeam Kasten's SCC may be unexpectedly applied to workloads it was not 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 with kubectl in the command below.

To check if a user can use/access Veeam Kasten'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 Veeam Kasten's SCC or no if it is not. For example, the output for the following check, "Can Veeam Kasten's ServiceAccount use Veeam Kasten'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 Veeam Kasten has been installed properly, the following command can be run in Veeam Kasten's namespace (the install default is kasten-io) to watch for the status of all Veeam Kasten 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 Veeam Kasten dashboard will not be exposed externally. To establish a connection to it, use the following kubectl command to forward a local port to the Veeam Kasten ingress port:

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

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

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