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 initializes and validates properly
$ kubectl get profiles.config.kio.kasten.io --namespace kasten-io -w
NAME STATUS
sample-profile Running
sample-profile Success
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 initializes and validates properly
$ kubectl get profiles.config.kio.kasten.io --namespace kasten-io -w
NAME STATUS
sample-ceph-profile Running
sample-ceph-profile Success
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 initializes and validates properly
$ kubectl get profiles.config.kio.kasten.io --namespace kasten-io -w
NAME STATUS
kanister-profile Running
kanister-profile Success
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 configured
Once the change is submitted, K10 will re-validate the profile and update .status.validation accordingly.
$ kubectl get profiles.config.kio.kasten.io -w
NAME STATUS
sample-profile Running
sample-profile Success
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)
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
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
# 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 or VSphere
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
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
# 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)
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:
# # Pending - profile has been created
# # Running - undergoing initialization and validation
# # 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
# Standard Kubernetes secret type. Must be Opaque. Required.
type: Opaque
# 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=
Alternatively, the secret can be created using kubectl as follows.
$ kubectl create secret generic k10-azure-secret \
--namespace kasten-io \
--from-literal=azure_storage_account_id=AKIAIOSFODNN7EXAMPLEACCT \
--from-literal=azure_storage_key=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