Profiles
A Profile custom resource (CR) is used to perform operations on K10 Profiles. You can learn more about using K10 Profiles at Location Configuration.
Example Profile Operations
Create a Profile Secret
When creating a Profile, you first need to create a Kubernetes secret that holds the credentials for the location associated with the profile. The examples below use an S3 bucket and therefore requires a properly formatted S3 secret.
$ kubectl create secret generic k10-s3-secret \
--namespace kasten-io \
--type secrets.kanister.io/aws \
--from-literal=aws_access_key_id=AKIAIOSFODNN7EXAMPLE \
--from-literal=aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
For complete documentation of secret formats, refer to Profile Secret Types.
Create an Object Store Location Profile
With a secret already defined, you can now create an Object Store Location Profile. Object Store location profiles can be used for import as well as export operations.
$ cat <<EOF >>sample-profile.yaml
apiVersion: config.kio.kasten.io/v1alpha1
kind: Profile
metadata:
name: sample-profile
namespace: kasten-io
spec:
type: Location
locationSpec:
credential:
secretType: AwsAccessKey
secret:
apiVersion: v1
kind: Secret
name: k10-s3-secret
namespace: kasten-io
type: ObjectStore
objectStore:
name: profile-s3-bucket
objectStoreType: S3
region: us-east-2
EOF
$ kubectl apply -f sample-profile.yaml
profile.config.kio.kasten.io/sample-profile created
# make sure it is initialized and validated properly
$ kubectl get profiles.config.kio.kasten.io --namespace kasten-io -w
NAME STATUS AGE
sample-profile Success 7s
For complete documentation of the Profile CR, refer to Profile API Type.
Create an Infrastructure Profile
The example demonstrates how to create a Ceph Infrastructure Profile, but an analogous approach applies to creating an OpenStack Profile.
First, create a secret with the Ceph provider credentials as described in Ceph KeyRing Secret.
$ cat <<EOF >>sample-ceph-profile.yaml
apiVersion: config.kio.kasten.io/v1alpha1
kind: Profile
metadata:
name: sample-ceph-profile
namespace: kasten-io
spec:
type: Infra
infra:
type: Ceph
ceph:
monitor: 10.0.0.10:6789
pool: my-pool
credential:
secretType: cephKeyring
secret:
apiVersion: v1
kind: Secret
name: k10-ceph-infra-secret
namespace: kasten-io
EOF
$ kubectl apply -f sample-ceph-profile.yaml
profile.config.kio.kasten.io/sample-ceph-profile created
# make sure it is initialized and validated properly
$ kubectl get profiles.config.kio.kasten.io --namespace kasten-io -w
NAME STATUS AGE
sample-ceph-profile Success 7s
For complete documentation of the Profile CR, refer to Profile API Type.
Create a Kanister Profile
Similarly to a Location Profile, you can create a Kanister Profile which is used to store artifacts generated for applications instrumented with a Kanister blueprint. K10 will currently use the earliest created Kanister Profile.
$ cat <<EOF >>kanister-profile.yaml
apiVersion: config.kio.kasten.io/v1alpha1
kind: Profile
metadata:
name: kanister-profile
namespace: kasten-io
spec:
type: Kanister
kanister:
credential:
secretType: AwsAccessKey
secret:
apiVersion: v1
kind: Secret
name: k10-s3-secret
namespace: kasten-io
location:
type: ObjectStore
objectStore:
name: profile-s3-bucket
objectStoreType: S3
region: us-east-2
EOF
$ kubectl apply -f kanister-profile.yaml
profile.config.kio.kasten.io/kanister-profile created
# make sure it is initialized and validated properly
$ kubectl get profiles.config.kio.kasten.io --namespace kasten-io -w
NAME STATUS AGE
kanister-profile Success 7s
For complete documentation of the Profile CR, refer to Profile API Type.
Create a Veeam Repository Location Profile
A Veeam Repository Location Profile is used to export or import vSphere CSI provisioned volume snapshot data in a supported vSphere cluster from a Veeam Repository. A Veeam Repository cannot be used to save K10 restore points so such a location profile is always used in conjunction with another location profile that can be used to save restore point data.
This profile requires a secret whose creation is described in Veeam Repository Secret. Once the secret has been created the Veeam Repository Location Profile is created as follows:
$ cat <<EOF >>sample-vbr-profile.yaml
apiVersion: config.kio.kasten.io/v1alpha1
kind: Profile
metadata:
name: sample-vbr-profile
namespace: kasten-io
spec:
type: Location
locationSpec:
credential:
secretType: VBRKey
secret:
apiVersion: v1
kind: Secret
name: k10-vbr-secret
namespace: kasten-io
type: VBR
vbr:
repoName: Default Backup Repository
serverAddress: 192.168.1.218
serverPort: 9419
skipSSLVerify: true
EOF
$ kubectl apply -f sample-vbr-profile.yaml
profile.config.kio.kasten.io/sample-vbr-profile created
The repoName field specifies the name of the repository to use;
it should not be an immutable repository.
The serverPort and skipSSLVerify fields are optional.
For complete documentation of the Profile CR, refer to Profile API Type.
Update a Profile
To update a Profile edit the spec portion of a Profile CR using your preferred method of submitting resource changes with kubectl.
$ kubectl apply -f sample-profile-changed.yaml
profile.config.kio.kasten.io/sample-profile configured
Once the change is submitted, K10 will re-validate the profile and update .status.validation accordingly.
$ kubectl get profiles.config.kio.kasten.io --namespace kasten-io -w
NAME STATUS AGE
sample-profile Success 7s
Since K10 processes API object changes asynchronously, to avoid confusion with a previous Profile status, it is recommended as convention that the status portion of the Profile is omitted when submitting changes.
Delete a Profile
You can delete a Profile using the following command.
# delete profile "sample-profile" for K10 installed in "kasten-io"
$ kubectl delete profiles.config.kio.kasten.io sample-profile --namespace kasten-io
profile.config.kio.kasten.io "sample-profile" deleted
Profile API Type
The following is a complete specification of the Profile CR.
# Standard Kubernetes API Version declaration. Required.
apiVersion: config.kio.kasten.io/v1alpha1
# Standard Kubernetes Kind declaration. Required.
kind: Profile
# Standard Kubernetes metadata. Required.
metadata:
# Profile name. May be any valid Kubernetes object name. Required.
# Profile name is not mutable once created.
name: sample-location-profile
# Profile namespace. Required. Must be namespace where K10 is installed
namespace: kasten-io
# Profile parameters. Required.
spec:
# Type of Profile. Required
# Valid values are Location, Kanister, Infra
type: Location
# Only one of the profile type sections can be specified
# NOTE: camelCasing of the key is important
locationSpec:
# Credentials associated with profile location. Required.
credential:
# Type of secret being specified. Required.
# Valid values are:
# # AwsAccessKey (Amazon S3 and Generic S3)
# # GcpServiceAccountKey (Google Cloud Storage)
# # AzStorageAccount (Azure Storage)
# # VBRKey (Veeam Backup & Replication Storage)
secretType: AwsAccessKey
# Reference to K8s secret with credentials of secretType. Required.
secret:
# Standard Kubernetes API Version. Must be 'v1'. Required.
apiVersion: v1
# Standard Kubernetes Kind declaration. Must be 'secret'. Required.
kind: secret
# Secret name. May be any valid Kubernetes secret name. Required.
name: sample-profile-secret
# Secret namespace. Must be K10 installed namespace . Required.
namespace: kasten-io
# Location for profile data. Required.
location:
# Type of location being specified. Required.
# Valid values are ObjectStore, FileStore, VBR
locationType: ObjectStore
# When the type above is ObjectStore. Required.
# Only one of the location type sections can be specified
objectStore:
# Type of object store. Required
# Valid values are:
# # S3 (Amazon S3 and Generic S3)
# # GCS (Google Cloud Storage)
# # Azure (Azure Storage)
objectStoreType: S3
# The endpoint for object store API. Optional.
# Can be omitted unless an S3 compatible provider is used.
endpoint: ''
# If set to true, do not verify SSL cert. Optional.
# Default, when omitted, is false
skipSSLVerify: false
# Name of the object store bucket. Required
name: gmm-test
# Region valid for the object store provider.
# Required, if supported by provider.
# If provider does not support region, pass ""
region: us-east-2
# Path within bucket for profile artifacts. Optional.
# If not used, it will be generated by the system and
# updated during delayed initialization and validation.
# If used, it requires pathType below as well.
path: k10/q4ees3b2zilluaxw/migration
# Type of the path within the bucket above. Optional.
# Defaults to Directory if not specified.
pathType: Directory
# The protection period for immutable backups. Optional.
# Must be shorter than the bucket default retention
# period minus 20 days.
protectionPeriod: 240h
# When the type above is FileStore. Required.
# Only one of the location type sections can be specified
fileStore:
# Name of the Persistent Volume Claim. Required.
claimName: test-pvc
# Path within the PVC mount for profile artifacts. Optional.
# If not used, it will be generated by the system and
# updated during delayed initialization and validation.
path: k10/q4ees3b2zilluaxw/migration
# When the type above is VBR. Required.
# Only one of the location type sections can be specified
vbr:
# Address of the Veeam backup server. Required.
serverAddress: vbr-server
# VBR server RESTful API port number. Optional.
# Defaults to 9419 if not specified.
serverPort: 9419
# Name of the target Veeam cloud repository for backup files. Required.
repoName: k10-repo
# Identifier of the target Veeam cloud repository for backup files. Optional.
# Reserved field for internal use. Once the profile is created,
# this field will contain the ID of the repository specified in the repoName field.
repoId: 123e4567-e89b-12d3-a456-426614174000
# If set to true, do not verify SSL cert. Optional.
# Default, when omitted, is false.
skipSSLVerify: false
# Optional: Make export to this profile infra-portable.
# Default: false
infraPortable: false
# When type above is Kanister - Kanister profile. Required.
# Only one of the profile type sections can be specified
# K10 currently only uses the oldest valid Kanister profile
# NOTE: camelCasing of the key is important
kanister:
# Credentials associated with profile location. Required.
credential:
# same content as credential in location above
# Location for profile data. Required.
location:
# same content as location in location above
# When type above is Infra - Infrastructure profile. Required.
# Only one of the following profile type sections can be specified
# NOTE: camelCasing of the key is important
infra:
# type of Infrastructure profile. Required
# Valid values are OpenStack, Ceph, Portworx, VSphere, AWS or GCP
type: OpenStack
# When type of this Infra profile above is OpenStack. Required.
# Only one of the following infra profiles can be specified
# NOTE: camelCasing of the key is important
openStack:
# Endpoint for the Keystone auth provider. Required
keystoneEndpoint: https://my-keystone-ip:1234
# When type of this Infra profile above is OpenStack. Required.
# Only one of the following infra profiles can be specified
# NOTE: camelCasing of the key is important
azure:
# Endpoint for the active directory login. Optional
ADEndpoint: https://login.microsoftonline.com/
# Resource ID to obtain AD tokens .Optional
ADResource: https://management.example.com/71fb132f-xxxx-4e60-yyyy-example47e19
# The name of Azure Cloud, e.g. AzurePublicCloud. Optional
cloudEnv: AzurePublicCloud
# Type of credentials used for profile. To be filled by controller
credentialType: ClientSecret
# Name of the Resource Group that was created for the Kubernetes cluster. Required
resourceGroup: myResourceGroup
# Endpoint for the resource manager. Optional
resourceManagerEndpoint: https://management.azure.com/
# Subscription ID for your Azure resources. Required
subscriptionID: 00000000-0000-0000-0000-000000000000
# Option to use the default Managed Identity. Optional
# If set to true, profile does not need a secret.
useDefaultMSI: true
ceph:
# Endpoint for the Ceph monitor to be used. Required.
monitor: 10.0.0.10:6789
# Name of the Ceph pool associated with this profile. Required.
pool: my-ceph-pool
portworx:
# The namespace of the Portworx service.
namespace: kube-system
# The name of the Portworx service.
serviceName: portworx-service
vsphere:
# The vSphere endpoint
serverAddress: vsphere.server.com
# Enable vSphere snapshot tagging
taggingEnabled: true
# The Category Name, automatically set when tagging is enabled.
categoryName: exampleCategory
# Credentials associated with the infrastructure provider. Required.
credential:
# Type of secret being specified. Required.
# Valid values are:
# # OpenStackAccount (OpenStack storage provider)
# # CephKeyring (Ceph storage provider)
# # PortworxKey (Portworx storage provider)
# # VSphereKey (vSphere storage provider)
# # GcpServiceAccountKey (GCP/GCS storage provider)
# # AwsAccessKey (AWS storage provider)
secretType: OpenStackAccount
# Reference to K8s secret with credentials of secretType. Required.
secret:
# Same format as above
# #####################
# Status of the Profile. Users should not set any data here.
status:
# Validation status of the Profile
# Valid values are:
# # Success - successfully initialized and validated
# # Failed - not properly initialized on validated
# Only profiles which have status of Success should be used
validation: Success
# An array of any validation or initialization errors encountered.
error: null
# Hash of the spec portion of the profile.
# Used internally to determine when successfully validated profiles
# need to be reprocessed.
hash: 3369880242
Profile Secret Types
The following are the different secret types and formats to be used with profiles.
AWS S3 and S3 Compatible Bucket Secret
When a Profile is using an S3 or S3-compatible bucket location, the credential secret must follow the format below. In order to use temporary security credentials, you can generate an IAM role and provide it as a part of the S3 secret as shown below. K10 supports the generation of temporary credentials to perform generic backups, export collections to an object store, and for EBS/EFS snapshot operations.
# Standard Kubernetes API Version declaration. Required.
apiVersion: v1
# Standard Kubernetes Kind declaration. Required.
kind: Secret
# Standard Kubernetes metadata. Required.
metadata:
# Secret name. May be any valid Kubernetes secret name. Required.
name: k10-s3-secret
# Secret namespace. Required. Must be namespace where K10 is installed
namespace: kasten-io
# Standard Kubernetes secret type. Must be Opaque. Required.
type: secrets.kanister.io/aws
# Secret data payload. Required.
data:
# Base64 encoded value for key with proper permissions for the bucket
aws_access_key_id: QUtJQUlPU0ZPRE5ON0VYQU1QTEUK
# Base64 encoded value for the secret corresponding to the key above
aws_secret_access_key: d0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWQo=
# (optional field) Base64 encoded value for AWS IAM role
role: YXJuOmF3czppYW06OjAwMDAwMDAwMDAwMDpyb2xlL2Zha2Utcm9sZQo=
Alternatively, the secret can be created using kubectl as follows.
$ kubectl create secret generic k10-s3-secret \
--namespace kasten-io \
--type secrets.kanister.io/aws \
--from-literal=aws_access_key_id=AKIAIOSFODNN7EXAMPLE \
--from-literal=aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
GCS Bucket Secret
When a Profile is using a GCS Storage bucket location the credential secret must follow the format below.
# Standard Kubernetes API Version declaration. Required.
apiVersion: v1
# Standard Kubernetes Kind declaration. Required.
kind: Secret
# Standard Kubernetes metadata. Required.
metadata:
# Secret name. May be any valid Kubernetes secret name. Required.
name: k10-gcs-secret
# Secret namespace. Required. Must be namespace where K10 is installed
namespace: kasten-io
# Standard Kubernetes secret type. Must be Opaque. Required.
type: Opaque
# Secret data payload. Required.
data:
# Base64 encoded value for project with proper permissions for the bucket
project-id: bXktcHJvamVjdC1pZAo=
# Base64 encoded value for the SA with proper permissions for the bucket
# This value is base64 encoding of the service account json file when
# creating a new service account.
service-account.json: <base64 encoded SA json file>
Alternatively, the secret can be created using kubectl as follows. The example assumes that GCP service account json with the proper permissions for accessing your bucket is in your working directory.
$ kubectl create secret generic k10-gcs-secret \
--namespace kasten-io \
--from-literal=project-id=my-project-id \
--from-file=service-account.json=./gcs-access-service-account.json
Azure Storage Bucket Secret
When a Profile is using an Azure Storage bucket location the credential secret must follow the format below.
# Standard Kubernetes API Version declaration. Required.
apiVersion: v1
# Standard Kubernetes Kind declaration. Required.
kind: Secret
# Standard Kubernetes metadata. Required.
metadata:
# Secret name. May be any valid Kubernetes secret name. Required.
name: k10-azure-secret
# Secret namespace. Required. Must be namespace where K10 is installed
namespace: kasten-io
# Azure Kubernetes secret type. Required.
type: secrets.kanister.io/azure
# Secret data payload. Required.
data:
# Base64 encoded value for account with proper permissions for the bucket
azure_storage_account_id: QUtJQUlPU0ZPRE5ON0VYQU1QTEVBQ0NUCg==
# Base64 encoded value for the key corresponding to the account above
azure_storage_key: d0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWQo=
# Base64 encoded value for the storage enevironment.
# Can be left empty. Acceptable values are AzureCloud, AzureChinaCloud, AzureUSGovernment, AzureGermanCloud
azure_storage_environment: QXp1cmVVU0dvdmVybm1lbnRDbG91ZA==
Alternatively, the secret can be created using kubectl as follows.
$ kubectl create secret generic k10-azure-secret \
--namespace kasten-io \
--type secrets.kanister.io/azure \
--from-literal=azure_storage_account_id=AKIAIOSFODNN7EXAMPLEACCT \
--from-literal=azure_storage_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY \
--from-literal=azure_storage_environment=AzureUSGovernment
Azure Active Directory Secret
When a Profile is using an Azure Active Directory for authentication the credential secret must follow the format below. Please note that an Azure infrastructure profile using default Managed Identity does not need a secret.
# Standard Kubernetes API Version declaration. Required.
apiVersion: v1
# Standard Kubernetes Kind declaration. Required.
kind: Secret
# Standard Kubernetes metadata. Required.
metadata:
# Secret name. May be any valid Kubernetes secret name. Required.
name: k10-azure-secret
# Secret namespace. Required. Must be namespace where K10 is installed
namespace: kasten-io
# Azure Kubernetes secret type. Required.
type: secrets.kanister.io/azure
# Secret data payload. Required.
data:
# Base64 encoded value for the tenant ID of the Azure Active Directory to be used for authentication.
azure_tenant_id: QUtJQUlPU0ZPRE5ON0VYQU1QTEVBQ0NUCg==
# Base64 encoded value for the client id of the identity to be used for authentication.
azure_client_key: MTIzNDU2NzgtMTIzNC0xMjM0LTEyMzQtZXhhbXBsZWNsaWVudGlkCg==
# Base64 encoded value for the client secret corresponding to the client id above.
azure_client_secret: d0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWQo=
Alternatively, the secret can be created using kubectl as follows.
$ kubectl create secret generic k10-azure-secret \
--namespace kasten-io \
--type secrets.kanister.io/azure \
--from-literal=azure_tenant_id=AKIAIOSFODNN7EXAMPLEACCT \
--from-literal=azure_client_key=12345678-1234-1234-1234-exampleclientid \
--from-literal=azure_client_secret=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Ceph KeyRing Secret
When an Infrastructure Profile is being configured for Ceph storage access the credential secret must follow the format below.
# Standard Kubernetes API Version declaration. Required.
apiVersion: v1
# Standard Kubernetes Kind declaration. Required.
kind: Secret
# Standard Kubernetes metadata. Required.
metadata:
# Secret name. May be any valid Kubernetes secret name. Required.
name: k10-ceph-infra-secret
# Secret namespace. Required. Must be namespace where K10 is installed
namespace: kasten-io
# Standard Kubernetes secret type. Must be Opaque. Required.
type: Opaque
# Secret data payload. Required.
data:
# Base64 encoded value for the client.user to be used with the Ceph provider
# The value should not include the 'client' portion of the user name.
ceph_user: Y2VwaC11c2VyCg==
# Base64 encoded value for the (already base64 encoded) keyring file to be used
# with the user.
ceph_keyring: <base64 encoded key ring file>
Alternatively, the secret can be created using kubectl as follows.
$ kubectl create secret generic k10-ceph-secret \
--namespace kasten-io \
--from-literal=ceph_user=sample-ceph-user \
--from-file=ceph_keyring=./my-ceph-client.keyring
OpenStack Account Secret
When an Infrastructure Profile is being configured for accessing storage that support the Open Stack Cinder interface the credential secret must follow the format below.
# Standard Kubernetes API Version declaration. Required.
apiVersion: v1
# Standard Kubernetes Kind declaration. Required.
kind: Secret
# Standard Kubernetes metadata. Required.
metadata:
# Secret name. May be any valid Kubernetes secret name. Required.
name: k10-openstack-infra-secret
# Secret namespace. Required. Must be namespace where K10 is installed
namespace: kasten-io
# Standard Kubernetes secret type. Must be Opaque. Required.
type: Opaque
# Secret data payload. Required.
data:
# Base64 encoded value for an OpenStack user name to use with provider
os_username: b3MtdXNlcm5hbWUK
# Base64 encoded OpenStack password
os_password: b3MtcGFzc3dvcmQK
# Base64 encoded OpenStack domain
os_domain: b3MtZG9tYWluCg==
# Base64 encoded OpenStack project
os_project: b3MtcHJvamVjdAo=
# Base64 encoded OpenStack region
os_region: b3MtcmVnaW9u
Alternatively, the secret can be created using kubectl as follows.
$ kubectl create secret generic k10-openstack-secret \
--namespace kasten-io \
--from-literal=os_username=my-os-username \
--from-literal=os_password=my-os-password-user \
--from-literal=os_domain=my-os-domain \
--from-literal=os_project=my-os-project
Portworx Key Secret
When an Infrastructure Profile is being configured for accessing storage that supports the Portworx interface, the credential secret must follow the format below.
# Standard Kubernetes API Version declaration. Required.
apiVersion: v1
# Standard Kubernetes Kind declaration. Required.
kind: Secret
# Standard Kubernetes metadata. Required.
metadata:
# Secret name. May be any valid Kubernetes secret name. Required.
name: k10-portworx-infra-secret
# Secret namespace. Required. Must be namespace where K10 is installed
namespace: kasten-io
# Standard Kubernetes secret type. Must be Opaque. Required.
type: Opaque
# Secret data payload. Required.
data:
# Base64 encoded value for a Portworx jwt issuer.
pwx_issuer: cHd4X2lzc3Vlcg==
# Base64 encoded value for a Portworx jwt secret.
pwx_secret: cHd4X3NlY3JldA==
Alternatively, the secret can be created using kubectl as follows.
$ kubectl create secret generic k10-portworx-infra-secret \
--namespace kasten-io \
--from-literal=pwx_issuer=my-pwx-issuer \
--from-file=pwx_secret=my-pwx-secret
vSphere Key Secret
When a vSphere Infrastructure Profile is being configured the credential secret must follow the format below.
# Standard Kubernetes API Version declaration. Required.
apiVersion: v1
# Standard Kubernetes Kind declaration. Required.
kind: Secret
# Standard Kubernetes metadata. Required.
metadata:
# Secret name. May be any valid Kubernetes secret name. Required.
name: k10-vsphere-infra-secret
# Secret namespace. Required. Must be namespace where K10 is installed
namespace: kasten-io
# Standard Kubernetes secret type. Must be Opaque. Required.
type: Opaque
# Secret data payload. Required.
data:
# Base64 encoded value for a vSphere user.
vsphere_user: dnNwaGVyZV91c2Vy
# Base64 encoded value for a vSphere password.
vsphere_password: dnNwaGVyZV9wYXNzd29yZA==
Alternatively, the secret can be created using kubectl as follows.
$ kubectl create secret generic k10-vsphere-infra-secret \
--namespace kasten-io \
--from-literal=vsphere_user=my-vsphere-user \
--from-file=vsphere_password=my-vsphere-password
Veeam Repository Secret
A Veeam Repository Location Profile requires a credential secret in the format below.
# Standard Kubernetes API Version declaration. Required.
apiVersion: v1
# Standard Kubernetes Kind declaration. Required.
kind: Secret
# Standard Kubernetes metadata. Required.
metadata:
# Secret name. May be any valid Kubernetes secret name. Required.
name: k10-vbr-secret
# Secret namespace. Required. Must be the namespace where K10 is installed
namespace: kasten-io
# Standard Kubernetes secret type. Must be Opaque. Required.
type: Opaque
# Secret data payload. Required.
data:
# Base64 encoded value for the Veeam server account name.
vbr_user: QWRtaW5pc3RyYXRvcg==
# Base64 encoded value for the password.
vbr_password: UEFTU1dPUkQ=
Alternatively, the secret can be created using kubectl as follows:
$ kubectl create secret generic k10-vbr-secret \
--namespace kasten-io \
--from-literal=vbr_user=Administrator \
--from-literal=vbr_password=PASSWORD