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
.
apiVersion: v1
kind: Secret
metadata:
name: mapr-provisioner-secrets
namespace: test-driver
type: Opaque
data:
...
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.
apiVersion: v1
kind: Secret
metadata:
name: mapr-provisioner-secrets
namespace: test-driver
type: Opaque
data:
MAPR_CLUSTER_USER: cm9vdA==
MAPR_CLUSTER_PASSWORD: bWFwcg==
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!
CONTAINER_TICKET
field in the ticket
Secret example:Parameter | Description |
---|---|
CONTAINER_TICKET |
Base64-encoded ticket value. See Converting a String to Base64. |
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.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
andGroupID
, useservice
ticket. - if the ticket and pod user have different
UserID
andGroupID
, useservicewithimpersonation
ticket.
- if both the ticket and pod user have same
- 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). UseUserID
andGroupID
of the pod user for all operations.TIPTenant
ticket user can only access the tenant volumes (passingtenantuser
inStorageClass
) created by the Data Fabric administrator for that user.
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.
For more information about the format of the Secret files, see REST Secrets and Ticket Secrets earlier in this section. -
Deploy the secret on the pod by running the following command:
kubectl apply -f <secret-file-name>.yaml