Authorization v2.0

Container Storage Modules (CSM) for Authorization v2.0 Operator deployment

Docker Hub images are discontinued. All deployments will be using images from quay.io.

The following Authorization components are installed in the specified namespace:

  • proxy-service, which forwards requests from the CSI Driver to the backend storage array
  • tenant-service, which configures tenants, role bindings, and generates JSON Web Tokens
  • role-service, which configures roles for tenants to be bound to
  • storage-service, which configures backend storage arrays for the proxy-server to forward requests to

The following third-party components are installed in the specified namespace:

  • redis, which stores data regarding tenants and their volume ownership, quota, and revokation status
  • redis-commander, a web management tool for Redis

The following third-party components are optionally installed in the specified namespace:

  • cert-manager, which optionally provides a self-signed certificate to configure the Authorization Ingresses
  • nginx-ingress-controller, which fulfills the Authorization Ingresses

Storage system credentials can be provided in one of two ways:

  1. Using a SecretProviderClass (for dynamic secrets from external providers)
  2. Using a Kubernetes Secret (for static credentials)

Install Container Storage Modules Authorization

  1. Create the Authorization namespace.

    kubectl create namespace authorization

  2. Install cert-manager CRDs

    kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml

  3. Configure Storage Credentials


  • Ensure the Secrets Store CSI Driver is installed and configured with an External Secret Provider. For guidance refer to our installation and configuration guide.

  • Create your own SecretProviderClass Object based on your external secret provider. You also have the option to create your own Redis secret in the SecretProviderClass.

Minimal SecretProviderClass configuration: includes only array-based credentials
SecretProviderClass configuration with array-based and Redis credentials

  • Create a YAML file (in this example, storage-secret.yaml) containing the credentials:

    # Username and password for accessing storage system
username: "username"
password: "password"

  • Create the Secret:

    kubectl create secret generic storage-secret -n authorization --from-file=storage-secret.yaml

Note: Only one of SecretProviderClass or Secret can be used at a time.


  1. Prepare 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:

web:
  jwtsigningsecret: randomString123

  • Ensure the Secrets Store CSI Driver is installed and configured with an External Secret Provider. For guidance refer to our installation and configuration guide.

  • Create your JWT signing secret within your chosen External Secret Provider. Paste the contents of this file as the secret content.

  • Create your own SecretProviderClass Object based on your external secret provider. You also have the option to create your own Redis secret in the SecretProviderClass.

SecretProviderClass configuration with array-based, Redis, and config credentials

After editing the file, run this command to create a secret called karavi-config-secret:

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:

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:

  • Only one of SecretProviderClass or Secret can be used at a time.
  • If you are installing Authorization in a different namespace than authorization, edit the namespace field in this file to your namespace.

Install Container Storage Modules Authorization Proxy Server

  1. Create a CR (Custom Resource) for Authorization from a sample manifest. This file can be modified to use custom parameters if needed.

  2. Users should configure the parameters in the CR. This table lists the primary configurable parameters of the Authorization Proxy Server and their default values:

    Parameters
    Additional v2.0 Parameters

    Note:

    • If you are installing 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 Authorization.

    Optional: To enable reporting of trace data with Zipkin, 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.

    ZIPKIN_URI: "http://ZIPKIN_ADDRESS:9411/api/v2/spans"
ZIPKIN_PROBABILITY: "1.0"

  1. Execute this command to create the Authorization CR:

    kubectl create -f <SAMPLE FILE>

Note:

  • This command will deploy the Authorization Proxy Server in the namespace specified in the input YAML file.

Verify Installation of the Container Storage Modules Authorization Proxy Server

Once the Authorization CR is created, you can verify the installation as mentioned below:

kubectl describe csm/<name-of-custom-resource> -n authorization

Install dellctl

Note: Karavictl will not work with Authorization v2.x. Please use dellctl instead.

Follow the instructions for Installing dellctl.

