Secrets Management
The GoodData.CN helm chart uses several credentials which are stored in a plain text format directly in the chart. We do not recommend this setup for production environments as it is an insecure method of protecting data. Instead, proper secrets management should be used.
Note
If you just want to evaluate GoodData.CN helm chart installation, you do not need to setup secrets. The default secrets will be used.
Provide existing secrets
It is possible to provide existing Kubernetes secrets with the required credentials. You can provide the credentials to the secrets in the following ways.
Postgres Admin Secrets
Required Format:
apiVersion: v1
kind: Secret
metadata:
name: your-postgres-secret
type: Opaque
data:
postgresql-password: "Zm9vYmFy"
repmgr-password: "Q3RicU40WmVvWA=="
This secret is referenced in the GoodData.CN helm chart as shown below.
Installation with Included Postgres Helm Chart
You can reference the secret in the following ways:
deployPostgresHA: true
global:
postgresql:
existingSecret: your-postgres-secret
deployPostgresHA: true
postgresql-ha:
postgresql:
existingSecret: your-postgres-secret
Note
While you can define it both ways, the global setting has priority.
Installation with external Postgres
deployPostgresHA: false
service:
postgres:
existingSecret: your-postgres-secret
Metadata Bootstrap secret
Required Format:
apiVersion: v1
kind: Secret
metadata:
name: your-metadata-bootstrap-secret
type: Opaque
data:
user: "Zm9vYmFy"
password: "Q3RicU40WmVvWA=="
You can reference the secret in following way:
metadataApi:
bootstrap:
existingSecret: your-metadata-bootstrap-secret
Export Controller AWS secret
Export controller supports storing exported results on AWS S3 object storage. If your cluster doesn’t support IAM roles for Service Accounts (IRSA), you can store credentials of dedicated IAM user in Kubernetes Secret and pass the name of this secret during helm chart installation.
Required format:
apiVersion: v1
kind: Secret
metadata:
name: export-controller-iam
type: Opaque
data:
aws-access-key-id: "QUtJQTAxMjM0NTY3ODkwMTIzNDU="
aws-secret-access-key: "Yys4OXR0NFF0SWUxaHpReEoxcUhod3l3MnRKS2ZGZmQ0SHAxUkUvQQ=="
Alternatively, you can create this secret with command like:
kubectl -n gooddata-cn create secret generic export-controller-iam \
--from-literal aws-access-key-id=AKIA0123456789012345 \
--from-literal aws-secret-access-key=c+89tt4QtIe1hzQxJ1qHhwyw2tJKfFfd4Hp1RE/A
You can reference the secret in customized values.yaml in following way:
exportController:
# for us-east-1 region, the format is s3://<bucket>.s3.amazonaws.com/<prefix>
# for other regions, the format is s3://<bucket>.s3-<region>.amazonaws.com/<prefix>
fileStorageBaseUrl: s3://my-bucket.s3-us-east-2.amazonaws.com/gooddata-cn-exports
existingSecret: export-controller-iam
If you plan to deploy to AWS Elastic Kubernetes Cluster (EKS), it’s recommended to create dedicated IAM role (e.g. gooddata-cn-role),
attach a policy allowing read and write access to chosen S3 bucket and assign this role to GoodData.CN ServiceAccount.
This can be done by adding annotation to ServiceAccount:
serviceAccount:
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/gooddata-cn-role
Then you don’t need to set explicit credentials for allowing access to this bucket.
Dedicated users and secrets for Postgres databases
GoodData.CN uses Postgres as internal database. There are two, respectively three databases, based on whether you choose to use the internal OIDC identity provider or not:
- Metadata database
- SqlExecutor database
- The internal OIDC identity provider database
It is encouraged to use dedicated credentials on production environments.
Warning
Setting up the dedicated credentials can be done during initial installation only. Specifying dedicated credentials during upgrades will very likely lead to complete service unavailability; based on used Postgres database provider.
Please note that you might need to provision these dedicated users on the Postgres database. We do create the users automatically, but you might need to create them on your cloud provider using the proper API. Also, if you decide to deploy PostgresHA Helm chart, you need to define these users in the pgpool configuration in the values.yaml.
Metadata Postgres database credentials
The Metadata Postgres credentials can be supplied directly in the values.yaml. However, it is recommended to set only user in values.yaml
and the password should be provided as a dedicated secret.
Required Format:
apiVersion: v1
kind: Secret
metadata:
name: your-md-postgres-secret
type: Opaque
data:
postgresql-password: "Zm9vYmFy"
You can set the Metadata user and reference the secret in the following way:
metadataApi:
database:
name: md
user: 'md'
password: ''
existingSecret: your-md-postgres-secret
SqlExecutor Postgres database credentials
The SqlExecutor Postgres credentials can be supplied directly in the values.yaml. However, it is recommended to set only user in values.yaml
and the password should be provided as a dedicated secret.
Required Format:
apiVersion: v1
kind: Secret
metadata:
name: your-sqlexec-postgres-secret
type: Opaque
data:
postgresql-password: "Zm9vYmFy"
You can set the Metadata user and reference the secret in the following way:
sqlExecutor:
database:
name: execution
user: 'execution'
password: ''
existingSecret: your-sqlexec-postgres-secret
Internal OIDC Identity Provider Postgres database credentials
The Postgres credentials for the internal OIDC identity provider can be supplied directly in the values.yaml. However, it is recommended to set only user in values.yaml
and the password should be provided as a dedicated secret.
Required Format:
apiVersion: v1
kind: Secret
metadata:
name: your-dex-postgres-secret
type: Opaque
data:
postgresql-password: "Zm9vYmFy"
You can set the internal OIDC identity provider user and reference the secret in the following way:
config:
database:
name: dex
user: 'dex'
password: ''
existingSecret: your-dex-postgres-secret
Secrets management
GoodData.CN is un-opinionated about how secrets are managed as long they are secure. There are many ways to do it and there’s no one-size-fits-all solution. Here are some solutions for managing secrets: