Integrating with HashiCorp Vault

Kaspersky Container Security provides the ability to securely transfer passwords, tokens, and secrets using HashiCorp Vault, an external storage service. The solution generates pod annotations, which the Vault injector uses to mount the necessary secrets from storage at startup.

Kaspersky Container Security supports integration with Hashicorp Vault 1.7 or later.

Version 2.0 of Kaspersky Container Security supports working with HashiCorp Vault only in sidecar mode using sidecar containers; in this case, only the Kubernetes authentication method is supported.

If the service accounts for pods are not defined, and default service accounts are used, we recommend against assigning roles dedicated to the storage to such service accounts, in line with a critical security requirement.

Values of HashiCorp Vault settings are specified in the values.yaml configuration file and deployed when the Helm Chart package is launched.

HashiCorp Vault settings are configured in the values.yaml configuration file as follows:

• If the enabled setting in the vault block is set to false, integration with the vault is not used.
• If the enabled setting in the vault block is set to true, integration with the vault is enabled, and the values of the variables in the vault settings block take precedence.

The vault settings block contains the following sections:

• secret – to specify secrets and credentials.
• certificate – to specify certificates and certificate keys.

The secret section lists the paths to files that contain the secrets for the following parameters:

• Secrets of proxy servers for requests to the external information environment.
• Credentials for the PostgreSQL database.
• Credentials for an s3-compatible file storage for storing files that are generated by the solution.
• Credentials for the ClickHouse database management system.

Secrets are specified in key:value format

where:

• <key> is the name of the environment variable
• <value> is the full path to the secret in the secret storage, followed by the @ sign and the name of the key of the secret created in the storage.

For example: POSTGRES_USER: kv/secret/kcs/psql@POSTGRES_USER

To get a certificate, in the vault.certificate section, you must specify the following in the fields:

• To get a CA certificate, the ca setting is set to true. In this case, the path to access the certificate is formed based on the standard cert/ca path based on the name in the public key infrastructure (Public Key Infrastructure, PKI). If the CA certificate is not a root certificate, use the caList parameter to list all certificates, including the root certificate. For example:

  cert-ca:

  ca: true

  tls.crt: pki_kcs/cert/ca

  caList:

  - pki/cert/ca

• To generate certificates and keys, you need to specify the path from the PKI name with the standard issue path and the name of the created role. The common name (cn) and all possible alternative names (altname) are automatically added to the certificate. If necessary, the cn, altname and ipsans values can be specified manually as shown below for an external database:

  cert-pguser:

  cn: pguser

  altname: pguser,pguser.psql,pguser.psql.svc,pguser.psql.svc.cluster.local,localhost

  ipsans: 0.0.0.0,127.0.0.1

• To set the certificate lifetime, you need to specify the value of the ttl parameter. The default value is 8760 hours.

  The parameter value cannot be greater than the value set in the PKI HashiCorp Vault.

The certificate section also contains the paths to files that contain the following certificates and keys:

• CA certificate and client certificate for an external PostgreSQL database.
• Certificates required for the solution components:
  • CA certificate and CA certificate key for the admission controller.
  • Certificate and certificate key for the Kaspersky Container Security licensing module.
  • Certificate and certificate key for the module with the solution's main business logic.
  • Certificate and certificate key for the remote procedure call platform (GRPC).
  • Certificate and certificate key for the scanner server.
  • Certificate and certificate key for the scanner server API.
  • Certificate and certificate key for the update file server for private corporate networks.
  • Certificate and certificate key for s3-compatible file storage.
  • Certificate and certificate key for the event broker.
  • Certificate and certificate key for the agent broker.
  • Certificate and certificate key for the ClickHouse database management system.

HashiCorp Vault storage settings:

For Kaspersky Container Security to work with HashiCorp Vault, you must specify the values of the following configuration settings in the values.yaml configuration file:

• The enabled flag enables the integration with the storage. The vault.enabled = true value indicates that the integration with HashiCorp Vault is established; the values of environment variables are obtained from the storage. The default value is false.
• mountPath — path to mount secrets from the Vault to the pod. The default is /vault/secrets.
• role is the role to be used for authentication in the storage.

  When creating a role in Vault, you need to specify all existing values from the serviceAccount section in the values.yaml file.

• agentInitFirst — variable for defining the initialization queue of the init container. A value of true indicates that the pod first initializes the Vault init container. This value must be set when other containers in the initialization require prepopulated secrets to function. If it is set to false, the order of initialization of the containers is randomized. The default value is true.
• agentPrePopulate — variable for enabling the init container for prepopulating the shared memory with secrets before the containers are started. The default value is true.
• agentPrePopulateOnly — variable that indicates whether the init container will be the only one injected in the pod. If it is set to true, no sidecar container is added when the pod is run. The default value is false.
• preserveSecretCase — variable for preserving the case in the names of secrets when creating secret files. The default value is true.
• agentInjectPerms — variable that defines rights to access the mounted file with secrets from the storage. The default value is 0440 (owner and group have the read permission).
• annotations — instructions that configure the correct operation of the sidecar container. You can add instructions to the vault block for use by all Helm Chart components or specify them in the Architecture section separately for each component, for example:

  kcs-middleware:

  enabled: true

  appType: deployment

  annotations:

  vault.hashicorp.com/agent-limits-cpu: 200m

Limitations related to storage

There is a number of non-critical limitations when Kaspersky Container Security works with HashiCorp Vault:

• Integration with HashiCorp Vault works only with KV1/KV2 storages and Secrets Engine components for rotating PKI certificates.
• The solution does not support working with external components of the Secrets Engine, except for PKI Secrets.
• Kaspersky Container Security does not support dynamic processing of secrets. To get an updated secret, you have to restart the solution.
• If you are using Vault integration, you can specify credentials only for an external PostgreSQL database in the vault section. To use an internal PostgreSQL database, these credentials must be commented out.