Note
With the 7.0 release in May 2024, "Kasten by Veeam" and "Kasten K10" have been replaced with "Veeam Kasten for Kubernetes." Throughout this documentation, references to "K10" will be modified to include both the new and simpler "Veeam Kasten" names. Both names will be used for a while, and then the documentation will be modified only to use the new names. The name K10 is still used for functional examples.
Operator based Installation
Veeam Kasten Operator Editions
Veeam Kasten (Free): Free edition of Veeam Kasten for use in clusters up to 5 nodes
Veeam Kasten (Enterprise - PAYGO): Enterprise edition of Veeam Kasten, billed per usage of node-hours
Veeam Kasten (Enterprise - Term): Enterprise edition of Veeam Kasten intended to be used with a term license
Pre-Flight Checks
Assuming that your default oc context is pointed to the cluster you want to install Veeam Kasten on, you can run pre-flight checks by deploying the primer tool. This tool runs in a pod in the cluster and does the following:
Validates if the Kubernetes settings meet the Veeam Kasten requirements.
Catalogs the available StorageClasses.
If a CSI provisioner exists, it will also perform a basic validation of the cluster's CSI capabilities and any relevant objects that may be required. It is strongly recommended that the same tool be used to also perform a more complete CSI validation using the documentation here.
Note that this will create and clean up a ServiceAccount and ClusterRoleBinding to perform sanity checks on your Kubernetes cluster.
Run the following command to deploy the pre-check tool:
$ curl https://docs.kasten.io/tools/k10_primer.sh | bash
Prerequisites
Before installing Veeam Kasten, it is essential to have a functional and accessible Red Hat OpenShift environment.
Optionally, you can create a new project in advance where Veeam Kasten will be installed. Select this project during operator deployment, or create a project (namespace) during the operator installation process. By default, the documentation uses the kasten-io namespace.
oc new-project kasten-io \
--description="Kubernetes data management platform" \
--display-name="Kasten K10"
Veeam Kasten Installation
Interactive Demo
Step-by-Step Guide
Select the OperatorHub from the Operators Menu, search for Veeam Kasten. Select either the Certified Operator, or Marketplace version, depending on the requirements.
To begin the installation, simply click
Install
.
Next, set the channel to stable and the installation mode to
A specific namespace on the cluster
. Choose thekasten-io
project created in an earlier step.
After installation, click
Create Instance
on the operator details page to create a Veeam Kasten instance.
The default installation can be done through either the
Form View
orYAML View
. By default, no changes are required to install.Veeam Kasten assumes that the default storage class is supported by SSDs or equivalent fast storage media. If this assumption is not true, please modify the installation values to specify a performance-oriented storage class. This modification can be done within the form view or directly within the YAML of the Veeam Kasten Operand configuration by setting the parameters below:
global: persistence: storageClass: <storage-class-name>
Offline Operator Install
Note
Only Veeam Kasten Operator Editions "Veeam Kasten (Free)" and "Veeam Kasten (Enterprise - Term)" are supported in disconnected environments.
Create a filtered RedHat marketplace index image in the private registry.
Log into both the Red Hat registry and the private registry. The private registry is the registry disconnected cluster has access to.
$ docker login registry.redhat.io
$ podman login <private registry>
Prune the index image to include the Veeam Kasten operator(s).
The steps below are using the Veeam Kasten operators from
registry.redhat.io/redhat/redhat-marketplace-index:v4.9
.
$ opm index prune -f registry.redhat.io/redhat/redhat-marketplace-index:v4.9 \
-p k10-kasten-operator-rhmp,k10-kasten-operator-term-rhmp \
-t <private registry>/redhat-marketplace-index:v4.9 \
-c docker
Push the pruned index image to the private registry.
$ docker push <private registry>/redhat-marketplace-index:v4.9
Create a pull secret with RedHat and private registry credentials.
Follow the steps in Configuring credentials that allow images to be mirrored to create an image registry credentials file that allows mirroring images to the private registry.
Mirror the operator images to the private registry
$ REG_CREDS=pull-secret.json # path to pull secret file created in step 2
$ oc adm catalog mirror <private registry>/redhat-marketplace-index:v4.9 \
<private registry>/olm-mirror -a ${REG_CREDS}
This copies the operator images from RedHat to the local registry. This also creates a manifest directory, which is used in the next two steps.
Example output:
...
info: Mirroring completed in 4.61s (0B/s)
no digest mapping available for <private registry>/redhat-marketplace-index:v4.9, skip writing to ImageContentSourcePolicy
wrote mirroring manifests to <path of manifest directory>
Create an ImageContentSourcePolicy in the disconnected cluster.
Create an ImageContentSourcePolicy
object using the
imageContentSourcePolicy.yaml
file in the manifests directory created
in step 3.
$ oc create -f <path to manifests dir>/imageContentSourcePolicy.yaml
Create a CatalogSource in the disconnected cluster.
Create a CatalogSource
object using the catalogSource.yaml
file in the
manifests directory created in step 3.
$ oc create -f <path to manifests dir>/catalogSource.yaml
catalogSource.yaml
can be updated to specify a catalog display name as the
example below.
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
name: test-catalog
namespace: openshift-marketplace
spec:
image: <catalog image>
sourceType: grpc
displayName: Offline Catalog
publisher: Local Publisher
updateStrategy:
registryPoll:
interval: 30m
Optionally, default catalog sources can be removed with the command below.
$ oc patch OperatorHub cluster --type json \
-p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
Verify the package manifest.
$ oc get packagemanifest -n openshift-marketplace
NAME CATALOG AGE
k10-kasten-operator-term-rhmp Test Catalog 10m
k10-kasten-operator-rhmp Test Catalog 10m
Install the operators via the operator hub.
Veeam Kasten operators can be now installed from the operator hub.
Follow the steps under operator install to continue installing Veeam Kasten.
Other Installation Options
For a complete list of installation options, please visit our advanced installation page.
Note
After installing the "Veeam Kasten (Enterprise - PAYGO)" edition, if the warning message "Unable to validate Red Hat Marketplace license" is displayed on the Veeam Kasten dashboard, please verify the cluster is registered with Red Hat Marketplace and the Red Hat Marketplace Operator is installed, and then re-install Veeam Kasten.
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}"
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.
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.
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.