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
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: vault-db-creds
spec:
# Vault CSI Provider provider: vault
parameters:
# Vault role name to use during login roleName: 'csm-authorization'# Vault's hostname vaultAddress: 'https://vault:8200'# TLS CA certification for validation vaultCACertPath: '/vault/tls/ca.crt' objects: | - objectName: "dbUsername" secretPath: "database/creds/db-app" secretKey: "username" - objectName: "dbPassword" secretPath: "database/creds/db-app" secretKey: "password"# "objectName" is an alias used within the SecretProviderClass to reference# that specific secret. This will also be the filename containing the secret.# "secretPath" is the path in Vault where the secret should be retrieved.# "secretKey" is the key within the Vault secret response to extract a value from.
SecretProviderClass configuration with array-based and Redis credentials
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: vault-db-creds
spec:
# Vault CSI Provider provider: vault
secretObjects:
# Name of the Kubernetes Secret object# This name will be used during deployment - secretName: redis-secret-vault
type: kubernetes.io/basic-auth
data:
# Name of the mounted content to sync# This could be the object name or the object alias - objectName: dbRedisUsername
# Data field to populate key: username
- objectName: dbRedisPassword
key: password
parameters:
# Vault role name to use during login roleName: 'csm-authorization'# Vault's hostname vaultAddress: 'https://vault:8200'# TLS CA certification for validation vaultCACertPath: '/vault/tls/ca.crt' objects: | - objectName: "dbUsername" secretPath: "database/creds/db-app" secretKey: "username" - objectName: "dbPassword" secretPath: "database/creds/db-app" secretKey: "password" - objectName: "dbRedisUsername" secretPath: "database/creds/redis" secretKey: "username" - objectName: "dbRedisPassword" secretPath: "database/creds/redis" secretKey: "password"# "objectName" is an alias used within the SecretProviderClass to reference# that specific secret. This will also be the filename containing the secret.# "secretPath" is the path in Vault where the secret should be retrieved.# "secretKey" is the key within the Vault secret response to extract a value from.
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: conjur-db-creds
spec:
provider: conjur
secretObjects:
# Name of the Kubernetes Secret object# This name will be used during deployment - secretName: redis-secret-conjur
type: kubernetes.io/basic-auth
data:
# Name of the mounted content to sync# This could be the object name or the object alias - objectName: secrets/redis-username
# Data field to populate key: username
- objectName: secrets/redis-password
key: password
parameters:
conjur.org/configurationVersion: 0.2.0
account: replace-me-account
applianceUrl: 'https://conjur-conjur-oss.default.svc.cluster.local' authnId: authn-jwt/kube
sslCertificate: | -----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
Create a YAML file (in this example, storage-secret.yaml) containing the credentials:
# Username and password for accessing storage systemusername: "username"password: "password"
Note: Only one of SecretProviderClass or Secret can be used at a time.
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
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: vault-db-creds
spec:
# Vault CSI Provider provider: vault
secretObjects:
# Name of the Kubernetes Secret object# This name will be used during deployment - secretName: redis-secret-vault
type: kubernetes.io/basic-auth
data:
# Name of the mounted content to sync# This could be the object name or the object alias - objectName: dbRedisUsername
# Data field to populate key: username
- objectName: dbRedisPassword
key: password
- secretName: config-secret-vault
type: Opaque
data:
- objectName: config-object
# The key must be config.yaml for this secret key: config.yaml
parameters:
# Vault role name to use during login roleName: 'csm-authorization'# Vault's hostname vaultAddress: 'https://vault:8200'# TLS CA certification for validation vaultCACertPath: '/vault/tls/ca.crt' objects: | - objectName: "dbUsername" secretPath: "database/creds/db-app" secretKey: "username" - objectName: "dbPassword" secretPath: "database/creds/db-app" secretKey: "password" - objectName: "dbRedisUsername" secretPath: "database/creds/redis" secretKey: "username" - objectName: "dbRedisPassword" secretPath: "database/creds/redis" secretKey: "password" - objectName: "config-object" secretPath: "database/creds/config" secretKey: "configkey"# "objectName" is an alias used within the SecretProviderClass to reference# that specific secret. This will also be the filename containing the secret.# "secretPath" is the path in Vault where the secret should be retrieved.# "secretKey" is the key within the Vault secret response to extract a value from.
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: conjur-db-creds
spec:
provider: conjur
secretObjects:
# Name of the Kubernetes Secret object# This name will be used during deployment - secretName: redis-secret-conjur
type: kubernetes.io/basic-auth
data:
# Name of the mounted content to sync# This could be the object name or the object alias - objectName: secrets/redis-username
# Data field to populate key: username
- objectName: secrets/redis-password
key: password
- secretName: config-secret-conjur
type: Opaque
data:
- objectName: secrets/config-object
# The key must be config.yaml for this secret key: config.yaml
parameters:
conjur.org/configurationVersion: 0.2.0
account: replace-me-account
applianceUrl: 'https://conjur-conjur-oss.default.svc.cluster.local' authnId: authn-jwt/kube
sslCertificate: | -----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
After editing the file, run the following command to create a secret called karavi-config-secret:
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.
Updating Container Storage Modules for Authorization Proxy Server Configuration
Authorization has a subset of configuration parameters that can be updated dynamically:
Parameter
Type
Default
Description
web.jwtsigningsecret
String
“secret”
The secret used to sign JWT tokens
Updating configuration parameters can be done by editing the karavi-config-secret. The secret can be queried using k3s and kubectl like so:
kubectl -n authorization get secret/karavi-config-secret
To update parameters, you must edit the base64 encoded data in the secret. The karavi-config-secret data can be decoded like so:
kubectl -n authorization get secret/karavi-config-secret -o yaml | grep config.yaml | head -n 1| awk '{print $2}'| base64 -d
Save the output to a file or copy it to an editor to make changes. Once you are done with the changes, you must encode the data to base64. If your changes are in a file, you can encode it like so:
cat <file> | base64
Copy the new, encoded data and edit the karavi-config-secret with the new data. Run this command to edit the secret:
Replace the data in config.yaml under the data field with your new, encoded data. Save the changes and Authorization will read the changed secret.
Note: If you are updating the signing secret, the tenants need to be updated with new tokens via the dellctl generate token command.
CSM for Authorization Proxy Server Dynamic Configuration Settings
Some settings are not stored in the karavi-config-secret but in the csm-config-params ConfigMap, such as LOG_LEVEL and LOG_FORMAT. To update the Authorization logging settings during runtime, run the below command, make your changes, and save the updated configMap data.
This edit will not update the logging level for the sidecar-proxy containers running in the CSI Driver pods. To update the sidecar-proxy logging levels, you must update the associated CSI Driver ConfigMap in a similar fashion:
Using PowerFlex as an example, kubectl -n vxflexos edit configmap/vxflexos-config-params can be used to update the logging level of the sidecar-proxy and the driver.