Configuring a Secret

Kubernetes Secrets enable you to inject sensitive data into a pod. The examples in this section show how Secrets can be used in static and dynamic provisioning. Secrets are not by themselves secure. It is important to turn on encryption at rest for Secrets. See Encrypting Secret Data at Rest. For more information about security and Secrets, see Security Properties.

During installation of the driver, the Kubernetes token that was moved into the pod is written to the host node so that the plugin can query a Secret to pull the ticket for mounting. This Kubernetes token is sensitive and should be protected. The token is placed in /var/run/secrets/kubernetes.io/serviceaccount.

Here is an example of a configuration file for a Kubernetes Secret:
apiVersion: v1
kind: Secret
metadata:
  name: mapr-provisioner-secrets
  namespace: test-driver
type: Opaque
data:
  ...
The following table describes the fields in the sample Secret file. For more information, see Secrets in the Kubernetes documentation.
Parameter Description
apiVersion The Kubernetes API version.
kind The type of object being created.
name A string to identify the Secret.
type The type of Secret being created. For type Opaque, clients must treat these values as opaque and pass them unmodified back to the server.

REST Secrets

For dynamic provisioning, you must use a Secret to pass the user name and password of a Data Fabric user to the provisioner. This user must have privileges to create and delete a Data Fabric volume. The credentials allow the provisioner to make REST calls to the Data Fabric webserver. Secrets are protected by the Kubernetes RBAC.

The following example shows a REST secret in the Secret file:
apiVersion: v1
kind: Secret
metadata:
  name: mapr-provisioner-secrets
  namespace: test-driver
type: Opaque
data:
 MAPR_CLUSTER_USER: cm9vdA==
  MAPR_CLUSTER_PASSWORD: bWFwcg==
The following table describes the REST secret fields in the REST Secret example:
Parameter Description
MAPR_CLUSTER_CLIENTCERT Parameter for specifying the client certificate. You must express the parameter as a base64 representation of the client certificate. See Converting a String to Base64.
MAPR_CLUSTER_CLIENTKEY Parameter for specifying the client key for the client certificate. You must express the parameter as a base64 representation of the client key. See Converting a String to Base64.
MAPR_CLUSTER_USER The base64 representation of a Data Fabric user that has the ability to create and delete Data Fabric volumes. See Converting a String to Base64.
MAPR_CLUSTER_PASSWORD The base64 representation of the password for the user defined by the MAPR_CLUSTER_USER parameter. See Converting a String to Base64
MAPR_CLUSTER_TICKET The base64 representation of the ticket contents generated on the data-fabric cluster using the maprlogin utility. For dynamic provisioning, with the latest CSI drivers, you can configure a data-fabric ticket to authenticate to the data-fabric webserver to make REST calls. This parameter is provided as a Beta feature.
MAPR_CLUSTER_TLSCERT Parameter for providing the CA certificate. If MAPR_CLUSTER_TLSCERT is not specified, the CSI driver uses a nonsecure HTTP connection to the Data Fabric REST servers. You must express the parameter as a base64 representation of the TLS certificate. See Converting a String to Base64.

Ticket Secrets

For static and dynamic provisioning, you must specify a Secret, which is the base64 representation of the ticket, to enable the POSIX client to communicate with a secure Data Fabric cluster. The ticket for the POSIX client can be generated on the Data Fabric cluster by using the maprlogin utility.

The following example shows a ticket Secret:

apiVersion: v1
kind: Secret
metadata:
  name: mapr-ticket-secret
  namespace: mapr-examples
type: Opaque
data:
  CONTAINER_TICKET: CHANGETHIS!
The following table describes the CONTAINER_TICKET field in the ticket Secret example:
Parameter Description
CONTAINER_TICKET Base64-encoded ticket value. See Converting a String to Base64.
Ticket secret specified in CONTAINER_TICKET is used to perform read/write operation on the provisioned volumes. To specify/edit ticket secret, the user must have access to volumes.
Use different types of CONTAINER_TICKET based on the conditions that follow:
  • If a pod user (via Linux or LDAP user) exists on the Data Fabric cluster, and:
    • if both the ticket and pod user have same UserID and GroupID, use service ticket.
    • if the ticket and pod user have different UserID and GroupID, use servicewithimpersonation ticket.
  • If the pod user does not exist in Data Fabric cluster, use tenant ticket of the user that exists on Data Fabric cluster (via Linux or LDAP user). Use UserID and GroupID of the pod user for all operations.
    TIP
    Tenant ticket user can only access the tenant volumes (passing tenantuser in StorageClass) created by the Data Fabric administrator for that user.

To create the secret:

  1. Run the following command to create the Secret file:

    kubectl create -f <secret-file-name>.yaml

  2. Convert sensitive data, such as a user name and password, to a base64 representation.

    See Converting a String to Base64.

  3. Add the base64 representation of sensitive data in the Secret file.

    For more information about the format of the Secret files, see REST Secrets and Ticket Secrets earlier in this section.

  4. Deploy the secret on the pod by running the following command:

    kubectl apply -f <secret-file-name>.yaml