Installing and configuring the Secrets Store CSI Driver with an External Secret Provider

  • Install a supported External Secret Provider to integrate with the Secrets Store CSI Driver. For guidance on setting up Vault, refer to our Vault installation guide. For Conjur, refer to our Conjur installation guide.

  • Install the Secrets Store CSI Driver enabling the Sync as Kubernetes Secret and Secret Auto Rotation features.

    Note: If you are using Conjur with the Secrets Store CSI Driver, be sure to configure --set 'tokenRequests[0].audience=conjur' when installing the Secrets Store CSI Driver.

  • For OpenShift environments, label the namespace:

    kubectl label namespace authorization \
 pod-security.kubernetes.io/enforce=privileged \
 security.openshift.io/MinimallySufficientPodSecurityStandard=privileged \
 --overwrite

Configure the Container Storage Modules Authorization Proxy Server

Follow the instructions available in Authorization for Configuring the Authorization Proxy Server.

Configure a Dell CSI Driver with Container Storage Modules Authorization

Follow the instructions available in Authorization for

Vault CSI Provider Installation

If there is already a Vault CSI provider install available, skip to Minimum Server Configuration.

If there is no Vault CSI provider available to use with CSM Authorization, it can be installed following Hashicorp Vault documentation.

For a testing environment, however, a simple deployment suggested in this section may suffice.

NOTE: It creates a standalone server with in-memory (non-persistent) storage. It is insecure and will lose data on every restart. It is only made for development or experimentation.

Start Vault CSI Provider 

helm repo add hashicorp https://helm.releases.hashicorp.com
helm install vault hashicorp/vault \
    --set "server.dev.enabled=true" \
    --set "injector.enabled=false" \
    --set "csi.enabled=true"

This is the recommended installation method for Vault Provider for Secrets Store CSI Driver.

Minimum Server Configuration

NOTE: This configuration is a bare minimum to support CSM Authorization. Refer to the Hashicorp Vault documentation for recommended configuration options.

To start an interactive shell session, run kubectl exec -it vault-0 -- /bin/sh. After completing the configuration process, exit the shell by typing exit.

Enable Key/Value secret engine 

vault secrets enable -version=2 -path=csm-authorization/ kv

Key/Value secret engine is used to store array credentials.

Enable Kubernetes authentication 

vault auth enable kubernetes

Configure Kubernetes authentication 

vault write auth/kubernetes/config kubernetes_host="$KUBERNETES_HOST" kubernetes_ca_cert="$KUBERNETES_CA_CERT"

Create a policy 

vault policy write csm-authorization - <<EOF
path "csm-authorization/*" {
	capabilities = ["read"]
}
EOF

The policy needs read access to the path(s) containing the storage credentials.

Create a role 

vault write auth/kubernetes/role/csm-authorization \
	token_ttl=1h \
	token_max_ttl=1h \
	token_explicit_max_ttl=10d \
  bound_service_account_names=storage-service,tenant-service,proxy-server,sentinel,redis \
  bound_service_account_namespaces=authorization \
  policies=csm-authorization

The role needs to be:

  • bound to the storage-service service account
  • bound to the namespace where Authorization will be deployed
  • reference the policy that has read access to the storage credentials.

Write a secret

Given an example below for writing a secret to vault for PowerFlex,

vault kv put -mount=secret /storage/powerflex/systemid1 username=user password=pass

The username must use the key username and the password must use the key password.

Token TTL Considerations

Effective client token TTL is determined by the Vault server based on multiple factors which are described in the Vault documentation.

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

Conjur CSI Provider Installation

If there is already a Conjur CSI provider install available, skip to Minimum Server Configuration.

If there is no Conjur CSI provider available to use with CSM Authorization, it can be installed following Conjur K8S CSI Provider documentation.

For a testing environment, however, a simple deployment suggested in this section may suffice.

Start Conjur CSI Provider 

helm repo add cyberark https://cyberark.github.io/helm-charts
helm install conjur-csi-provider \
  cyberark/conjur-k8s-csi-provider \
  --set provider.name="conjur" \
  --set securityContext.privileged=true \
  --set securityContext.allowPrivilegeEscalation=true

