Greymatter supports the use of Hashicorp Vault secrets, Kubernetes secrets, or both to manage sensitive data. The benefit of using Vault over Kubernetes secrets is that secrets are stored in a secure server, fully disconnected from the infrastructure that the Greymatter platform is being installed too.

There are two categories of Vault secrets in Greymatter:

1. Infrastructure secrets

2. Data plane filter secrets

Before beginning please make sure you have:

• An installed Greymatter instance

• A deployed Vault server

Create a Vault authentication secret

To integrate with Vault, Greymatter requires authentication credentials. These credentials must exist as a Kubernetes secret.

kubectl create secret generic greymatter-vault --from-literal=token=<vault token> -n gm-operator

To configure TLS from Greymatter to Vault, create the secret with these options:

kubectl create secret generic greymatter-vault --from-literal=token=<vault token> --from-file=ca.crt=<path to CA certificate> -n gm-operator

To configure mTLS between Greymatter and Vault, create the secret with these options:

kubectl create secret generic greymatter-vault --from-literal=token=<vault token> --from-file=ca.crt=<path to CA certificate> --from-file=server.crt=<path to client certificate> --from-file=server.key=<path to private key> -n gm-operator

Create the Git authentication secret

The Operator can be configured to read a Vault secret containing configurations to connect to your Git repo. This is akin to the greymatter-core-repo Kubernetes secret with the same configurations, if using a Kubernetes secret for Git authentication. Create a new secret in Vault containing key-value pairs for either SSH or HTTP connections to your Git server.

SSH

auth_type: ssh
ssh-private-key: <private key>
known_hosts: <known hosts file with an entry for the Git server>
ssh_private_key_password: <optional password for the private key if it is encrypted>

HTTP

auth_type: http
http_username: <the username of the Git user>
http_password: <the password for the Git user>
tls_remote_ca: <a bundle of CA certs to validate the Git remote's certificate>
tls_insecure_verify: <whether or not to validate the remote's certificate, by default, verification is enabled>

Set the value of GREYMATTER_GITOPS_AUTH_VAULT_PATH to this secret’s path in Vault.

Edit the Operator bootstrap configuration

The operator does not pull secrets from Vault by default. To enable Vault for secrets management, open the installation manifest you use to install your Greymatter Operator.

└── greymatter-core
    └── generated-manifests
        ├── operator-openshift-spire.yaml
        ├── operator-openshift.yaml
        ├── operator-spire.yaml
        └── operator.yaml

Next, locate the bootstrap ConfigMap. It should have some basic environment variables set. Append the required fields to the list:

GREYMATTER_VAULT_ENABLE: true
GREYMATTER_VAULT_ADDRESS: <your vault URL>

You can find all Vault variables, including ones to control TLS connections, at this page.

Apply the Changes

Apply the changes by running:

kubectl apply -f </path/to/greymatter-core/generated-manifests/operator>.yaml -n gm-operator

This will update the bootstrap ConfigMap in your Kubernetes cluster. Then, restart the Operator if you already have it deployed:

kubectl delete pod -n gm-operator greymatter-operator-0

Inspecting the Operator logs should reveal that the Operator is parsing the new configurations, locating the greymatter-vault Kubernetes secret, and if using GREYMATTER_GITOPS_AUTH_VAULT_PATH, resolving Git server configurations from Vault. If the Operator successfully pulls from your Git repository, then the Vault configurations have been applied correctly. An additional verification is to see the greymatter-vault Kubernetes secret and greymatter-vault-config ConfigMap (auto-created by Operator) in the greymatter namespace for Control to leverage.

Now, your Greymatter installation is ready to read infrastructure secrets and data plane filter secrets from Vault.