Secrets
How Gaur stores connector credentials, encrypted and never in plain text.
A secret holds the credentials a connector needs to reach its source: a database password, an access key, an API token. You create a secret once, and connectors reuse it for every ingestion and refresh from that source.
Secrets are encrypted
This is the important part.
Every secret is encrypted at rest. Gaur never stores connector credentials in plain text, never writes them to logs, and never returns them through the API. Once a secret is created, its credential values cannot be read back out, only used.
When you look at a secret after creating it, you see its name and connector type, never the password, key, or token inside it. To change a credential, you create a new secret or replace the existing one; you cannot view the stored value.
What a secret contains
A secret has:
- A name, so you can recognize it when picking it during ingestion.
- A connector type, which decides what credential fields it holds.
- The credentials themselves, encrypted.
The connector types are Postgres, MySQL, S3, R2, Stripe, and MotherDuck. Each connector's page lists the exact fields its secret needs:
| Connector | Secret page |
|---|---|
| S3 | Create an S3 secret |
| R2 | Create an R2 secret |
| Postgres | Create a Postgres secret |
| MySQL | Create a MySQL secret |
| MotherDuck | Create a MotherDuck secret |
| Stripe | Create a Stripe secret |
File upload is the one connector that needs no secret, since the data comes straight from your machine.
One secret, many uses
A secret is tied to a source, not to a single ingestion. Once you have a secret for, say, a production database, every table you ingest from that database and every refresh of those tables reuses the same secret. You enter credentials once.
Managing secrets
- Create a secret from the connector flow, or ahead of time, by choosing a connector type and entering its credentials.
- List your secrets to see what is available. You see names and connector types only.
- Delete a secret you no longer need. Connectors that relied on it will need a new secret before their next ingestion or refresh.
Good practice
- Name secrets clearly, for example
prod-postgresoranalytics-s3, so the right one is easy to pick. - Use least-privilege credentials. Give Gaur a read-only database user or a scoped access key wherever the source supports it.
- Rotate at the source. When you rotate a credential in the source system, create a fresh secret with the new value.