Secret Management

overview the resolve satellite uses two types of secrets ingest token authenticates the satellite over an encrypted channel integration tokens authenticate with on premises data sources (e g , grafana, elasticsearch, splunk) for security best practice, use kubernetes secrets and encrypt etcd at rest the satellite automatically mounts these secrets as files in the pod at /etc/secrets/\<secret name>/ the raw secret values are never exposed to resolve's cloud and stay strictly within the walls of your satellite deployment they are used to authenticate with on premises data sources security recommendation for production environments we recommend using secret management solutions already approved by your security team in order to ensure that secrets are properly encrypted and managed according to enterprise security standards if you use kubernetes secrets as your secret management solution, encrypt etcd at rest encrypting data at rest protects secret data stored in the cluster alternatively, integrate with external secrets management systems like hashicorp vault , aws secrets manager , azure key vault , or google secret manager using controllers like external secrets operator choose your setup method select the approach that matches your environment and security requirements setup ingest token kubernetes secrets secret management /#ingest token with kubernetes secret if you use native kubernetes secrets external secrets manager secret management /#ingest token with external secrets manager if you use aws secrets manager, azure key vault, hashicorp vault, or similar setup tokens for your integrations see secret management /#integration token configuration to connect on premises data sources configuring your ingest token the satellite requires an ingest token to authenticate with the resolve backend choose one of the following methods based on your environment ingest token with kubernetes secret this method stores your ingest token as a native kubernetes secret, keeping it separate from your configuration files step 1 create the secret create a kubernetes secret containing your ingest token create secret kubectl create secret generic resolve satellite token from literal=token=\<your resolve satellite token> step 2 reference in values file reference the secret in your resolve values yaml resolve values yaml ingest tokensecretname resolve satellite token clustername \<your cluster name> environment \<your environment> security best practice this values file should be applied by a cluster admin and should not be checked into version control systems use your organization's secure deployment practices for managing helm values files the satellite will automatically read the token from the secret at runtime ingest token with external secrets manager for enterprise environments using external secrets managers this method integrates with aws secrets manager, azure key vault, hashicorp vault, or other providers via the secrets store csi driver prerequisites secrets store csi driver installed in your cluster secret named resolve satellite token created in your secrets manager with the ingest token value step 1 create secret provider class create a secret provider class yaml file configured for your secrets provider refer to the secrets store csi driver documentation for provider specific configuration secret provider class yaml apiversion secrets store csi x k8s io/v1 kind secretproviderclass metadata name resolve satellite secrets spec provider \<your provider> # aws, azure, gcp, vault, etc parameters \# provider specific parameters see your provider's documentation step 2 apply the secret provider class kubectl apply f secret provider class yaml step 3 configure values file configure your resolve values yaml to use the external secrets resolve values yaml ingest providersecretname resolve satellite token clustername \<your cluster name> environment \<your environment> externalsecretsstore secretproviderclass resolve satellite secrets note the token will be mounted from /mnt/secrets store/resolve satellite token ensure your secret contains the token value in plain text or as a json object with a token key integration token configuration integration tokens authenticate the satellite with on premises data sources like grafana, elasticsearch, splunk, and others the setup pattern is similar to ingest tokens—you create a kubernetes secret, then reference it in your values file step 1 create the kubernetes secret create a secret containing your integration credentials most integrations need only an api token create integration secret kubectl create secret generic \<secret name> from literal=token="\<your api token>" example for logz io kubectl create secret generic logz token from literal=apitoken="your logz token" for integrations requiring multiple credentials (username/password, multiple keys), use multiple from literal flags see secret management /#reference kubernetes secret operations below for more examples step 2 configure integration in values file reference the secret in your resolve values yaml file see the reference schema docid\ cgezyiqyrhpra0d8gnqla for integration specific connection parameters resolve values yaml integrations \<integration name> type "\<integration type>" create true secretname \<secret name> connection \# see integration specific documentation for connection parameters example for logz io resolve values yaml integrations logzio type "logzio" create true secretname logz token connection url api logz io the helm chart includes a file watcher that automatically detects integration updates, removing the need to manually restart the satellite after each change see resolve satellite docid\ k6ksy4pbgdi7fe4ukhgfo for deployment instructions reference kubernetes secret operations this section provides reference commands for creating and managing kubernetes secrets creating secrets create a secret with a single key single key secret kubectl create secret generic \<secret name> from literal=\<key>="\<your token>" create a secret with multiple keys multiple key secret kubectl create secret generic \<secret name> \\ \ from literal=\<key1>="\<value1>" \\ \ from literal=\<key2>="\<value2>" resulting secret secret yaml apiversion v1 kind secret metadata name \<secret name> type opaque data \<key> \<value> # base64 encoded value verifying secrets check if your secret exists check secret kubectl get secret \<secret name> verify secret contents (be careful with sensitive data) verify contents kubectl get secret \<secret name> o jsonpath='{ data \<key>}' | base64 d