Configuring a Secret

Kubernetes Secrets enable you to inject sensitive data into a pod. For more information about Secrets, see Secrets.

The examples in this section show how Secrets can be used in static and dynamic provisioning. Secrets are not by themselves secure. For more information about security and Secrets, see Security Properties. Specifically, it is important to turn on encryption at rest for Secrets. See Encrypting Secret Data at Rest.

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 Notes
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 MapR user to the provisioner. This user must have privileges to create and delete a MapR volume. The credentials allow the provisioner to make REST calls to the MapR 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 Notes
MAPR_CLUSTER_USER The base64 representation of a MapR user that has the ability to create and delete MapR 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.

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 MapR cluster. The ticket for the POSIX client can be generated on the MapR cluster 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 Notes
CONTAINER_TICKET Base64-encoded ticket value. See Converting a String to Base64.

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