diff --git a/content/docs/authorization/Migration guide from v1 to v2/_index.md b/content/docs/authorization/Migration guide from v1 to v2/_index.md new file mode 100644 index 0000000000..5d489e2820 --- /dev/null +++ b/content/docs/authorization/Migration guide from v1 to v2/_index.md @@ -0,0 +1,175 @@ +--- +title: Authorization - v2 Migration guide +linktitle: Migration guide from v1 to v2 +weight: 1 +description: > + CSM for Authorization v1 to v2 Migration guide +--- + +CSM for Authorization v2 has significant architectural changes that prevent a user from upgradng CSM for Authorization v1 to CSM for Authorization v2. This page provides a reference guide for migrating v1 to v2. + +**Before migration please note following points** + - CSM for Authorization v2 calculates the actual usage of capacity provisioned by syncing with the array. + - Volumes belonging to a tenant are identified using the **Volume Prefix** configured in csmtenant custom resource. + - Volumes without the **Volume Prefix** will not be accounted for in usage capacity calculation as ownership of the volume is unknown without the volume prefix. + - User should rename all volumes that are needed to be accounted for with the **Volume Prefix** before migration to v2. + +## Storage Systems + +In CSM for Authorization v1 setup, list the storage to get all the storages configured in the environment. +Example: + +``` +karavictl storage list --admin-token admintoken.yaml --addr csm-authorization.host.com + +{ + "storage": { + "powerflex": { + "3000000000011111": { + "Endpoint": "https://1.1.1.1", + "Insecure": true, + "Password": "(omitted)", + "User": "admin" + } + } + } +} +``` +In CSM for Authorization v2 Storage are created using custom resources. For each Storage in a v1 environment, create using the CRD, example: + +``` +kubectl create -f controller/config/samples/csm-authorization_v1_storage.yaml +``` +Content of csm-authorization_v1_storage.yaml +```yaml +apiVersion: csm-authorization.storage.dell.com/v1 +kind: Storage +metadata: + name: powerflex +spec: + # Type of the storage system. Example: powerflex, powermax, powerscale + type: powerflex + endpoint: https://1.1.1.1 + # System ID of the backend storage array + systemID: 3000000000011111 + # Vault is the credential manager for storage arrays + vault: + identifier: vault0 + kvEngine: secret + path: csm-authorization/powerflex/3000000000011111 + # SkipCertificateValidation is the flag to skip certificate validation + skipCertificateValidation: true + # PollInterval is the polling frequency to test the storage connectivity + pollInterval: 30s +``` + +## Role and Role Binding + +In CSM for Authorization v2, role creation is simpler. User will not be required to bind the role, only thing user needs to do is create roles that are needed. + +List all the roles that are created in CSM for Authorization v1 setup. +Example: +``` +karavictl role list --admin-token admintoken.yaml --addr csm-authorization.host.com +``` +``` +{ + "CSIGold": [ + { + "storage_system_id": "3000000000011111", + "pool_quotas": [ + { + "pool": "mypool", + "quota": 32000000 + } + ] + } + ], + "CSISilver": [ + { + "storage_system_id": "3000000000011111", + "pool_quotas": [ + { + "pool": "mypool", + "quota": 16000000 + } + ] + } + ] +} +``` +For each role in v1 setup, create roles using csmrole custom resources. +Example +``` +kubectl create -f controller/config/samples/csm-authorization_v1_csmrole.yaml +``` +csm-authorization_v1_csmrole.yaml file for **CSIGold** role in v1 setup will look like following example file: +```yaml +apiVersion: csm-authorization.storage.dell.com/v1 +kind: CSMRole +metadata: + labels: + app.kubernetes.io/name: role + app.kubernetes.io/instance: role-sample + app.kubernetes.io/part-of: csm-authorization + app.kubernetes.io/managed-by: kustomize + app.kubernetes.io/created-by: csm-authorization + name: CSIGold +spec: + quota: 1600GiB + systemID: 3000000000011111 + systemType: powerflex + pool: mypool +``` + +## Tenant + +List all the tenants in v1 setup and all those tenants should be created in v2 setup. +List tenants in v1 setup, example: +``` +karavictl tenant list --admin-token admintoken.yaml --addr csm-authorization.host.com +``` +``` +{ + "tenants": [ + { + "name": "Alice" + } + ] +} +``` +Get detail of each tenant, example: +``` +karavictl tenant get --name Alice --admin-token admintoken.yaml --addr csm-authorization.host.com +``` +``` +{ + "name": "Alice" + "roles": "role-1,role-2" +} +``` +For each Tenant in a v1 environment, create a new CSMTenant using the Tenant CRD. Role binding will be handled automatically. + +Example: +``` +kubectl create -f controller/config/samples/csm-authorization_v1_csmtenant.yaml +``` +csm-authorization_v1_csmtenant.yaml file will look like following example: +```yaml +apiVersion: csm-authorization.storage.dell.com/v1 +kind: CSMTenant +metadata: + labels: + app.kubernetes.io/name: csmtenant + app.kubernetes.io/instance: csmtenant-sample + app.kubernetes.io/part-of: csm-authorization + app.kubernetes.io/managed-by: kustomize + app.kubernetes.io/created-by: csm-authorization + name: Alice +spec: + # Roles defines a comma separated list of Roles for this tenant + roles: role-1,role-2 + approveSdc: false + revoke: false + volumePrefix: tn1 +``` \ 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 index 1a9d357e57..8cc0132fbd 100644 --- a/content/docs/deployment/csmoperator/modules/authorization v2.0 Tech Preview.md +++ b/content/docs/deployment/csmoperator/modules/authorization v2.0 Tech Preview.md @@ -18,9 +18,9 @@ To deploy the Operator, follow the instructions available [here](../../#installa 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'. +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 +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 ``` @@ -39,7 +39,7 @@ To deploy the Operator, follow the instructions available [here](../../#installa ``` 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 @@ -48,12 +48,12 @@ To deploy the Operator, follow the instructions available [here](../../#installa 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__: +>__Note__: > - If you are installing CSM Authorization in a different namespace than `authorization`, edit the `namespace` field in this file to your namespace. @@ -98,9 +98,9 @@ To deploy the Operator, follow the instructions available [here](../../#installa | 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__: +>__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. +> - 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. @@ -114,11 +114,11 @@ To enable reporting of trace data with [Zipkin](https://zipkin.io/), use the `cs 4. Execute this command to create the Authorization CR: ```bash - + kubectl create -f ``` - >__Note__: + >__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 @@ -138,7 +138,7 @@ Follow the instructions available in CSM Authorization for [Configuring the CSM ### Configure a Dell CSI Driver with CSM Authorization -Follow the instructions available in CSM Authorization for +Follow the instructions available in CSM Authorization for - [Configuring PowerFlex with Authorization](../../../../authorization/v2.0-tech-preview/configuration/powerflex). - [Configuring PowerMax with Authorization](../../../../authorization/v2.0-tech-preview/configuration/powermax). @@ -148,7 +148,7 @@ If there is already a Vault server available, skip to [Minimum Server Configurat 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. +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. @@ -175,8 +175,8 @@ openssl req -newkey rsa:2048 -nodes \ 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. +> 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 < cert.ext < **NOTE:** this configuration is a bare minimum to support CSM Authorization and is not intended for use in production environment. +> **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. +> 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 +> - `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). @@ -362,7 +361,7 @@ With the default server settings, role level values control TTL in this way: `token_explicit_max_ttl=2h` - limits the client token TTL to 2 hours since it was originally issues as a result of login. This is a hard limit. -`token_ttl=30m` - sets the default client token TTL to 30 minutes. 30 minutes are counted from the login time and from any following token renewal. +`token_ttl=30m` - sets the default client token TTL to 30 minutes. 30 minutes are counted from the login time and from any following token renewal. The client token will only be able to renew 3 times before reaching it total allowed TTL of 2 hours. Existing role values can be changed using `vault write auth/kubernetes/role/csm-authorization token_ttl=30m token_explicit_max_ttl=2h`.