mirror of
https://github.com/awatertrevi/infisical.git
synced 2026-09-22 13:39:35 +00:00
Fix merge conflicts
This commit is contained in:
Tuan Dang
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: "Project Access Requests"
|
||||
description: "Learn how to request access to projects in Infisical."
|
||||
---
|
||||
|
||||
The Project Access Request feature allows users to view all projects within organization, including those they don't currently have access to.
|
||||
Users can request access to these projects by submitting a request that automatically notifies project administrators via email, along with any comments provided by the user.
|
||||
|
||||
# Viewing Available Projects
|
||||
|
||||
From the Infisical dashboard, users can view all projects within the organization:
|
||||
|
||||
1. Navigate to the main dashboard after logging in
|
||||
2. The overview page for each product displays two tabs:
|
||||
|
||||
- **My Projects**: Projects you currently have access to
|
||||
- **All Projects**: Complete list of projects in the organization
|
||||
|
||||
|
||||
|
||||
# Requesting Access to a Project
|
||||
|
||||
To request access to a project you don't currently have access for:
|
||||
|
||||
1. Click the **Request Access** button next to the project name
|
||||
|
||||
|
||||
2. Add a comment explaining why you need access
|
||||
|
||||
|
||||
3. Click **Submit Request**
|
||||
|
||||
<Info>
|
||||
Project administrators will receive email notification with details regarding
|
||||
the access request.
|
||||
</Info>
|
||||
@@ -4,13 +4,13 @@ description: "View and manage resources across your organization"
|
||||
---
|
||||
|
||||
<Note>
|
||||
The Organization Admin Console can only be accessed by organization members with admin status.
|
||||
The Organization Admin Console can only be accessed by organization members
|
||||
with admin status.
|
||||
</Note>
|
||||
|
||||
|
||||
## Accessing the Organization Admin Console
|
||||
|
||||
On the sidebar, tap on your initials to access the settings dropdown and press the **Organization Admin Console** option.
|
||||
On the sidebar, hover over **Admin** to access the settings dropdown and press the **Organization Admin Console** option.
|
||||
|
||||
|
||||
|
||||
@@ -20,12 +20,9 @@ The Projects tab lists all the projects within your organization, including thos
|
||||
|
||||
|
||||
|
||||
|
||||
### Accessing a Project in Your Organization
|
||||
|
||||
You can access a project that you are not a member of by tapping on the options menu of the project row and pressing the **Access** button.
|
||||
Doing so will grant you admin permissions for the selected project and add you as a member.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ customize settings and manage users for their entire Infisical instance.
|
||||
|
||||
## Accessing the Server Admin Console
|
||||
|
||||
On the sidebar, tap on your initials to access the settings dropdown and press the **Server Admin Console** option.
|
||||
On the sidebar, hover over **Admin** to access the settings dropdown and press the **Server Admin Console** option.
|
||||
|
||||
|
||||
|
||||
@@ -40,7 +40,7 @@ If you're using SAML/LDAP/OIDC for only one organization on your instance, you c
|
||||
|
||||
By default, users signing up through SAML/LDAP/OIDC will still need to verify their email address to prevent email spoofing. This requirement can be skipped by enabling the switch to trust logins through the respective method.
|
||||
|
||||
### Notices
|
||||
### Broadcast Messages
|
||||
|
||||
Auth consent content is displayed to users on the login page. They can be used to display important information to users, such as a maintenance message or a new feature announcement. Both HTML and Markdown formatting are supported, allowing for customized styling like below:
|
||||
|
||||
|
||||
@@ -3,19 +3,21 @@ title: "Projects"
|
||||
description: "Learn more and understand the concept of Infisical projects."
|
||||
---
|
||||
|
||||
A project in Infisical belongs to an [organization](./organization) and contains a number of environments, folders, and secrets.
|
||||
Only users and machine identities who belong to a project can access resources inside of it according to predefined permissions.
|
||||
A project in Infisical belongs to an [organization](./organization) and contains a number of environments, folders, and secrets.
|
||||
Only users and machine identities who belong to a project can access resources inside of it according to predefined permissions.
|
||||
|
||||
Infisical also allows users to request project access. Refer to the [project access request section](./access-controls/project-access-requests)
|
||||
|
||||
## Project environments
|
||||
|
||||
For both visual and organizational structure, Infisical allows splitting up secrets into environments (e.g., development, staging, production). In project settings, such environments can be
|
||||
customized depending on the intended use case.
|
||||
For both visual and organizational structure, Infisical allows splitting up secrets into environments (e.g., development, staging, production). In project settings, such environments can be
|
||||
customized depending on the intended use case.
|
||||
|
||||
|
||||
|
||||
## Secrets Overview
|
||||
|
||||
The **Secrets Overview** page captures a birds-eye-view of secrets and [folders](./folder) across environments.
|
||||
The **Secrets Overview** page captures a birds-eye-view of secrets and [folders](./folder) across environments.
|
||||
This is useful for comparing secrets, identifying if anything is missing, and making quick changes.
|
||||
|
||||
|
||||
@@ -98,7 +100,7 @@ Then:
|
||||
- If users B and C fetch the secret D back, they both get the value E.
|
||||
|
||||
<Info>
|
||||
Please keep in mind that secret reminders won't work with personal overrides.
|
||||
Please keep in mind that secret reminders won't work with personal overrides.
|
||||
</Info>
|
||||
|
||||
|
||||
@@ -112,4 +114,3 @@ To view the full details of each secret, you can hover over it and press on the
|
||||
This opens up a side-drawer:
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -11,10 +11,11 @@ This means that updating the value of a base secret propagates directly to other
|
||||
|
||||
|
||||
|
||||
Since secret referencing works by reconstructing values back on the client side, the client, be it a user, service token, or a machine identity, fetching back secrets
|
||||
must be permissioned access to all base and dependent secrets.
|
||||
Since secret referencing reconstructs values on the client side, any client (user, service token, or machine identity) fetching secrets must have proper permissions to access all base and dependent secrets. Without sufficient permissions, secret references will not resolve to their appropriate values.
|
||||
|
||||
For example, to access some secret `A` whose values depend on secrets `B` and `C` from different scopes, a client must have `read` access to the scopes of secrets `A`, `B`, and `C`.
|
||||
For example, if secret A references values from secrets B and C located in different scopes, the client must have read access to all three scopes containing secrets A, B, and C. If permission to any referenced secret is missing, the reference will remain unresolved, potentially causing application errors or unexpected behavior.
|
||||
|
||||
This is an important security consideration when planning your secret access strategy, especially when working with cross-environment or cross-folder references.
|
||||
|
||||
### Syntax
|
||||
|
||||
@@ -28,11 +29,11 @@ Then consider the following scenarios:
|
||||
|
||||
Here are a few more helpful examples for how to reference secrets in different contexts:
|
||||
|
||||
| Reference syntax | Environment | Folder | Secret Key |
|
||||
| --------------------- | ----------- | ------------ | ---------- |
|
||||
| `${KEY1}` | same env | same folder | KEY1 |
|
||||
| `${dev.KEY2}` | `dev` | `/` (root of dev environment) | KEY2 |
|
||||
| `${prod.frontend.KEY2}` | `prod` | `/frontend` | KEY2 |
|
||||
| Reference syntax | Environment | Folder | Secret Key |
|
||||
| ----------------------- | ----------- | ----------------------------- | ---------- |
|
||||
| `${KEY1}` | same env | same folder | KEY1 |
|
||||
| `${dev.KEY2}` | `dev` | `/` (root of dev environment) | KEY2 |
|
||||
| `${prod.frontend.KEY2}` | `prod` | `/frontend` | KEY2 |
|
||||
|
||||
## Secret Imports
|
||||
|
||||
@@ -59,4 +60,12 @@ To reorder a secret import, hover over it and drag the arrows handle to the posi
|
||||
|
||||
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/o11bMU0pXRs?si=dCprt3xLWPrSOJxy" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
|
||||
<iframe
|
||||
width="560"
|
||||
height="315"
|
||||
src="https://www.youtube.com/embed/o11bMU0pXRs?si=dCprt3xLWPrSOJxy"
|
||||
title="YouTube video player"
|
||||
frameborder="0"
|
||||
allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
|
||||
allowfullscreen
|
||||
></iframe>
|
||||
|
||||
@@ -1,139 +1,163 @@
|
||||
---
|
||||
title: "Microsoft SQL Server"
|
||||
description: "Learn how to automatically rotate Microsoft SQL Server user passwords."
|
||||
title: "Microsoft SQL Server Credentials"
|
||||
description: "Learn how to automatically rotate Microsoft SQL Server credentials."
|
||||
---
|
||||
|
||||
The Infisical SQL Server secret rotation allows you to automatically rotate your database users' passwords at a predefined interval.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. Create two SQL Server logins and database users with the required permissions. We'll refer to them as `user-a` and `user-b`.
|
||||
2. Create another SQL Server login with permissions to alter logins for `user-a` and `user-b`. We'll refer to this as the `admin` login.
|
||||
1. Create a [Microsoft SQL Server Connection](/integrations/app-connections/mssql) with the required **Secret Rotation** permissions
|
||||
2. Create two designated database users for Infisical to rotate the credentials for. Be sure to grant each user login permissions for the desired database with the necessary privileges their use case will require.
|
||||
|
||||
Here's how to set up the prerequisites:
|
||||
An example creation statement might look like:
|
||||
```SQL
|
||||
-- create server-level logins
|
||||
CREATE LOGIN [infisical_user_1] WITH PASSWORD = 'my-password';
|
||||
CREATE LOGIN [infisical_user_2] WITH PASSWORD = 'my-password';
|
||||
GRANT CONNECT SQL TO [infisical_user_1];
|
||||
GRANT CONNECT SQL TO [infisical_user_2];
|
||||
|
||||
```sql
|
||||
-- Create the logins (at server level)
|
||||
CREATE LOGIN [user-a] WITH PASSWORD = 'ComplexPassword1';
|
||||
CREATE LOGIN [user-b] WITH PASSWORD = 'ComplexPassword2';
|
||||
-- create database-level users with login from above
|
||||
USE my_database;
|
||||
CREATE USER [infisical_user_1] FOR LOGIN [infisical_user_1];
|
||||
CREATE USER [infisical_user_2] FOR LOGIN [infisical_user_2];
|
||||
|
||||
-- Create database users for the logins (in your specific database)
|
||||
USE [YourDatabase];
|
||||
CREATE USER [user-a] FOR LOGIN [user-a];
|
||||
CREATE USER [user-b] FOR LOGIN [user-b];
|
||||
-- grant relevant permissions
|
||||
GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA::dbo TO [infisical_user_1];
|
||||
GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA::dbo TO [infisical_user_2];
|
||||
```
|
||||
|
||||
-- Grant necessary permissions to the users
|
||||
GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA::dbo TO [user-a];
|
||||
GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA::dbo TO [user-b];
|
||||
<Tip>
|
||||
To learn more about Microsoft SQL Server's permission system, please visit their [documentation](https://learn.microsoft.com/en-us/sql/t-sql/statements/grant-transact-sql?view=sql-server-ver16).
|
||||
</Tip>
|
||||
|
||||
-- Create admin login with permission to alter other logins
|
||||
CREATE LOGIN [admin] WITH PASSWORD = 'AdminComplexPassword';
|
||||
CREATE USER [admin] FOR LOGIN [admin];
|
||||
|
||||
-- Grant permission to alter any login
|
||||
GRANT ALTER ANY LOGIN TO [admin];
|
||||
```
|
||||
## Create a Microsoft SQL Server Credentials Rotation in Infisical
|
||||
|
||||
To learn more about SQL Server's permission system, please visit this [documentation](https://learn.microsoft.com/en-us/sql/relational-databases/security/authentication-access/getting-started-with-database-engine-permissions).
|
||||
<Tabs>
|
||||
<Tab title="Infisical UI">
|
||||
1. Navigate to your Secret Manager Project's Dashboard and select **Add Secret Rotation** from the actions dropdown.
|
||||
|
||||
|
||||
## How it works
|
||||
2. Select the **Microsoft SQL Server Credentials** option.
|
||||
|
||||
|
||||
1. Infisical connects to your database using the provided `admin` login credentials.
|
||||
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 successful, 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.
|
||||
3. Select the **Microsoft SQL Server Connection** to use and configure the rotation behavior. Then click **Next**.
|
||||
|
||||
|
||||
## Rotation Configuration
|
||||
- **Microsoft SQL Server Connection** - the connection that will perform the rotation of the configured database user credentials.
|
||||
- **Rotation Interval** - the interval, in days, that once elapsed will trigger a rotation.
|
||||
- **Rotate At** - the local time of day when rotation should occur once the interval has elapsed.
|
||||
- **Auto-Rotation Enabled** - whether secrets should automatically be rotated once the rotation interval has elapsed. Disable this option to manually rotate secrets or pause secret rotation.
|
||||
|
||||
<Steps>
|
||||
<Step title="Open Secret Rotation Page">
|
||||
Head over to Secret Rotation configuration page of your project by clicking on `Secret Rotation` in the left side bar
|
||||
</Step>
|
||||
<Step title="Click on Microsoft SQL Server card" />
|
||||
<Step title="Provide the inputs">
|
||||
<ParamField path="Admin Username" type="string" required>
|
||||
SQL Server admin username
|
||||
</ParamField>
|
||||
4. Input the usernames of the database users created above that will be used for rotation. Then click **Next**.
|
||||
|
||||
|
||||
<ParamField path="Admin password" type="string" required>
|
||||
SQL Server admin password
|
||||
</ParamField>
|
||||
- **Database Username 1** - the username of the first user that will be used for rotation.
|
||||
- **Database Username 2** - the username of the second user that will be used for rotation.
|
||||
|
||||
<ParamField path="Host" type="string" required>
|
||||
SQL Server host url (e.g., your-server.database.windows.net)
|
||||
</ParamField>
|
||||
5. Specify the secret names that the active credentials should be mapped to. Then click **Next**.
|
||||
|
||||
|
||||
<ParamField path="Port" type="number" required>
|
||||
Database port number (default: 1433)
|
||||
</ParamField>
|
||||
- **Username** - the name of the secret that the active username will be mapped to.
|
||||
- **Password** - the name of the secret that the active password will be mapped to.
|
||||
|
||||
<ParamField path="Database" type="string" required>
|
||||
Database name (default: master)
|
||||
</ParamField>
|
||||
6. Give your rotation a name and description (optional). Then click **Next**.
|
||||
|
||||
|
||||
<ParamField path="Username1" type="string" required>
|
||||
The first login name to rotate - `user-a`
|
||||
</ParamField>
|
||||
- **Name** - the name of the secret rotation configuration. Must be slug-friendly.
|
||||
- **Description** (optional) - a description of this rotation configuration.
|
||||
|
||||
<ParamField path="Username2" type="string" required>
|
||||
The second login name to rotate - `user-b`
|
||||
</ParamField>
|
||||
7. Review your configuration, then click **Create Secret Rotation**.
|
||||
|
||||
|
||||
<ParamField path="CA" type="string">
|
||||
Optional database certificate to connect with database
|
||||
</ParamField>
|
||||
8. Your **Microsoft SQL Server Credentials** are now available for use via the mapped secrets.
|
||||
|
||||
</Tab>
|
||||
<Tab title="API">
|
||||
To create a Microsoft SQL Server Credentials Rotation, make an API request to the [Create Microsoft SQL Server
|
||||
Credentials Rotation](/api-reference/endpoints/secret-rotations/mssql-credentials/create) API endpoint.
|
||||
|
||||
</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.
|
||||
### Sample request
|
||||
|
||||
<ParamField path="Environment" type="string" required>
|
||||
The environment where the rotated credentials should be mapped to.
|
||||
</ParamField>
|
||||
```bash Request
|
||||
curl --request POST \
|
||||
--url https://us.infisical.com/api/v2/secret-rotations/mssql-credentials \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data '{
|
||||
"name": "my-mssql-rotation",
|
||||
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"description": "my database credentials rotation",
|
||||
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"environment": "dev",
|
||||
"secretPath": "/",
|
||||
"isAutoRotationEnabled": true,
|
||||
"rotationInterval": 30,
|
||||
"rotateAtUtc": {
|
||||
"hours": 0,
|
||||
"minutes": 0
|
||||
},
|
||||
"parameters": {
|
||||
"username1": "infisical_user_1",
|
||||
"username2": "infisical_user_2"
|
||||
},
|
||||
"secretsMapping": {
|
||||
"username": "MSSQL_DB_USERNAME",
|
||||
"password": "MSSQL_DB_PASSWORD"
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
<ParamField path="Secret Path" type="string" required>
|
||||
The secret path where the rotated credentials should be mapped to.
|
||||
</ParamField>
|
||||
### Sample response
|
||||
|
||||
<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 an admin 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 permissions for your admin account but rather just the permission to alter logins (ALTER ANY LOGIN).
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="How does this work with Azure SQL Database?">
|
||||
When using Azure SQL Database, you'll need to:
|
||||
|
||||
1. Use the full server name as your host (e.g., your-server.database.windows.net)
|
||||
2. Ensure your admin account is either the Azure SQL Server admin or an Azure AD account with appropriate permissions
|
||||
3. Configure your Azure SQL Server firewall rules to allow connections from Infisical's IP addresses
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
```bash Response
|
||||
{
|
||||
"secretRotation": {
|
||||
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"name": "my-mssql-rotation",
|
||||
"description": "my database credentials rotation",
|
||||
"secretsMapping": {
|
||||
"username": "MSSQL_DB_USERNAME",
|
||||
"password": "MSSQL_DB_PASSWORD"
|
||||
},
|
||||
"isAutoRotationEnabled": true,
|
||||
"activeIndex": 0,
|
||||
"folderId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"createdAt": "2023-11-07T05:31:56Z",
|
||||
"updatedAt": "2023-11-07T05:31:56Z",
|
||||
"rotationInterval": 30,
|
||||
"rotationStatus": "success",
|
||||
"lastRotationAttemptedAt": "2023-11-07T05:31:56Z",
|
||||
"lastRotatedAt": "2023-11-07T05:31:56Z",
|
||||
"lastRotationJobId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"nextRotationAt": "2023-11-07T05:31:56Z",
|
||||
"connection": {
|
||||
"app": "mssql",
|
||||
"name": "my-mssql-connection",
|
||||
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a"
|
||||
},
|
||||
"environment": {
|
||||
"slug": "dev",
|
||||
"name": "Development",
|
||||
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a"
|
||||
},
|
||||
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"folder": {
|
||||
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"path": "/"
|
||||
},
|
||||
"rotateAtUtc": {
|
||||
"hours": 0,
|
||||
"minutes": 0
|
||||
},
|
||||
"lastRotationMessage": null,
|
||||
"type": "mssql-credentials",
|
||||
"parameters": {
|
||||
"username1": "infisical_user_1",
|
||||
"username2": "infisical_user_2"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
@@ -6,44 +6,92 @@ description: "Learn how to set up automated secret rotation in Infisical."
|
||||
|
||||
## Introduction
|
||||
|
||||
Secret rotation is a process that involves updating secret credentials periodically to minimize the risk of their compromise.
|
||||
Rotating secrets helps prevent unauthorized access to systems and sensitive data by ensuring that old credentials are replaced with new ones regularly.
|
||||
Secret rotation is a security best practice that involves systematically updating credentials and access tokens at regular intervals to minimize the risk of compromise. By proactively replacing existing secrets with new ones, organizations reduce the potential impact of credential theft or leakage.
|
||||
|
||||
Rotated secrets may include, but are not limited to:
|
||||
Examples of rotated secrets include:
|
||||
|
||||
1. API keys for external services;
|
||||
2. Database credentials for various platforms.
|
||||
- API keys and authentication tokens for cloud services and third-party integrations
|
||||
- Database credentials across production, staging, and development environments
|
||||
|
||||
## Rotation Process
|
||||
## How Rotation Works
|
||||
|
||||
The practice of rotating secrets is a systematic and interval-based operation, carried out in four fundamental phases.
|
||||
Secret Rotation systematically replaces secrets at regular intervals while ensuring zero downtime for your applications. This overlapping lifecycle approach maintains continuous availability while enhancing your security posture.
|
||||
|
||||
### 1. Creation
|
||||
### Visual Timeline
|
||||
|
||||
The system initiates the rotation process by either making an API call to an external service or generating a new secret value internally.
|
||||
Upon successful creation, the system will temporarily have three versions of the secret:
|
||||
```mermaid
|
||||
gantt
|
||||
title Credential Lifecycle (Interval = 30 days)
|
||||
dateFormat YYYY-MM-DD
|
||||
axisFormat %b %d
|
||||
|
||||
- **Current active secret**: The one currently in use.
|
||||
- **Future active secret (pending)**: The newly created secret, awaiting validation.
|
||||
- **Previous active secret**: The old secret, soon to be retired.
|
||||
section Credentials 1
|
||||
Active :active, a1, 2023-01-01, 30d
|
||||
Inactive :done, i1, after a1, 30d
|
||||
Revoked :crit, r1, after i1, 30d
|
||||
|
||||
### 2. Testing
|
||||
section Credentials 2
|
||||
Active :active, a2, 2023-01-31, 30d
|
||||
Inactive :done, i2, after a2, 30d
|
||||
Revoked :crit, r2, after i2, 30d
|
||||
|
||||
The newly generated secret is subjected to a verification process to ensure its validity and functionality.
|
||||
This involves conducting checks or tests that simulate actual operations the secret would perform.
|
||||
Only the current active and the future active (pending) secrets are considered operational at this stage, while the previous active secret remains in standby mode.
|
||||
section Credentials 3
|
||||
Active :active, a3, 2023-03-02, 30d
|
||||
Inactive :done, i3, after a3, 30d
|
||||
Revoked :crit, r3, after i3, 30d
|
||||
```
|
||||
|
||||
### 3. Deletion
|
||||
### Credential States
|
||||
|
||||
Post-verification, the system deactivates and deletes the previous active secret, leaving only the current and future active (pending) secrets in the system.
|
||||
Each set of credentials transitions through three distinct states:
|
||||
|
||||
### 4. Activation
|
||||
- **Active**: The primary credentials that will be used for new connections
|
||||
- **Inactive**: These credentials are still valid but are no longer issued for new connections
|
||||
- **Revoked**: Permanently invalidated and deleted from the system
|
||||
|
||||
Finally, the system promotes the future active (pending) secret to be the new current active secret. It then triggers necessary side effects, such as invoking webhooks and generating events, to notify other services of the change.
|
||||
### Rotation Cycle Example (30-Day Interval)
|
||||
|
||||
Using a __30-Day__ rotation interval as an example, here's how the process unfolds:
|
||||
|
||||
1. __Day 0__
|
||||
- `Credential set 1` is issued and set to **Active**
|
||||
- Applications begin using this set for authentication
|
||||
|
||||
2. __Day 30__
|
||||
- `Credential set 2` is issued and set to **Active**
|
||||
- `Credential set 1` transitions to **Inactive** but remains valid
|
||||
- New connections utilize set 2 while existing connections with set 1 continue to work
|
||||
|
||||
<Note>
|
||||
This overlapping validity period ensures that at any point during the active period of a credential set, you are guaranteed that retrieved credentials will be valid for the specified rotation period.
|
||||
</Note>
|
||||
|
||||
3. __Day 60__
|
||||
- `Credential set 3` is issued and set to **Active**
|
||||
- `Credential set 2` transitions to **Inactive** but remains valid
|
||||
- `Credential set 1` is **Revoked** and securely deleted
|
||||
- By now, all applications should have transitioned to using set 2 or 3
|
||||
|
||||
4. __Day 90__
|
||||
- `Credential set 4` is issued and set to **Active**
|
||||
- `Credential set 3` transitions to **Inactive** but remains valid
|
||||
- `Credential set 2` is **Revoked** and securely deleted
|
||||
- The cycle continues...
|
||||
|
||||
### Benefits of This Approach
|
||||
|
||||
- **Zero Downtime**: Applications always have valid credentials
|
||||
- **Grace Period**: The inactive period gives applications time to update to new credentials
|
||||
- **Reduced Risk**: Credentials are regularly cycled, limiting the impact of potential compromise
|
||||
- **Predictable Schedule**: Makes credential management more systematic and easier to automate
|
||||
|
||||
### Implementation Considerations
|
||||
|
||||
- Choose a rotation interval appropriate for your security requirements and operational needs
|
||||
- Ensure your applications can handle credential updates gracefully
|
||||
- Monitor for applications still using credentials nearing revocation
|
||||
|
||||
## Infisical Secret Rotation Strategies
|
||||
|
||||
1. [SendGrid Integration](./sendgrid)
|
||||
2. [PostgreSQL/CockroachDB Implementation](./postgres)
|
||||
3. [MySQL/MariaDB Configuration](./mysql)
|
||||
4. [AWS IAM User](./aws-iam)
|
||||
- [PostgreSQL Credentials](./postgres)
|
||||
- [Microsoft SQL Server Credentials](./mssql)
|
||||
|
||||
@@ -1,104 +1,160 @@
|
||||
---
|
||||
title: "PostgreSQL/CockroachDB"
|
||||
description: "Learn how to automatically rotate PostgreSQL/CockroachDB user passwords."
|
||||
title: "PostgreSQL Credentials"
|
||||
description: "Learn how to automatically rotate PostgreSQL credentials."
|
||||
---
|
||||
|
||||
The Infisical Postgres secret rotation allows you to automatically rotate your Postgres database user's password at a predefined interval.
|
||||
## Prerequisites
|
||||
|
||||
1. Create a [PostgreSQL Connection](/integrations/app-connections/postgres) with the required **Secret Rotation** permissions
|
||||
2. Create two designated database users for Infisical to rotate the credentials for. Be sure to grant each user login permissions for the desired database with the necessary privileges their use case will require.
|
||||
|
||||
An example creation statement might look like:
|
||||
```SQL
|
||||
-- create user roles
|
||||
CREATE USER infisical_user_1 WITH ENCRYPTED PASSWORD 'temporary_password';
|
||||
CREATE USER infisical_user_2 WITH ENCRYPTED PASSWORD 'temporary_password';
|
||||
|
||||
-- grant database connection permissions
|
||||
GRANT CONNECT ON DATABASE my_database TO infisical_user_1;
|
||||
GRANT CONNECT ON DATABASE my_database TO infisical_user_2;
|
||||
|
||||
-- grant relevant table permissions
|
||||
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO infisical_user_1;
|
||||
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO infisical_user_2;
|
||||
```
|
||||
|
||||
<Tip>
|
||||
To learn more about PostgreSQL's permission system, please visit their [documentation](https://www.postgresql.org/docs/current/sql-grant.html).
|
||||
</Tip>
|
||||
|
||||
|
||||
## Prerequisite
|
||||
## Create a PostgreSQL Credentials Rotation in Infisical
|
||||
|
||||
1. Create two users with the required permission in your PostgreSQL instance. We'll refer to them as `user-a` and `user-b`.
|
||||
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.
|
||||
<Tabs>
|
||||
<Tab title="Infisical UI">
|
||||
1. Navigate to your Secret Manager Project's Dashboard and select **Add Secret Rotation** from the actions dropdown.
|
||||
|
||||
|
||||
To learn more about Postgres permission system, please visit this [documentation](https://www.postgresql.org/docs/9.1/sql-grant.html).
|
||||
2. Select the **PostgreSQL Credentials** option.
|
||||
|
||||
|
||||
3. Select the **PostgreSQL Connection** to use and configure the rotation behavior. Then click **Next**.
|
||||
|
||||
|
||||
## How it works
|
||||
- **PostgreSQL Connection** - the connection that will perform the rotation of the configured database user credentials.
|
||||
- **Rotation Interval** - the interval, in days, that once elapsed will trigger a rotation.
|
||||
- **Rotate At** - the local time of day when rotation should occur once the interval has elapsed.
|
||||
- **Auto-Rotation Enabled** - whether secrets should automatically be rotated once the rotation interval has elapsed. Disable this option to manually rotate secrets or pause secret rotation.
|
||||
|
||||
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.
|
||||
4. Input the usernames of the database users created above that will be used for rotation. Then click **Next**.
|
||||
|
||||
|
||||
## Rotation Configuration
|
||||
- **Database Username 1** - the username of the first user that will be used for rotation.
|
||||
- **Database Username 2** - the username of the second user that will be used for rotation.
|
||||
|
||||
<Steps>
|
||||
<Step title="Open Secret Rotation Page">
|
||||
Head over to Secret Rotation configuration page of your project by clicking on `Secret Rotation` in the left side bar
|
||||
</Step>
|
||||
<Step title="Click on PostgresSQL card" />
|
||||
5. Specify the secret names that the active credentials should be mapped to. Then click **Next**.
|
||||
|
||||
|
||||
<Step title="Provide the inputs">
|
||||
<ParamField path="Admin Username" type="string" required="true">
|
||||
Rotator admin username
|
||||
</ParamField>
|
||||
- **Username** - the name of the secret that the active username will be mapped to.
|
||||
- **Password** - the name of the secret that the active password will be mapped to.
|
||||
|
||||
<ParamField path="Admin password" type="string" required="true">
|
||||
Rotator admin password
|
||||
</ParamField>
|
||||
6. Give your rotation a name and description (optional). Then click **Next**.
|
||||
|
||||
|
||||
<ParamField path="Host" type="string" required="true">
|
||||
Database host url
|
||||
</ParamField>
|
||||
- **Name** - the name of the secret rotation configuration. Must be slug-friendly.
|
||||
- **Description** (optional) - a description of this rotation configuration.
|
||||
|
||||
<ParamField path="Port" type="number" required="true">
|
||||
Database port number
|
||||
</ParamField>
|
||||
7. Review your configuration, then click **Create Secret Rotation**.
|
||||
|
||||
|
||||
<ParamField path="Username1" type="string" required="true">
|
||||
The first username of two to rotate - `user-a`
|
||||
</ParamField>
|
||||
8. Your **PostgreSQL Credentials** are now available for use via the mapped secrets.
|
||||
|
||||
</Tab>
|
||||
<Tab title="API">
|
||||
To create a PostgreSQL Credentials Rotation, make an API request to the [Create PostgreSQL
|
||||
Credentials Rotation](/api-reference/endpoints/secret-rotations/postgres-credentials/create) API endpoint.
|
||||
|
||||
<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">
|
||||
### Sample request
|
||||
|
||||
When a secret rotation is successful, the updated values needs to be saved to an existing key(s) in your project.
|
||||
```bash Request
|
||||
curl --request POST \
|
||||
--url https://us.infisical.com/api/v2/secret-rotations/postgres-credentials \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data '{
|
||||
"name": "my-pg-rotation",
|
||||
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"description": "my database credentials rotation",
|
||||
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"environment": "dev",
|
||||
"secretPath": "/",
|
||||
"isAutoRotationEnabled": true,
|
||||
"rotationInterval": 30,
|
||||
"rotateAtUtc": {
|
||||
"hours": 0,
|
||||
"minutes": 0
|
||||
},
|
||||
"parameters": {
|
||||
"username1": "infisical_user_1",
|
||||
"username2": "infisical_user_2"
|
||||
},
|
||||
"secretsMapping": {
|
||||
"username": "POSTGRES_DB_USERNAME",
|
||||
"password": "POSTGRES_DB_PASSWORD"
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
<ParamField path="Environment" type="string" required>
|
||||
The environment where the rotated credentials should be mapped to.
|
||||
</ParamField>
|
||||
### Sample response
|
||||
|
||||
<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>
|
||||
```bash Response
|
||||
{
|
||||
"secretRotation": {
|
||||
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"name": "my-pg-rotation",
|
||||
"description": "my database credentials rotation",
|
||||
"secretsMapping": {
|
||||
"username": "POSTGRES_DB_USERNAME",
|
||||
"password": "POSTGRES_DB_PASSWORD"
|
||||
},
|
||||
"isAutoRotationEnabled": true,
|
||||
"activeIndex": 0,
|
||||
"folderId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"createdAt": "2023-11-07T05:31:56Z",
|
||||
"updatedAt": "2023-11-07T05:31:56Z",
|
||||
"rotationInterval": 30,
|
||||
"rotationStatus": "success",
|
||||
"lastRotationAttemptedAt": "2023-11-07T05:31:56Z",
|
||||
"lastRotatedAt": "2023-11-07T05:31:56Z",
|
||||
"lastRotationJobId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"nextRotationAt": "2023-11-07T05:31:56Z",
|
||||
"connection": {
|
||||
"app": "postgres",
|
||||
"name": "my-pg-connection",
|
||||
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a"
|
||||
},
|
||||
"environment": {
|
||||
"slug": "dev",
|
||||
"name": "Development",
|
||||
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a"
|
||||
},
|
||||
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"folder": {
|
||||
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"path": "/"
|
||||
},
|
||||
"rotateAtUtc": {
|
||||
"hours": 0,
|
||||
"minutes": 0
|
||||
},
|
||||
"lastRotationMessage": null,
|
||||
"type": "postgres-credentials",
|
||||
"parameters": {
|
||||
"username1": "infisical_user_1",
|
||||
"username2": "infisical_user_2"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
Reference in New Issue
Block a user