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 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	Notes
`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.

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 data-fabric 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:

Run the following command to create the Secret file:
```
kubectl create -f <secret-file-name>.yaml
```
Convert sensitive data, such as a user name and password, to a base64 representation.
See Converting a String to Base64.
Add the base64 representation of sensitive data in the Secret file.
See REST Secrets and Ticket Secrets for more information on the format of the Secret files.
Deploy the secret on the pod by running the following command:
```
kubectl apply -f <secret-file-name>.yaml
```