As discussed, each API has an authentication section that specifies how to authenticate Vault. Here’s an example.

  authentication: 
    path: kubernetes
    role: policy-admin
    namespace: tenant-namespace
    serviceAccount:
      name: vaultsa  
Copy the code

The path field specifies the installation path of the Kubernetes authentication role.

The role field specifies the role to request during authentication.

The Namespace field specifies the Vault namespace to use (independent of the Kubernetes namespace). This is optional.

Serviceaccount. name specifies which serviceAccount token to use during authentication.

Therefore, the above configuration roughly corresponds to the following commands.

vault write [tenant-namespace/]auth/kubernetes/login role=policy-admin jwt=
Copy the code

VaultRole, for example, creates a Vault authentication role for Kubernetes authentication mount.

apiVersion: redhatcop.redhat.io/v1alpha1
kind: VaultRole
metadata:
  name: database-engine-admin
spec:
  authentication: 
    path: kubernetes
    role: policy-admin
  path: kubernetes  
  policies:
    - database-engine-admin
  targetServiceAccounts: 
  - vaultsa  
  targetNamespaceSelector:
    matchLabels:
      postgresql-enabled: "true"
Copy the code

The path field specifies the Kubernetes authentication mount path where the role will be mounted.

The Policies field specifies which Vault policies will be associated with this role.

The targetServiceAccounts field specifies which service accounts can be authenticated. If not specified, it defaults to default.

The targetNamespaceSelector field specifies which Kubernetes namespaces can be authenticated from. Note that this configuration will be updated as the set of namespaces selected by the selector changes. You can also specify a static set of namespaces.

Many other standard Kubernetes authentication role fields are available for fine-tuning, see Vault documentation

This CR is roughly equivalent to the Vault CLI command.

vault write [namespace/]auth/kubernetes/role/database-engine-admin bound_service_account_names=vaultsa bound_service_account_namespaces=
Copy the code

Secret DatabaseSecretEngineConfig CRD allows the user to create a database engine configuration, also known as the secret existing database engine installation of connection. Here’s an example

apiVersion: redhatcop.redhat.io/v1alpha1
kind: DatabaseSecretEngineConfig
metadata:
  name: my-postgresql-database
spec:
  authentication: 
    path: kubernetes
    role: database-engine-admin
  pluginName: postgresql-database-plugin
  allowedRoles:
    - read-write
    - read-only
  connectionURL: postgresql://{{username}}:{{password}}@my-postgresql-database.postgresql-vault-demo.svc:5432
  username: admin
  rootCredentialsFromSecret:
    name: postgresql-admin-password
  path: postgresql-vault-demo/database
Copy the code

The pluginName field specifies what type of database this connection is for.

The allowedRoles field specifies which role names can be created for this connection.

The connectionURL field specifies how to connect to the database.

The username field specifies the username used to connect to the database. This field is optional; if not specified, the username is taken from the credential secret.

The path field specifies the path to the secret engine to which the connection will be added.

Passwords and possible user names can be obtained in three different ways.

1. Secret from Kubernetes, specifiedrootCredentialsFromSecretField. The secret must beBasic Authentication Type. If the secret is updated, the connection is updated as well.
2. Secret from Vault, specifiedrootCredentialsFromVaultSecretField.
3. From aRandomSecret, specifyrootCredentialsFromRandomSecretField. When RandomSecret generates a new secret, the connection will also be updated.

Many other standard database secret engine configuration fields are available for fine-tuning, see Vault documentation

This CR is roughly equivalent to the Vault CLI command.

vault write [namespace/]auth/kubernetes/role/database-engine-admin bound_service_account_names=vaultsa Bound_service_account_namespaces = < dynamic generation > policies=database-engine-admin

[](#databasesecretenginerole)DatabaseSecretEngineRole ----------------------------------------------------- 'DatabaseSecretEngineRole' CRD allows the user to create a DatabaseSecretEngineRole. Here is an example. apiVersion: redhatcop.redhat.io/v1alpha1 kind: DatabaseSecretEngineRole metadata: name: read-only spec: authentication: path: kubernetes role: database-engine-admin path: postgresql-vault-demo/database dBName: my-postgresql-database creationStatements: - CREATE ROLE "{{name}}" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO "{{name}}";Copy the code

The path field specifies the path to the secret engine that will contain this role.

The dBname field specifies the name of the connection to be used with this role.

The creationStatements field specifies the statement to run to create a new account.

Many other standard database secret engine role fields are available for fine-tuning, see Vault documentation

This CR is roughly equivalent to the Vault CLI command.

vault write [namespace/]postgresql-vault-demo/database/config/my-postgresql-database plugin_name=postgresql-database-plugin allowed_roles="read-write,read-only" connection_url="postgresql://{{username}}:{{password}}@my-postgresql-database.postgresql-vault-demo.svc:5432/" username=<retrieved dynamically> password=<retrieved dynamically>
Copy the code