Conjur Minimum Server Configuration

NOTE: This configuration is a bare minimum to support CSM Authorization.

Load Host Policy

Load the following policy file using conjur-cli. In this example, the yaml below is saved in $HOME/.conjur-cli/config.yaml.

NOTE: This example uses public-keys of the Service Account Issuer Discovery service in Kubernetes. jwks-uri is also available to set and configure.

# Define the policy branch
- !policy
  id: csm-authorization
  body:
    - !host
      id: system:serviceaccount:authorization:storage-service
      annotations:
        authn-jwt/kube/kubernetes.io/namespace: "authorization"
        authn-jwt/kube/kubernetes.io/serviceaccount/name: "storage-service"

# Define the webservice and its variables
- !webservice
  id: conjur/authn-jwt/kube

- !variable
  id: conjur/authn-jwt/kube/issuer

- !variable
  id: conjur/authn-jwt/kube/public-keys

- !variable
  id: conjur/authn-jwt/kube/audience

- !variable
  id: conjur/authn-jwt/kube/token-app-property

- !variable
  id: conjur/authn-jwt/kube/identity-path

# Permit the nested host access to the webservice
- !permit
  role: !host csm-authorization/system:serviceaccount:authorization:storage-service
  privilege: [ read, authenticate ]
  resource: !webservice conjur/authn-jwt/kube

podman run --rm -it -v ~/.conjur-cli:/home/cli docker.io/cyberark/conjur-cli:8 policy load -b root -f /home/cli/config.yaml

Configure JWT Authentication

Save your cluster’s JWKS information.

kubectl get --raw /openid/v1/jwks > $HOME/.conjur-cli/jwks.json

Configure the public-keys, issuer, token-app-property, identity-path, and audience variables.

If your cluster is OpenShift, the issuer is https://kubernetes.default.svc. For standard Kubernetes, it is https://kubernetes.default.svc.cluster.local. In this example, the cluster is OpenShift.

ISSUER="https://kubernetes.default.svc"

podman run --rm -v ~/.conjur-cli:/home/cli docker.io/cyberark/conjur-cli:8 variable set -i conjur/authn-jwt/kube/public-keys -v "{\"type\":\"jwks\", \"value\":$(cat ~/.conjur-cli/jwks.json | jq -c .)}" && \
podman run --rm -v ~/.conjur-cli:/home/cli docker.io/cyberark/conjur-cli:8 variable set -i conjur/authn-jwt/kube/issuer -v "$ISSUER && \
podman run --rm -v ~/.conjur-cli:/home/cli docker.io/cyberark/conjur-cli:8 variable set -i conjur/authn-jwt/kube/token-app-property -v "sub" && \
podman run --rm -v ~/.conjur-cli:/home/cli docker.io/cyberark/conjur-cli:8 variable set -i conjur/authn-jwt/kube/identity-path -v csm-authorization && \
podman run --rm -v ~/.conjur-cli:/home/cli docker.io/cyberark/conjur-cli:8 variable set -i conjur/authn-jwt/kube/audience -v "conjur"

Load and Configure a Secret

In this example, the following yaml is saved in $HOME/.conjur-cli/app-secret.yaml.

- !policy
  id: secrets
  body:
    - &variables
      - !variable username
      - !variable password
    - !permit
      role: !host /csm-authorization/system:serviceaccount:authorization:storage-service
      privilege: [ read, execute ]
      resource: *variables

podman run --rm -it -v ~/.conjur-cli:/home/cli docker.io/cyberark/conjur-cli:8 policy load -b root -f /home/cli/app-secret.yaml

Set the variable with values. In this example, usr and pwd are the values.

podman run --rm -it -v ~/.conjur-cli:/home/cli docker.io/cyberark/conjur-cli:8 variable set -i secrets/username -v usr && \
podman run --rm -it -v ~/.conjur-cli:/home/cli docker.io/cyberark/conjur-cli:8 variable set -i secrets/password -v pwd