mirror of
https://github.com/awatertrevi/infisical.git
synced 2026-10-07 07:27:58 +00:00
Merge pull request #1480 from akhilmhdh/docs/rotation-doc-update
docs: improved secret rotation documentation with better understanding
This commit is contained in:
Maidul Islam
@@ -1,37 +1,102 @@
|
|||||||
---
|
---
|
||||||
title: "MySQL/MariaDB"
|
title: "MySQL/MariaDB"
|
||||||
description: "Rotated database user password of a MySQL or MariaDB"
|
description: "How to rotate MySQL/MariaDB database user passwords"
|
||||||
---
|
---
|
||||||
|
|
||||||
Infisical will update periodically the provided database user's password.
|
The Infisical MySQL secret rotation allows you to automatically rotate your MySQL database user's password at a predefined interval.
|
||||||
|
|
||||||
<Warning>
|
|
||||||
At present Infisical do require access to your database. We will soon be released Infisical agent based rotation which would help you rotate without direct database access from Infisical cloud.
|
|
||||||
</Warning>
|
|
||||||
|
|
||||||
## Working
|
## Prerequisite
|
||||||
|
|
||||||
1. User's has to create the two user's for Infisical to rotate and provide them required database access
|
1. Create two users with the required permission in your MySQL instance. We'll refer to them as `user-a` and `user-b`.
|
||||||
2. Infisical will connect with your database with admin access
|
2. Create another MySQL user with just the permission to update the passwords of `user-a` and `user-b`. We'll refer to this user as the `admin` user.
|
||||||
3. If last rotated one was username1, then username2 is chosen to be rotated
|
|
||||||
5. Update it's password with random value
|
To learn more about MySQL permission system, please visit this [documentation](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html).
|
||||||
6. After testing it gets saved to the provided secret mapping
|
|
||||||
|
## How it works
|
||||||
|
|
||||||
|
1. Infisical connects to your database using the provided `admin` user account.
|
||||||
|
2. A random value is generated and the password for `user-a` is updated with the new value.
|
||||||
|
3. The new password is then tested by logging into the database
|
||||||
|
4. If test is success, it's saved to the output secret mappings so that rest of the system gets the newly rotated value(s).
|
||||||
|
5. The process is then repeated for `user-b` on the next rotation.
|
||||||
|
6. The cycle repeats until secret rotation is deleted/stopped.
|
||||||
|
|
||||||
## Rotation Configuration
|
## Rotation Configuration
|
||||||
|
|
||||||
1. Head over to Secret Rotation configuration page of your project by clicking on side bar `Secret Rotation`
|
<Steps>
|
||||||
2. Click on `MySQL`
|
<Step title="Open Secret Rotation Page">
|
||||||
3. Provide the inputs
|
Head over to Secret Rotation configuration page of your project by clicking on `Secret Rotation` in the left side bar
|
||||||
- Admin Username: DB admin username
|
</Step>
|
||||||
- Admin Password: DB admin password
|
<Step title="Click on MySQL card" />
|
||||||
- Host: DB host
|
<Step title="Provide the inputs">
|
||||||
- Port: DB port(number)
|
<ParamField path="Admin Username" type="string" required>
|
||||||
- Username1: The first username in two to rotate
|
Rotator admin username
|
||||||
- Username2: The second username in two to rotate
|
</ParamField>
|
||||||
- CA: Certificate to connect with database(string)
|
|
||||||
4. Final step
|
|
||||||
- Select `Environment`, `Secret Path` and `Interval` to rotate the secrets
|
|
||||||
- Finally select the secrets in your provided board to replace with new secret after each rotation
|
|
||||||
- Your done and good to go.
|
|
||||||
|
|
||||||
Congrats. You have 10x your MySQL/MariaDB access security.
|
<ParamField path="Admin password" type="string" required>
|
||||||
|
Rotator admin password
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
|
<ParamField path="Host" type="string" required>
|
||||||
|
Database host url
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
|
<ParamField path="Port" type="number" required>
|
||||||
|
Database port number
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
|
<ParamField path="Username1" type="string" required>
|
||||||
|
The first username of two to rotate - `user-a`
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
|
<ParamField path="Username2" type="string" required>
|
||||||
|
The second username of two to rotate - `user-b`
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
|
<ParamField path="CA" type="string">
|
||||||
|
Optional database certificate to connect with database
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
|
</Step>
|
||||||
|
<Step title="Configure the output secret mapping">
|
||||||
|
When a secret rotation is successful, the updated values needs to be saved to an existing key(s) in your project.
|
||||||
|
|
||||||
|
<ParamField path="Environment" type="string" required>
|
||||||
|
The environment where the rotated credentials should be mapped to.
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
|
<ParamField path="Secret Path" type="string" required>
|
||||||
|
The secret path where the rotated credentials should be mapped to.
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
|
<ParamField path="Interval" type="number" required>
|
||||||
|
What interval should the credentials be rotated in days.
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
|
<ParamField path="DB USERNAME" type="string" required>
|
||||||
|
Select an existing secret key where the rotated database username value should be saved to.
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
|
<ParamField path="DB PASSWORD" type="string" required>
|
||||||
|
Select an existing select key where the rotated database password value should be saved to.
|
||||||
|
</ParamField>
|
||||||
|
</Step>
|
||||||
|
</Steps>
|
||||||
|
|
||||||
|
## FAQ
|
||||||
|
|
||||||
|
<AccordionGroup>
|
||||||
|
<Accordion title="Why can't we delete the other user when rotating?">
|
||||||
|
When a system has multiple nodes by horizontal scaling, redeployment doesn't happen instantly.
|
||||||
|
|
||||||
|
This means that when the secrets are rotated, and the redeployment is triggered, the existing system will still be using the old credentials until the change rolls out.
|
||||||
|
|
||||||
|
To avoid causing failure for them, the old credentials are not removed. Instead, in the next rotation, the previous user's credentials are updated.
|
||||||
|
</Accordion>
|
||||||
|
<Accordion title="Why do you need root user account?">
|
||||||
|
The admin account is used by Infisical to update the credentials for `user-a` and `user-b`.
|
||||||
|
|
||||||
|
You don't need to grant all permission for your admin account but rather just the permissions to update both of the user's passwords.
|
||||||
|
</Accordion>
|
||||||
|
</AccordionGroup>
|
||||||
|
|||||||
@@ -1,33 +1,104 @@
|
|||||||
---
|
---
|
||||||
title: "PostgreSQL/CockroachDB"
|
title: "PostgreSQL/CockroachDB"
|
||||||
description: "Rotated database user password of a PostgreSQL or Cockroach DB"
|
description: "How to rotate postgreSQL/cockroach database user passwords"
|
||||||
---
|
---
|
||||||
|
|
||||||
Infisical will update periodically the provided database user's password.
|
The Infisical Postgres secret rotation allows you to automatically rotate your Postgres database user's password at a predefined interval.
|
||||||
|
|
||||||
## Working
|
|
||||||
|
|
||||||
1. User's has to create the two user's for Infisical to rotate and provide them required database access.
|
## Prerequisite
|
||||||
2. Infisical will connect with your database with admin access.
|
|
||||||
3. If last rotated one was username1, then username2 is chosen to be rotated.
|
1. Create two users with the required permission in your PostgreSQL instance. We'll refer to them as `user-a` and `user-b`.
|
||||||
5. Update it's password with random value.
|
2. Create another PostgreSQL user with just the permission to update the passwords of `user-a` and `user-b`. We'll refer to this user as the `admin` user.
|
||||||
6. After testing it gets saved to the provided secret mapping.
|
|
||||||
|
To learn more about Postgres permission system, please visit this [documentation](https://www.postgresql.org/docs/9.1/sql-grant.html).
|
||||||
|
|
||||||
|
|
||||||
|
## How it works
|
||||||
|
|
||||||
|
1. Infisical connects to your database using the provided `admin` user account.
|
||||||
|
2. A random value is generated and the password for `user-a` is updated with the new value.
|
||||||
|
3. The new password is then tested by logging into the database
|
||||||
|
4. If test is success, it's saved to the output secret mappings so that rest of the system gets the newly rotated value(s).
|
||||||
|
5. The process is then repeated for `user-b` on the next rotation.
|
||||||
|
6. The cycle repeats until secret rotation is deleted/stopped.
|
||||||
|
|
||||||
## Rotation Configuration
|
## Rotation Configuration
|
||||||
|
|
||||||
1. Head over to Secret Rotation configuration page of your project by clicking on side bar `Secret Rotation`
|
<Steps>
|
||||||
2. Click on `PostgreSQL`
|
<Step title="Open Secret Rotation Page">
|
||||||
3. Provide the inputs
|
Head over to Secret Rotation configuration page of your project by clicking on `Secret Rotation` in the left side bar
|
||||||
- Admin Username: DB admin username
|
</Step>
|
||||||
- Admin Password: DB admin password
|
<Step title="Click on PostgresSQL card" />
|
||||||
- Host: DB host
|
|
||||||
- Port: DB port(number)
|
|
||||||
- Username1: The first username in two to rotate
|
|
||||||
- Username2: The second username in two to rotate
|
|
||||||
- CA: Certificate to connect with database(string)
|
|
||||||
4. Final step
|
|
||||||
- Select `Environment`, `Secret Path` and `Interval` to rotate the secrets
|
|
||||||
- Finally select the secrets in your provided board to replace with new secret after each rotation
|
|
||||||
- Your done and good to go.
|
|
||||||
|
|
||||||
Congratulations. You have improved your PostgreSQL/CockroachDB access security.
|
<Step title="Provide the inputs">
|
||||||
|
<ParamField path="Admin Username" type="string" required="true">
|
||||||
|
Rotator admin username
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
|
<ParamField path="Admin password" type="string" required="true">
|
||||||
|
Rotator admin password
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
|
<ParamField path="Host" type="string" required="true">
|
||||||
|
Database host url
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
|
<ParamField path="Port" type="number" required="true">
|
||||||
|
Database port number
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
|
<ParamField path="Username1" type="string" required="true">
|
||||||
|
The first username of two to rotate - `user-a`
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
|
<ParamField path="Username2" type="string" required="true">
|
||||||
|
The second username of two to rotate - `user-b`
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
|
<ParamField path="CA" type="string" optional>
|
||||||
|
Optional database certificate to connect with database
|
||||||
|
</ParamField>
|
||||||
|
</Step>
|
||||||
|
<Step title="Configure the output secret mapping">
|
||||||
|
|
||||||
|
When a secret rotation is successful, the updated values needs to be saved to an existing key(s) in your project.
|
||||||
|
|
||||||
|
<ParamField path="Environment" type="string" required>
|
||||||
|
The environment where the rotated credentials should be mapped to.
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
|
<ParamField path="Secret Path" type="string" required>
|
||||||
|
The secret path where the rotated credentials should be mapped to.
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
|
<ParamField path="Interval" type="number" required>
|
||||||
|
What interval should the credentials be rotated in days.
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
|
<ParamField path="DB USERNAME" type="string" required>
|
||||||
|
Select an existing secret key where the rotated database username value should be saved to.
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
|
<ParamField path="DB PASSWORD" type="string" required>
|
||||||
|
Select an existing select key where the rotated database password value should be saved to.
|
||||||
|
</ParamField>
|
||||||
|
</Step>
|
||||||
|
</Steps>
|
||||||
|
|
||||||
|
## FAQ
|
||||||
|
|
||||||
|
<AccordionGroup>
|
||||||
|
<Accordion title="Why can't we delete the other user when rotating?">
|
||||||
|
When a system has multiple nodes by horizontal scaling, redeployment doesn't happen instantly.
|
||||||
|
|
||||||
|
This means that when the secrets are rotated, and the redeployment is triggered, the existing system will still be using the old credentials until the change rolls out.
|
||||||
|
|
||||||
|
To avoid causing failure for them, the old credentials are not removed. Instead, in the next rotation, the previous user's credentials are updated.
|
||||||
|
</Accordion>
|
||||||
|
<Accordion title="Why do you need root user account?">
|
||||||
|
The admin account is used by Infisical to update the credentials for `user-a` and `user-b`.
|
||||||
|
|
||||||
|
You don't need to grant all permission for your admin account but rather just the permissions to update both of the user's passwords.
|
||||||
|
</Accordion>
|
||||||
|
</AccordionGroup>
|
||||||
|
|||||||
@@ -1,31 +1,58 @@
|
|||||||
---
|
---
|
||||||
title: "Twilio SendGrid"
|
title: "Twilio SendGrid"
|
||||||
description: "Rotate Twilio SendGrid API keys"
|
description: "How to rotate Twilio SendGrid API keys"
|
||||||
---
|
---
|
||||||
|
|
||||||
Twilio SendGrid is a cloud-based email delivery platform that helps businesses send transactional and marketing emails.
|
Eliminate the use of long lived secrets by rotating Twilio SendGrid API keys with Infisical.
|
||||||
It uses an API key to do various operations. Using Infisical you can easily dynamically change the keys.
|
|
||||||
|
|
||||||
## Working
|
## Prerequisite
|
||||||
|
|
||||||
1. Infisical will need an admin token of SendGrid to create API keys dynamically.
|
You will need a valid SendGrid admin key with the necessary scope to create additional API keys.
|
||||||
2. Using the given admin token and scope by user Infisical will create and rotate API keys periodically
|
|
||||||
3. Under the hood infisical uses [SendGrid API](https://docs.sendgrid.com/api-reference/api-keys/create-api-keys)
|
Follow the [SendGrid Docs to create an admin api key](https://docs.sendgrid.com/ui/account-and-settings/api-keys)
|
||||||
|
|
||||||
|
## How it works
|
||||||
|
|
||||||
|
Using the provided admin API key, Infisical will attempt to create child API keys with the specified permissions.
|
||||||
|
New keys will ge generated every time a rotation occurs. Behind the scenes, Infisical uses the [SendGrid API](https://docs.sendgrid.com/api-reference/api-keys/create-api-keys) to generate new API keys.
|
||||||
|
|
||||||
## Rotation Configuration
|
## Rotation Configuration
|
||||||
|
|
||||||
1. Head over to Secret Rotation configuration page of your project by clicking on side bar `Secret Rotation`
|
<Steps>
|
||||||
2. Click on `Twilio SendGrid Card`
|
<Step title="Open Secret Rotation Page">
|
||||||
3. Provide the inputs
|
Head over to Secret Rotation configuration page of your project by clicking on `Secret Rotation` in the left side bar
|
||||||
- Admin API Key:
|
</Step>
|
||||||
SendGrid admin key to create lower scoped API keys.
|
<Step title="Click on Twilio SendGrid Card" />
|
||||||
- API Key Scopes
|
<Step title="Provide the inputs">
|
||||||
SendGrid generated API Key's scopes. For more info refer [this doc](https://docs.sendgrid.com/api-reference/api-key-permissions/api-key-permissions)
|
<ParamField path="Admin API Key" type="string" required>
|
||||||
|
SendGrid admin API key with permission to create child scoped API keys.
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
4. Final step
|
<ParamField path="Admin API Key" type="array" required>
|
||||||
- Select `Environment`, `Secret Path` and `Interval` to rotate the secrets
|
The permissions that the newly generated API keys will have. To view possible permissions, visit [this documentation](https://docs.sendgrid.com/api-reference/api-key-permissions/api-key-permissions).
|
||||||
- Finally select the secrets in your provided board to replace with new secret after each rotation
|
Permissions must be entered as a list of strings.
|
||||||
- Your done and good to go.
|
|
||||||
|
|
||||||
Now your output mapped secret value will be replaced periodically by SendGrid.
|
|
||||||
|
|
||||||
|
Example: `["user.profile.read", "user.profile.update"]`
|
||||||
|
</ParamField>
|
||||||
|
</Step>
|
||||||
|
<Step title="Configure the output secret mapping">
|
||||||
|
When a secret rotation is successful, the updated values needs to be saved to an existing key(s) in your project.
|
||||||
|
<ParamField path="Environment" type="string" required>
|
||||||
|
The environment where the rotated credentials should be mapped to.
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
|
<ParamField path="Secret Path" type="string" required>
|
||||||
|
The secret path where the rotated credentials should be mapped to.
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
|
<ParamField path="Interval" type="number" required>
|
||||||
|
What interval should the credentials be rotated in days.
|
||||||
|
</ParamField>
|
||||||
|
|
||||||
|
<ParamField path="API KEY" type="string" required>
|
||||||
|
Select an existing select key where the newly rotated API key will get saved to.
|
||||||
|
</ParamField>
|
||||||
|
</Step>
|
||||||
|
</Steps>
|
||||||
|
|
||||||
|
Now your output mapped secret value will be replaced periodically by SendGrid.
|
||||||
|
|||||||
Binary file not shown.
|
After Width: | Height: | Size: 65 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 66 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 57 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 42 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 52 KiB |
Reference in New Issue
Block a user