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