Configuring access using `vaulttenantsa`

Configure Key Management System (KMS) using vaulttenantsa, allowing users to use serviceaccounts to authenticate with Vault.

Before you begin

The Fusion Data Foundation cluster is in Ready state.
On the external key management system (KMS):
- Ensure that a policy exists and the key value backend path in Vault is enabled.
- Ensure that you are using signed certificates on your Vault servers.

Create the following serviceaccount in the tenant namespace as shown below:

$ cat <<EOF | oc create -f -
apiVersion: v1
kind: ServiceAccount
metadata:
    name: ceph-csi-vault-sa
EOF

About this task

Configure the Kubernetes authentication method before Fusion Data Foundation can authenticate with and start using Vault. These instructions create and configure serviceAccount, ClusterRole, and ClusterRoleBinding required to allow Fusion Data Foundation to authenticate with Vault.

Procedure

Apply the following YAML to your OpenShift cluster:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: rbd-csi-vault-token-review
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: rbd-csi-vault-token-review
rules:
  - apiGroups: ["authentication.k8s.io"]
    resources: ["tokenreviews"]
    verbs: ["create", "get", "list"]

---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: rbd-csi-vault-token-review
subjects:
  - kind: ServiceAccount
    name: rbd-csi-vault-token-review
    namespace: openshift-storage
roleRef:
  kind: ClusterRole
  name: rbd-csi-vault-token-review
  apiGroup: rbac.authorization.k8s.io

Create a secret for serviceaccount token and CA certificate.

$ cat <<EOF | oc create -f -
apiVersion: v1
kind: Secret
metadata:
  name: rbd-csi-vault-token-review-token
  namespace: openshift-storage
  annotations:
    kubernetes.io/service-account.name: "rbd-csi-vault-token-review"
type: kubernetes.io/service-account-token
data: {}
EOF

Get the token and the CA certificate from the secret.

$ SA_JWT_TOKEN=$(oc -n openshift-storage get secret rbd-csi-vault-token-review-token -o jsonpath="{.data['token']}" | base64 --decode; echo)
$ SA_CA_CRT=$(oc -n openshift-storage get secret rbd-csi-vault-token-review-token -o jsonpath="{.data['ca\.crt']}" | base64 --decode; echo)

Retrieve the Fusion Data Foundation cluster endpoint.

OCP_HOST=$(oc config view --minify --flatten -o jsonpath="{.clusters[0].cluster.server}")

Use the information collected in the previous steps to set up the Kubernetes authentication method in Vault as shown:

$ vault auth enable kubernetes
$ vault write auth/kubernetes/config \
          token_reviewer_jwt="$SA_JWT_TOKEN" \
          kubernetes_host="$OCP_HOST" \
          kubernetes_ca_cert="$SA_CA_CRT"

Create a role in Vault for the tenant namespace.
```
$ vault write "auth/kubernetes/role/csi-kubernetes" bound_service_account_names="ceph-csi-vault-sa" bound_service_account_namespaces=<tenant_namespace> policies=<policy_name_in_vault>
```
csi-kubernetes is the default role name that Fusion Data Foundation looks for in Vault. The default service account name in the tenant namespace in the Fusion Data Foundation cluster is ceph-csi-vault-sa. These default values can be overridden by creating a ConfigMap in the tenant namespace.

For more information about overriding the default names, see Overriding Vault connection details using tenant ConfigMap.

Example

Use this sample YAML to update or create the csi-kms-connection-detail ConfigMap, using Table 1 to configure the file.

To create a StorageClass that uses the vaulttenantsa method for PV encryption, you must either edit the existing ConfigMap or create a ConfigMap named csi-kms-connection-details that will hold all the information needed to establish the connection with Vault.

apiVersion: v1
data:
  vault-tenant-sa: |-
    {
      "encryptionKMSType": "vaulttenantsa",
      "vaultAddress": "<https://hostname_or_ip_of_vault_server:port>",
      "vaultTLSServerName": "<vault TLS server name>",
      "vaultAuthPath": "/v1/auth/kubernetes/login",
      "vaultAuthNamespace": "<vault auth namespace name>"
      "vaultNamespace": "<vault namespace name>",
      "vaultBackendPath": "<vault backend path name>",
      "vaultCAFromSecret": "<secret containing CA cert>",
      "vaultClientCertFromSecret": "<secret containing client cert>",
      "vaultClientCertKeyFromSecret": "<secret containing client private key>",
      "tenantSAName": "<service account name in the tenant namespace>"
    }
metadata:
  name: csi-kms-connection-details

Table 1. YAML values and descriptions
Value	Description
`encryptionKMSType`	Set to `vaulttenantsa` to use service accounts for authentication with vault.
`vaultAddress`	The hostname or IP address of the vault server with the port number.
`vaultTLSServerName`	(Optional) The vault TLS server name.
`vaultAuthPath`	(Optional) The path where Kubernetes auth method is enabled in Vault. The default path is kubernetes. If the auth method is enabled in a different path other than kubernetes, this variable needs to be set as "/v1/auth/<path>/login".
`vaultAuthNamespace`	(Optional) The Vault namespace where Kubernetes auth method is enabled.
`vaultNamespace`	(Optional) The Vault namespace where the backend path being used to store the keys exists.
`vaultBackendPath`	The backend path in Vault where the encryption keys will be stored.
`vaultCAFromSecret`	The secret in the Fusion Data Foundation cluster containing the CA certificate from Vault.
`vaultClientCertFromSecret`	The secret in the Fusion Data Foundation cluster containing the client certificate from Vault.
`vaultClientCertKeyFromSecret`	The secret in the Fusion Data Foundation cluster containing the client private key from Vault.
`tenantSAName`	(Optional) The service account name in the tenant namespace. The default value is `ceph-csi-vault-sa`. If a different name is to be used, this variable has to be set accordingly.