Secrets management

The Kubernetes declarative model requires that you develop applications with manifest files or command line interactions with the Kubernetes API. This makes your sensitive information vulnerable because it is exposed in files and your shell history.

Kubernetes provides native support to prevent such security risks with Secrets. A Secret is an object that you can reference by name that conceals confidential data. For example, you can create a Secret named su-password that stores the database superuser password. In a manifest file, you can add su-password in place of the literal password value, and now you can safely store the manifest in a file system or pass it on the command line.

Cloud providers offer services that let you store sensitive information in a central location and reference it securely. Vertica support for these services and other Secret strategies are detailed in the following sections.

Manually encode Secrets

The idiomatic way to create a Secret in Kubernetes is with the kubectl command-line tool. For example, the following command creates a Secret named superuser-password from a literal value passed on the command line:

$ kubectl create secret generic superuser-password \
    --from-literal=password=secret-value
secret/superuser-password created

Instead of creating a Kubernetes Secret with kubectl, you can manually base64 encode a string on the command line, and then add the encoded output to a Secrets manifest. For example, pass the string value to the echo command, and pipe the output to the base64 command to encode the value. In the echo command, include the -n option so that it does not append a newline character:

$ echo -n 'secret-value' | base64
c2VjcmV0LXZhbHVl

For detailed steps about creating the Secret manifest and applying it to a namespace, see the Kubernetes documentation.

Google Secret Manager

Google Cloud provides Google Secret Manager, a storage system for your sensitive data. To access your Secrets from your Google Cloud console, go to Security > Secret Manager.

Google Secret Manager stores data as key-value pairs, where the key is the name of the Secret, and the value is data in any format. Vertica requires that you format the value as a JSON document consisting of plain text string keys and base64-encoded values. For example:

{"password": "c2VjcmV0"}

When you pass a Google Secret as a CRD parameter, use the Secret resource name:

projects/project-id/secrets/secret-name/versions/version-number

The following VerticaDB CR parameters require that you prefix the Secret resource name with gsm://:

  • passwordSecret
  • nmaTLSSecret
  • communal.credentialSecret

For example:

    spec:
      ...
      passwordSecret: gsm://projects/project-id/secrets/password-secret/versions/version-number
      nmaTLSSecret: gsm://projects/project-id/secrets/nma-certs-secret/versions/version-number
      communal:
        credentialSecret: gsm://projects/project-id/secrets/gcp-creds-secret/versions/version-number
        path: gs://bucket-name/path/to/database-name
        ...