diff --git a/content/docs/authorization/v2.0 Tech Preview/_index.md b/content/docs/authorization/v2.0 Tech Preview/_index.md index 895f5e024a..2da76696a7 100644 --- a/content/docs/authorization/v2.0 Tech Preview/_index.md +++ b/content/docs/authorization/v2.0 Tech Preview/_index.md @@ -4,7 +4,7 @@ linktitle: v2.0 Tech Preview weight: 4 Description: > Dell Technologies (Dell) Container Storage Modules (CSM) for Authorization v2.0 Tech Preview. -tags: +tags: - csm-authorization --- @@ -14,7 +14,7 @@ tags: The following diagram shows a high-level overview of CSM for Authorization with a `tenant-app` that is using a CSI driver to perform storage operations through the CSM for Authorization `proxy-server` to access the a Dell storage system. All requests from the CSI driver will contain the token for the given tenant that was granted by the Storage Administrator. -![HA CSM Authorization](authorization-ha-example.png) +![Alt text](image.png) This is the introduction to a Stateless Architecture for Authorization. The creation of storage, roles, and tenants is done through Custom Resources (CRs) which are tracked and contained within CSM Authorization. The underlying communication is consistent with the previous architecture which makes the creation of volumes and snapshots seamless. @@ -22,13 +22,38 @@ This is the introduction to a Stateless Architecture for Authorization. The crea {{}} | Feature | PowerFlex | PowerMax | PowerScale | | ----------------------------------------------------------------------------------------------------------------------------- | --------- | -------- | ---------- | -| Ability to set storage quota limits to ensure k8s tenants are not overconsuming storage | Yes | Yes | No | -| Ability to create access control policies to ensure k8s tenant clusters are not accessing storage that does not belong to them | Yes | Yes | No | +| Ability to set storage quota limits to ensure k8s tenants are not overconsuming storage | Yes | No | No | +| Ability to create access control policies to ensure k8s tenant clusters are not accessing storage that does not belong to them | Yes | No | No | | Ability to shield storage credentials from Kubernetes administrators by storing them in vault | Yes | No | No | | Ability to create snapshots from owned volumes that consume the storage quota | Yes | No | No | | Ability to periodically query storage array to keep quota consumption in sync | Yes | No | No | {{
}} +### Snapshot Support + +As stated above, all snapshot requests that are associated with a volume that has been approved and created will go through a similar authorization processes ensuring that the snapshot fits within the allotted quota. + +```yaml +apiVersion: snapshot.storage.k8s.io/v1 +kind: VolumeSnapshot +metadata: + name: vol1-snapshot +spec: + volumeSnapshotClassName: vxflexos-snapclass + source: + persistentVolumeClaimName: vol1 +``` + +This will take a snapshot of the `persistent volume claim` named `vol1`. CSM Authorization will verify ownership with Redis to ensure that the tenant who is attempting to create the snapshot owns the `vol1` volume. If the tenant does own the volume, authorization will proceed to check to see if the snapshot fits within the allotted quota and add a record if it does. + +### Backend Storage Polling + +A configurable polling mechanism has been introduced to ensure that the tenant and Redis are always in sync with the backend storage configured. This is determined by the [volumePrefix](configuration/proxy-server/#configuring-tenants) specified for the `tenant`. During polling, for each of the tenants and roles, the storage service will ensure that nothing has been removed or added by the storage admin which would lead to Redis being out of sync. + +If a volume is created with the matching `volumePrefix`, the new entry will be added to Redis and the available quota will be consumed accordingly. Similarly, if a snapshot is created from a volume that is owned by the tenant in the backend storage array, that will be added to Redis. + +Lastly, if there is any deletion on the backend storage array of a volume or snapshot that is owned by the tenant, that entry will be deleted from Redis and the available capacity will reflect accordingly. + ## Roles and Responsibilities The Stateless CSM Authorization contains the following roles: diff --git a/content/docs/authorization/v2.0 Tech Preview/configuration/proxy-server/_index.md b/content/docs/authorization/v2.0 Tech Preview/configuration/proxy-server/_index.md index 3cb168e297..934dd61d3a 100644 --- a/content/docs/authorization/v2.0 Tech Preview/configuration/proxy-server/_index.md +++ b/content/docs/authorization/v2.0 Tech Preview/configuration/proxy-server/_index.md @@ -128,8 +128,20 @@ spec: Once the tenant is created, an access/refresh token pair can be created for the tenant. The storage admin is responsible for generating and sending the token to the Kubernetes tenant admin. +Generate an administrator token: + +```bash +dellctl admin token -n --access-token-expiration 1m30s --refresh-token-expiration 720h --jwt-signing-secret > admin.yaml +``` + +You can also pass in the `jwt-signing-secret` via terminal prompt by not supplying the `--jwt-signing-secret` argument: + +```bash +dellctl admin token -n --access-token-expiration 1m30s --refresh-token-expiration 720h > admin.yaml +``` + ```bash - dellctl generate token --addr csm-authorization.com: --insecure true --tenant --access-token-expiration 30m0s --refresh-token-expiration 1480h0m0s > token.yaml + dellctl generate token --admin-token admin.yaml --addr csm-authorization.com: --insecure true --tenant --access-token-expiration 30m0s --refresh-token-expiration 1480h0m0s > token.yaml ``` `token.yaml` will have a Kubernetes secret manifest that looks like this: diff --git a/content/docs/authorization/v2.0 Tech Preview/image.png b/content/docs/authorization/v2.0 Tech Preview/image.png new file mode 100644 index 0000000000..d21d835580 Binary files /dev/null and b/content/docs/authorization/v2.0 Tech Preview/image.png differ diff --git a/content/docs/authorization/v2.0 Tech Preview/use_cases.md b/content/docs/authorization/v2.0 Tech Preview/use_cases.md deleted file mode 100644 index ae46846183..0000000000 --- a/content/docs/authorization/v2.0 Tech Preview/use_cases.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: Use Cases -linktitle: Use Cases -weight: 1 -description: > - Use cases for Stateless Authorization ---- - -After Authorization is installed and the PowerFlex driver has been configured with a valid tenant, similar to the the previous architecture, all volume creations will be verified to ensure that the volume fits within the tenants quota. In addition, the support of snapshots is introduced within this version of Authorization. This means that all snapshots created from a volume from the tenant will go through similar verification. - -## Snapshot Support - -As stated above, all snapshot requests that are associated with a volume that has been approved and created will go through a similar authorization processes ensuring that the snapshot fits within the allotted quota. - -```yaml -apiVersion: snapshot.storage.k8s.io/v1 -kind: VolumeSnapshot -metadata: - name: vol1-snapshot -spec: - volumeSnapshotClassName: vxflexos-snapclass - source: - persistentVolumeClaimName: vol1 -``` - -This will take a snapshot of the `persistent volume claim` named `vol1`. CSM Authorization will verify ownership with Redis to ensure that the tenant who is attempting to create the snapshot owns the `vol1` volume. If the tenant does own the volume, authorization will proceed to check to see if the snapshot fits within the allotted quota and add a record if it does. - -## Backend Storage Polling - -A configurable polling mechanism has been introduced to ensure that the tenant and Redis are always in sync with the backend storage configured. This is determined by the [volumePrefix](../configuration/proxy-server/#configuring-tenants) specified for the `tenant`. During polling, for each of the tenants and roles, the storage service will ensure that nothing has been removed or added by the storage admin which would lead to Redis being out of sync. - -If a volume is created with the matching `volumePrefix`, the new entry will be added to Redis and the available quota will be consumed accordingly. Similarly, if a snapshot is created from a volume that is owned by the tenant in the backend storage array, that will be added to Redis. - -Lastly, if there is any deletion on the backend storage array of a volume or snapshot that is owned by the tenant, that entry will be deleted from Redis and the available capacity will reflect accordingly. \ No newline at end of file diff --git a/content/docs/deployment/csmoperator/modules/authorization v2.0 Tech Preview.md b/content/docs/deployment/csmoperator/modules/authorization v2.0 Tech Preview.md new file mode 100644 index 0000000000..bb150e731b --- /dev/null +++ b/content/docs/deployment/csmoperator/modules/authorization v2.0 Tech Preview.md @@ -0,0 +1,366 @@ +--- +title: Authorization v2.0 Tech Preview +linkTitle: "Authorization v2.0 Tech Preview" +description: > + Installing Authorization v2.0 Tech Preview via Dell CSM Operator +--- + +{{% pageinfo color="primary" %}} +The CSM Authorization karavictl CLI is no longer actively maintained or supported. It will be deprecated in CSM 2.0. +{{% /pageinfo %}} + +## Install CSM Authorization via Dell CSM Operator + +The CSM Authorization module for supported Dell CSI Drivers can be installed via the Dell CSM Operator. +To deploy the Operator, follow the instructions available [here](../../#installation). + +### Prerequisite + +1. [Install Vault or configure an existing Vault](#vault-server-installation). + +2. Execute `kubectl create namespace authorization` to create the authorization namespace (if not already present). Note that the namespace can be any user-defined name, in this example, we assume that the namespace is 'authorization'. + +3. Install cert-manager CRDs + ```bash + kubectl apply --validate=false -f /~https://github.com/jetstack/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml + ``` + +4. Prepare [samples/authorization/config.yaml](/~https://github.com/dell/csm-operator/blob/main/samples/authorization/config.yaml) which contains the JWT signing secret. The following table lists the configuration parameters. + + | Parameter | Description | Required | Default | + | --------- | ------------------------------------------------------------ | -------- | ------- | + | web.jwtsigningsecret | String used to sign JSON Web Tokens | true | secret |. + + Example: + + ```yaml + web: + jwtsigningsecret: randomString123 + ``` + + After editing the file, run this command to create a secret called `karavi-config-secret`: + + ```bash + + kubectl create secret generic karavi-config-secret -n authorization --from-file=config.yaml=samples/authorization/config.yaml + ``` + + Use this command to replace or update the secret: + + ```bash + + kubectl create secret generic karavi-config-secret -n authorization --from-file=config.yaml=samples/authorization/config.yaml -o yaml --dry-run=client | kubectl replace -f - + ``` + + +>__Note__: +> - If you are installing CSM Authorization in a different namespace than `authorization`, edit the `namespace` field in this file to your namespace. + + +### Install CSM Authorization Proxy Server + +1. Follow all the [prerequisites](#prerequisite). + +2. Create a CR (Custom Resource) for Authorization from a [sample manifest](/~https://github.com/dell/csm-operator/blob/main/samples/authorization/csm_authorization_proxy_server_v200-alpha.yaml). This file can be modified to use custom parameters if needed. + +3. Users should configure the parameters in the CR. This table lists the primary configurable parameters of the Authorization Proxy Server and their default values: + + | Parameter | Description | Required | Default | + | --------- | ----------- | -------- |-------- | + | **nginx** | This section configures the enablement of the NGINX Ingress Controller. | - | - | + | enabled | For Kubernetes Container Platform only: Enable/Disable deployment of the NGINX Ingress Controller. Set to false if you already have an Ingress Controller installed. | No | true | + | **cert-manager** | This section configures the enablement of cert-manager. | - | - | + | enabled | Enable/Disable deployment of cert-manager. Set to false if you already have cert-manager installed. | No | true | + | **authorization** | This section configures the CSM-Authorization components. | - | - | + | certificate | The base64-encoded certificate for the certificate/private-key to configure the proxy-service Ingress. Leave empty to use self-signed certificate. | No | - | + | privateKey | The base64-encoded private key for the certificate/private-key to configure the proxy-service Ingress. Leave empty to use self-signed certificate. | No | - | + | hostname | The hostname to configure the self-signed certificate (if applicable), and the proxy service Ingress. | No | csm-authorization.com | + | proxyServerIngress.ingressClassName | The ingressClassName of the proxy-service Ingress. | Yes | nginx | + | proxyServerIngress.hosts | Additional host rules to be applied to the proxy-service Ingress. | No | - | + | proxyServerIngress.annotations | Additional annotations for the proxy-service Ingress. | No | - | + | **redis** | This section configures the Redis components. | - | - | + | storageclass | The storage class for Redis to use for persistence. If not supplied, a locally provisioned volume is used. | No | - | + + **Additional v2.0 Technical Preview Parameters:** + | Parameter | Description | Required | Default | + | --------- | ----------- | -------- |-------- | + | **redis** | This section configures the Redis components. | - | - | + | redisName | The prefix of the redis pods. The number of pods is determined by the number of replicas. | Yes | redis-csm | + | redisCommander | The prefix of the redis commander pod. | Yes | rediscommander | + | sentinel | The prefix of the redis sentinel pods. The number of pods is determined by the number of replicas. | Yes | sentinel | + | redisReplicas | The number of replicas for the sentinel and redis pods. | Yes | 5 | + | storageclass | The storage class for Redis to use for persistence. If not supplied, a locally provisioned volume is used. | No | - | + | **vault** | This section configures the vault components. | - | - | + | vaultAddress | The address where vault is hosted with the credentials to the array (`https://10.0.0.1:`). | Yes | - | + | vaultRole | The configured authentication role in vault. | Yes | csm-authorization | + | kvEnginePath | The vault path where the credentials are stored. | Yes | secret | + | certificate | The base64-encoded certificate for the certificate/private-key pair to connect to Vault. Leave empty to use self-signed certificate. | No | - | + | privateKey | The base64-encoded private key for the certificate/private-key pair to connect to Vault. Leave empty to use self-signed certificate. | No | - | + | certificateAuthority | The base64-encoded certificate authority for validating the Vault server. | No | - | + +>__Note__: +> - If you are installing CSM Authorization in a different namespace than `authorization`, edit the `namespace` fields in this file to your namespace. +> - If you specify `storageclass`, the storage class must NOT be provisioned by the Dell CSI Driver to be configured with this installation of CSM Authorization. + +**Optional:** +To enable reporting of trace data with [Zipkin](https://zipkin.io/), use the `csm-config-params` configMap in the sample CR or dynamically by editing the configMap. + + Add the Zipkin values to the configMap where `ZIPKIN_ADDRESS` is the IP address or hostname of the Zipkin server. + ```bash + ZIPKIN_URI: "http://ZIPKIN_ADDRESS:9411/api/v2/spans" + ZIPKIN_PROBABILITY: "1.0" + ``` + +4. Execute this command to create the Authorization CR: + + ```bash + + kubectl create -f + ``` + + >__Note__: + > - This command will deploy the Authorization Proxy Server in the namespace specified in the input YAML file. + +### Verify Installation of the CSM Authorization Proxy Server +Once the Authorization CR is created, you can verify the installation as mentioned below: + + ```bash + kubectl describe csm/ -n authorization + ``` + +### Install dellctl + +Follow the instructions for [Installing dellctl](../../../../support/cli/#installation-instructions). + +### Configure the CSM Authorization Proxy Server + +Follow the instructions available in CSM Authorization for [Configuring the CSM Authorization Proxy Server](../../../../authorization/v2.0-tech-preview/configuration/proxy-server/). + +### Configure a Dell CSI Driver with CSM Authorization + +Follow the instructions available in CSM Authorization for [Configuring PowerFlex with Authorization](../../../../authorization/v2.0-tech-preview/configuration/powerflex). + +## Vault Server Installation + +If there is already a Vault server available, skip to [Minimum Server Configuration](#minimum-server-configuration). + +If there is no Vault server available to use with CSM Authorization, it can be installed in many ways following [Hashicorp Vault documentation](https://www.vaultproject.io/docs). + +For testing environment, however, a simple deployment suggested in this section may suffice. +It creates a standalone server with in-memory (non-persistent) storage, running in a Docker container. + +> **NOTE**: With in-memory storage, the data in Vault is permanently destroyed upon the server's termination. + +### Generate TLS certificates for server and client + +Create server CA private key and certificate: + +```shell +openssl req -x509 -sha256 -days 365 -newkey rsa:2048 -nodes \ + -subj "/CN=Vault Root CA" \ + -keyout server-ca.key \ + -out server-ca.crt +``` + +Create server private key and CSR: + +```shell +openssl req -newkey rsa:2048 -nodes \ + -subj "/CN=vault-demo-server" \ + -keyout server.key \ + -out server.csr +``` + +Create server certificate signed by the CA: + +> Replace `` with an IP address by which CSM Authorization can reach the Vault server. +This may be the address of the Docker host where the Vault server will be running. + +```shell +cat > cert.ext < +EOF + +openssl x509 -req \ + -CA server-ca.crt -CAkey server-ca.key \ + -in server.csr \ + -out server.crt \ + -days 365 \ + -extfile cert.ext \ + -CAcreateserial + +cat server-ca.crt >> server.crt +``` + +Create client CA private key and certificate: + +```shell +openssl req -x509 -sha256 -days 365 -newkey rsa:2048 -nodes \ + -subj "/CN=Client Root CA" \ + -keyout client-ca.key \ + -out client-ca.crt +``` + +Create client private key and CSR: + +```shell +openssl req -newkey rsa:2048 -nodes \ + -subj "/CN=vault-client" \ + -keyout client.key \ + -out client.csr +``` + +Create client certificate signed by the CA: +// todo check ip? +```shell +cat > cert.ext <> client.crt +``` + +### Create server hcl file + +```shell +cat >server.hcl < Variable `CONF_DIR` below refers to the directory containing files *server.crt*, *server.key*, *client-ca.crt* and *server.hcl*. +```shell +VOL_DIR="$CONF_DIR" +VOL_DIR_D="/var/vault" +ROOT_TOKEN="DemoRootToken" +VAULT_IMG="vault:1.13.3" + +docker run --rm -d \ + --name="vault-server" \ + -p 8200:8200 -p 8400:8400 \ + -v $VOL_DIR:$VOL_DIR_D -w $VOL_DIR_D \ + -e VAULT_DEV_ROOT_TOKEN_ID=$ROOT_TOKEN \ + -e VAULT_ADDR="http://127.0.0.1:8200" \ + -e VAULT_TOKEN=$ROOT_TOKEN \ + $VAULT_IMG \ + sh -c 'vault server -dev -dev-listen-address 0.0.0.0:8200 -config=server.hcl' +``` + +## Minimum Server Configuration + +> **NOTE:** this configuration is a bare minimum to support CSM Authorization and is not intended for use in production environment. +Refer to the [Hashicorp Vault documentation](https://www.vaultproject.io/docs) for recommended configuration options. + +> If a [test instance of Vault](#vault-server-installation) is used, the `vault` commands below can be executed in the Vault server container shell. +> To enter the shell, run `docker exec -it vault-server sh`. After completing the configuration process, exit the shell by typing `exit`. +> +> Alternatively, you can [download the vault binary](https://www.vaultproject.io/downloads) and run it anywhere. +> It will require two environment variables to communicate with the Vault server: +> - `VAULT_ADDR` - URL similar to `http://127.0.0.1:8200`. You may need to change the address in the URL to the address of +the Docker host where the server is running. +> - `VAULT_TOKEN` - Authentication token, e.g. the root token `DemoRootToken` used in the [test instance of Vault](#vault-server-installation). + +### Enable Key/Value secret engine + +```shell +vault secrets enable -version=2 -path=csm-authorization/ kv +``` + +Key/Value secret engine is used to store array credentials. + +### Enable Kubernetes authentication + +```shell +vault auth enable kubernetes +``` + +### Configure Kubernetes authentication + +```shell +vault write auth/kubernetes/config kubernetes_host="$KUBERNETES_HOST" kubernetes_ca_cert="$KUBERNETES_CA_CERT" +``` + +### Create a policy + +```shell +vault policy write csm-authorization - <__Note__: > - If you are installing CSM Authorization in a different namespace than `authorization`, edit the `namespace` field in this file to your namespace. -> - Authorization v2.0 Tech Preview does not need the creation of the `karavi-storage-secret`. ### Install CSM Authorization Proxy Server 1. Follow all the [prerequisites](#prerequisite). -2. Create a CR (Custom Resource) for Authorization from a [sample manifest](/~https://github.com/dell/csm-operator/tree/main/samples/authorization). This file can be modified to use custom parameters if needed. +2. Create a CR (Custom Resource) for Authorization from a [sample manifest](/~https://github.com/dell/csm-operator/blob/main/samples/authorization/csm_authorization_proxy_server_v1110.yaml). This file can be modified to use custom parameters if needed. 3. Users should configure the parameters in the CR. This table lists the primary configurable parameters of the Authorization Proxy Server and their default values: @@ -90,22 +87,6 @@ To deploy the Operator, follow the instructions available [here](../../#installa | **redis** | This section configures the Redis components. | - | - | | storageclass | The storage class for Redis to use for persistence. If not supplied, a locally provisioned volume is used. | No | - | - **Additional v2.0 Technical Preview Parameters:** - | Parameter | Description | Required | Default | - | --------- | ----------- | -------- |-------- | - | **redis** | This section configures the Redis components. | - | - | - | redisName | The prefix of the redis pods. The number of pods is determined by the number of replicas. | Yes | redis-csm | - | redisCommander | The prefix of the redis commander pod. | Yes | rediscommander | - | sentinel | The prefix of the redis sentinel pods. The number of pods is determined by the number of replicas. | Yes | sentinel | - | redisReplicas | The number of replicas for the sentinel and redis pods. | Yes | 5 | - | storageclass | The storage class for Redis to use for persistence. If not supplied, a locally provisioned volume is used. | No | - | - | **vault** | This section configures the vault components. | - | - | - | vaultAddress | The address where vault is hosted with the credentials to the array (`https://10.0.0.1:`). | Yes | - | - | vaultRole | The configured authentication role in vault. | Yes | csm-authorization | - | kvEnginePath | The vault path where the credentials are stored. | Yes | secret | - | certificate | The base64-encoded certificate for the certificate/private-key pair to connect to Vault. Leave empty to use self-signed certificate. | No | - | - | privateKey | The base64-encoded private key for the certificate/private-key pair to connect to Vault. Leave empty to use self-signed certificate. | No | - | - | certificateAuthority | The base64-encoded certificate authority for validating the Vault server. | No | - | >__Note__: > - If you are installing CSM Authorization in a different namespace than `authorization`, edit the `namespace` fields in this file to your namespace. @@ -139,8 +120,6 @@ Once the Authorization CR is created, you can verify the installation as mention ### Install Karavictl ->> NOTE: Authorization v2.0 Tech Preview does not use `karavictl` so installation is not necessary. - Follow the instructions available in CSM Authorization for [Installing karavictl](../../../helm/modules/installation/authorization/#install-karavictl). ### Configure the CSM Authorization Proxy Server @@ -149,9 +128,6 @@ Follow the instructions available in CSM Authorization for [Installing karavictl Follow the instructions available in CSM Authorization for [Configuring the CSM Authorization Proxy Server](../../../helm/modules/installation/authorization/#configuring-the-csm-authorization-proxy-server). -**Authorization v2.0 Technical Preview** - -Follow the instructions available in CSM Authorization for [Configuring the CSM Authorization Proxy Server](../../../../authorization/v2.0-tech-preview/configuration/proxy-server/). ### Configure a Dell CSI Driver with CSM Authorization @@ -232,231 +208,4 @@ This section outlines the upgrade steps for Container Storage Modules (CSM) for >NOTE: - In Authorization module upgrade, only `n-1` to `n` upgrade is supported, e.g. if the current observability version is `v1.8.x`, it can be upgraded to `1.9.x`. -**Authorization v2.0 Technical Preview** - -Follow the instructions available in CSM Authorization for [Configuring PowerFlex with Authorization](../../../../authorization/v2.0-tech-preview/configuration/powerflex). - -## Vault Server Installation - -If there is already a Vault server available, skip to [Minimum Server Configuration](#minimum-server-configuration). - -If there is no Vault server available to use with CSM Authorization, it can be installed in many ways following [Hashicorp Vault documentation](https://www.vaultproject.io/docs). - -For testing environment, however, a simple deployment suggested in this section may suffice. -It creates a standalone server with in-memory (non-persistent) storage, running in a Docker container. - -> **NOTE**: With in-memory storage, the data in Vault is permanently destroyed upon the server's termination. - -### Generate TLS certificates for server and client - -Create server CA private key and certificate: - -```shell -openssl req -x509 -sha256 -days 365 -newkey rsa:2048 -nodes \ - -subj "/CN=Vault Root CA" \ - -keyout server-ca.key \ - -out server-ca.crt -``` - -Create server private key and CSR: - -```shell -openssl req -newkey rsa:2048 -nodes \ - -subj "/CN=vault-demo-server" \ - -keyout server.key \ - -out server.csr -``` - -Create server certificate signed by the CA: - -> Replace `` with an IP address by which CSM Authorization can reach the Vault server. -This may be the address of the Docker host where the Vault server will be running. - -```shell -cat > cert.ext < -EOF - -openssl x509 -req \ - -CA server-ca.crt -CAkey server-ca.key \ - -in server.csr \ - -out server.crt \ - -days 365 \ - -extfile cert.ext \ - -CAcreateserial - -cat server-ca.crt >> server.crt -``` - -Create client CA private key and certificate: - -```shell -openssl req -x509 -sha256 -days 365 -newkey rsa:2048 -nodes \ - -subj "/CN=Client Root CA" \ - -keyout client-ca.key \ - -out client-ca.crt -``` - -Create client private key and CSR: - -```shell -openssl req -newkey rsa:2048 -nodes \ - -subj "/CN=vault-client" \ - -keyout client.key \ - -out client.csr -``` - -Create client certificate signed by the CA: -// todo check ip? -```shell -cat > cert.ext <> client.crt -``` - -### Create server hcl file - -```shell -cat >server.hcl < Variable `CONF_DIR` below refers to the directory containing files *server.crt*, *server.key*, *client-ca.crt* and *server.hcl*. -```shell -VOL_DIR="$CONF_DIR" -VOL_DIR_D="/var/vault" -ROOT_TOKEN="DemoRootToken" -VAULT_IMG="vault:1.13.3" - -docker run --rm -d \ - --name="vault-server" \ - -p 8200:8200 -p 8400:8400 \ - -v $VOL_DIR:$VOL_DIR_D -w $VOL_DIR_D \ - -e VAULT_DEV_ROOT_TOKEN_ID=$ROOT_TOKEN \ - -e VAULT_ADDR="http://127.0.0.1:8200" \ - -e VAULT_TOKEN=$ROOT_TOKEN \ - $VAULT_IMG \ - sh -c 'vault server -dev -dev-listen-address 0.0.0.0:8200 -config=server.hcl' -``` - -## Minimum Server Configuration - -> **NOTE:** this configuration is a bare minimum to support CSM Authorization and is not intended for use in production environment. -Refer to the [Hashicorp Vault documentation](https://www.vaultproject.io/docs) for recommended configuration options. - -> If a [test instance of Vault](#vault-server-installation) is used, the `vault` commands below can be executed in the Vault server container shell. -> To enter the shell, run `docker exec -it vault-server sh`. After completing the configuration process, exit the shell by typing `exit`. -> -> Alternatively, you can [download the vault binary](https://www.vaultproject.io/downloads) and run it anywhere. -> It will require two environment variables to communicate with the Vault server: -> - `VAULT_ADDR` - URL similar to `http://127.0.0.1:8200`. You may need to change the address in the URL to the address of -the Docker host where the server is running. -> - `VAULT_TOKEN` - Authentication token, e.g. the root token `DemoRootToken` used in the [test instance of Vault](#vault-server-installation). - -### Enable Key/Value secret engine - -```shell -vault secrets enable -version=2 -path=csm-authorization/ kv -``` - -Key/Value secret engine is used to store array credentials. - -### Enable Kubernetes authentication - -```shell -vault auth enable kubernetes -``` - -### Configure Kubernetes authentication - -```shell -vault write auth/kubernetes/config kubernetes_host="$KUBERNETES_HOST" kubernetes_ca_cert="$KUBERNETES_CA_CERT" -``` - -### Create a policy - -```shell -vault policy write csm-authorization - < Selecting too short TTL values will result in excessive overhead in Encryption to remain authenticated to the Vault server. diff --git a/content/docs/support/cli/_index.md b/content/docs/support/cli/_index.md index d2dc3763e0..e384ff1d62 100644 --- a/content/docs/support/cli/_index.md +++ b/content/docs/support/cli/_index.md @@ -32,10 +32,12 @@ This document outlines all dellctl commands, their intended use, options that ca | [dellctl encryption rekey-status](#dellctl-encryption-rekey-status) | Get status of an encryption rekey operation | | [dellctl images](#dellctl-images) | List the container images needed by csi driver | | [dellctl volume get](#dellctl-volume-get) | Gets PowerFlex volume infomation for a given tenant on a local cluster | +| [dellctl admin token](#dellctl-admin-token) | Generate an administrator token for administrating CSM Authorization v2 | +| [dellctl generate token](#dellctl-generate-token) | Generate a tenant token for configuring a Dell CSI Driver with CSM Authorization v2 | ## Installation instructions -1. Download `dellctl` from [here](/~https://github.com/dell/csm/releases/tag/v1.6.0). +1. Download `dellctl` from [here](/~https://github.com/dell/csm/releases/latest/download/dellctl). 2. chmod +x dellctl 3. Move `dellctl` to `/usr/local/bin` or add `dellctl`'s containing directory path to PATH environment variable. 4. Run `dellctl --help` to know available commands or run `dellctl command --help` to know more about a specific command. @@ -970,3 +972,68 @@ k8s-b1abb817d3 a69bf19000000001 8.000000 mypool 636468e3638c840f k8s-b k8s-28e4184f41 c6b2280d0000009a 8.000000 mypool 636468e3638c840f k8s-28e4184f41 Available local-storage k8s-7296621062 a69b554f00000004 8.000000 mypool 636468e3638c840f ``` + +### dellctl admin token + +Generate an administrator token for administrating CSM Authorization v2 + +##### Flags + +``` + --access-token-expiration duration Expiration time of the access token, e.g. 1m30s (default 1m0s) + -h, --help help for token + -s, --jwt-signing-secret string Specify JWT signing secret, or omit to use stdin + -n, --name string Admin name + --refresh-token-expiration duration Expiration time of the refresh token, e.g. 48h (default 720h0m0s) +``` + +##### Output + +```bash +dellctl admin token -n --jwt-signing-secret +``` + +``` +# dellctl admin token -n admin --jwt-signing-secret secret +{ + "Access": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJjc20iLCJleHAiOjE3MjA3MDk1MTcsImdyb3VwIjoiYWRtaW4iLCJpc3MiOiJjb20uZGVsbC5jc20iLCJyb2xlcyI6IiIsInN1YiI6ImNzbS1hZG1pbiJ9.WS5NSxrCoMn90ohOZZyyGoBias583xYumeKvmIrCqSs", + "Refresh": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJjc20iLCJleHAiOjE3MjMzMDE0NTcsImdyb3VwIjoiYWRtaW4iLCJpc3MiOiJjb20uZGVsbC5jc20iLCJyb2xlcyI6IiIsInN1YiI6ImNzbS1hZG1pbiJ9.MJ9ajrB-nLEQKdAA-H8n78kS9QiX1yW_-m7K4Tmu7Mg" +} +``` + +### dellctl generate token + +Generate a tenant token for configuring a Dell CSI Driver with CSM Authorization v2 + +##### Flags + +``` + --access-token-expiration duration Expiration time of the access token, e.g. 1m30s (default 1m0s) + -h, --help help for token + --refresh-token-expiration duration Expiration time of the refresh token, e.g. 48h (default 720h0m0s) + -t, --tenant string Tenant name + +Global Flags: + --addr string Address of the CSM Authorization Proxy Server; required + -f, --admin-token string Path to admin token file; required + --insecure Skip certificate validation of the CSM Authorization Proxy Server +``` + +##### Output + +```bash +dellctl generate token --admin-token --addr --tenant +``` + +``` +# dellctl admin token -n admin --jwt-signing-secret secret +apiVersion: v1 +data: + access: ZXlKaGJHY2lPaUpJVXpJMU5pSXNJblI1Y0NJNklrcFhWQ0o5LmV5SmhkV1FpT2lKamMyMGlMQ0psZUhBaU9qRTJPREl3TVRBeU5UTXNJbWR5YjNWd0lqb2labTl2SWl3aWFYTnpJam9pWTI5dExtUmxiR3d1WTNOdElpd2ljbTlzWlhNaU9pSmlZWElpTENKemRXSWlPaUpqYzIwdGRHVnVZVzUwSW4wLjlSYkJISzJUS2dZbVdDX0paazBoSXV0N0daSDV4NGVjQVk2ekdaUDNvUWs= + refresh: ZXlKaGJHY2lPaUpJVXpJMU5pSXNJblI1Y0NJNklrcFhWQ0o5LmV5SmhkV1FpT2lKamMyMGlMQ0psZUhBaU9qRTJPRFEyTURJeE9UTXNJbWR5YjNWd0lqb2labTl2SWl3aWFYTnpJam9pWTI5dExtUmxiR3d1WTNOdElpd2ljbTlzWlhNaU9pSmlZWElpTENKemRXSWlPaUpqYzIwdGRHVnVZVzUwSW4wLkxQcDQzbXktSVJudTFjdmZRcko4M0pMdTR2NXlWQlRDV2NjWFpfWjROQkU= +kind: Secret +metadata: + creationTimestamp: null + name: proxy-authz-tokens +type: Opaque +```