mirror of
https://github.com/awatertrevi/infisical.git
synced 2026-09-22 13:39:35 +00:00
Merge branch 'heads/main' into daniel/kms-sign-verify
This commit is contained in:
Daniel Hougaard
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Available"
|
||||
openapi: "GET /api/v1/app-connections/mssql/available"
|
||||
---
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
title: "Create"
|
||||
openapi: "POST /api/v1/app-connections/mssql"
|
||||
---
|
||||
|
||||
<Note>
|
||||
Check out the configuration docs for [Microsoft SQL Server
|
||||
Connections](/integrations/app-connections/mssql) to learn how to obtain the
|
||||
required credentials.
|
||||
</Note>
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Delete"
|
||||
openapi: "DELETE /api/v1/app-connections/mssql/{connectionId}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Get by ID"
|
||||
openapi: "GET /api/v1/app-connections/mssql/{connectionId}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Get by Name"
|
||||
openapi: "GET /api/v1/app-connections/mssql/connection-name/{connectionName}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "List"
|
||||
openapi: "GET /api/v1/app-connections/mssql"
|
||||
---
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
title: "Update"
|
||||
openapi: "PATCH /api/v1/app-connections/mssql/{connectionId}"
|
||||
---
|
||||
|
||||
<Note>
|
||||
Check out the configuration docs for [Microsoft SQL Server
|
||||
Connections](/integrations/app-connections/mssql) to learn how to obtain the
|
||||
required credentials.
|
||||
</Note>
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Available"
|
||||
openapi: "GET /api/v1/app-connections/postgres/available"
|
||||
---
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
title: "Create"
|
||||
openapi: "POST /api/v1/app-connections/postgres"
|
||||
---
|
||||
|
||||
<Note>
|
||||
Check out the configuration docs for [PostgreSQL
|
||||
Connections](/integrations/app-connections/postgres) to learn how to obtain the
|
||||
required credentials.
|
||||
</Note>
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Delete"
|
||||
openapi: "DELETE /api/v1/app-connections/postgres/{connectionId}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Get by ID"
|
||||
openapi: "GET /api/v1/app-connections/postgres/{connectionId}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Get by Name"
|
||||
openapi: "GET /api/v1/app-connections/postgres/connection-name/{connectionName}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "List"
|
||||
openapi: "GET /api/v1/app-connections/postgres"
|
||||
---
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
title: "Update"
|
||||
openapi: "PATCH /api/v1/app-connections/postgres/{connectionId}"
|
||||
---
|
||||
|
||||
<Note>
|
||||
Check out the configuration docs for [PostgreSQL
|
||||
Connections](/integrations/app-connections/postgres) to learn how to obtain the
|
||||
required credentials.
|
||||
</Note>
|
||||
4
docs/api-reference/endpoints/identities/search.mdx
Normal file
4
docs/api-reference/endpoints/identities/search.mdx
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Search"
|
||||
openapi: "POST /api/v1/identities/search"
|
||||
---
|
||||
4
docs/api-reference/endpoints/secret-rotations/list.mdx
Normal file
4
docs/api-reference/endpoints/secret-rotations/list.mdx
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "List"
|
||||
openapi: "GET /api/v2/secret-rotations"
|
||||
---
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
title: "Create"
|
||||
openapi: "POST /api/v2/secret-rotations/mssql-credentials"
|
||||
---
|
||||
|
||||
<Note>
|
||||
Check out the configuration docs for [Microsoft SQL Server
|
||||
Credentials Rotations](/documentation/platform/secret-rotation/mssql) to learn how to obtain the
|
||||
required parameters.
|
||||
</Note>
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Delete"
|
||||
openapi: "DELETE /api/v2/secret-rotations/mssql-credentials/{rotationId}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Get by ID"
|
||||
openapi: "GET /api/v2/secret-rotations/mssql-credentials/{rotationId}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Get by Name"
|
||||
openapi: "GET /api/v2/secret-rotations/mssql-credentials/rotation-name/{rotationName}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Get Credentials by ID"
|
||||
openapi: "GET /api/v2/secret-rotations/mssql-credentials/{rotationId}/generated-credentials"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "List"
|
||||
openapi: "GET /api/v2/secret-rotations/mssql-credentials"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Rotate Secrets"
|
||||
openapi: "POST /api/v2/secret-rotations/mssql-credentials/{rotationId}/rotate-secrets"
|
||||
---
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
title: "Update"
|
||||
openapi: "PATCH /api/v2/secret-rotations/mssql-credentials/{rotationId}"
|
||||
---
|
||||
|
||||
<Note>
|
||||
Check out the configuration docs for [Microsoft SQL Server
|
||||
Credentials Rotations](/documentation/platform/secret-rotation/mssql) to learn how to obtain the
|
||||
required parameters.
|
||||
</Note>
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Options"
|
||||
openapi: "GET /api/v2/secret-rotations/options"
|
||||
---
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
title: "Create"
|
||||
openapi: "POST /api/v2/secret-rotations/postgres-credentials"
|
||||
---
|
||||
|
||||
<Note>
|
||||
Check out the configuration docs for [PostgreSQL
|
||||
Credentials Rotations](/documentation/platform/secret-rotation/postgres) to learn how to obtain the
|
||||
required parameters.
|
||||
</Note>
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Delete"
|
||||
openapi: "DELETE /api/v2/secret-rotations/postgres-credentials/{rotationId}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Get by ID"
|
||||
openapi: "GET /api/v2/secret-rotations/postgres-credentials/{rotationId}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Get by Name"
|
||||
openapi: "GET /api/v2/secret-rotations/postgres-credentials/rotation-name/{rotationName}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Get Credentials by ID"
|
||||
openapi: "GET /api/v2/secret-rotations/postgres-credentials/{rotationId}/generated-credentials"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "List"
|
||||
openapi: "GET /api/v2/secret-rotations/postgres-credentials"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Rotate Secrets"
|
||||
openapi: "POST /api/v2/secret-rotations/postgres-credentials/{rotationId}/rotate-secrets"
|
||||
---
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
title: "Update"
|
||||
openapi: "PATCH /api/v2/secret-rotations/postgres-credentials/{rotationId}"
|
||||
---
|
||||
|
||||
<Note>
|
||||
Check out the configuration docs for [PostgreSQL
|
||||
Credentials Rotations](/documentation/platform/secret-rotation/postgres) to learn how to obtain the
|
||||
required parameters.
|
||||
</Note>
|
||||
@@ -8,6 +8,11 @@ You can use it across various environments, whether it's local development, CI/C
|
||||
|
||||
## Installation
|
||||
|
||||
<Warning>
|
||||
As of 04/08/25, all future releases for Debian/Ubuntu will be distributed via the official Infisical repository at https://artifacts-cli.infisical.com.
|
||||
No new releases will be published for Debian/Ubuntu on Cloudsmith going forward.
|
||||
</Warning>
|
||||
|
||||
<Tabs>
|
||||
<Tab title="MacOS">
|
||||
Use [brew](https://brew.sh/) package manager
|
||||
@@ -93,11 +98,12 @@ You can use it across various environments, whether it's local development, CI/C
|
||||
</Tip>
|
||||
</Tab>
|
||||
<Tab title="Debian/Ubuntu">
|
||||
|
||||
Add Infisical repository
|
||||
|
||||
```bash
|
||||
curl -1sLf \
|
||||
'https://dl.cloudsmith.io/public/infisical/infisical-cli/setup.deb.sh' \
|
||||
'https://artifacts-cli.infisical.com/setup.deb.sh' \
|
||||
| sudo -E bash
|
||||
```
|
||||
|
||||
|
||||
@@ -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>
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 826 KiB |
BIN
docs/images/app-connections/mssql/select-mssql-connection.png
Normal file
BIN
docs/images/app-connections/mssql/select-mssql-connection.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 782 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.2 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 825 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 782 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.2 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 852 KiB After Width: | Height: | Size: 307 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 852 KiB After Width: | Height: | Size: 320 KiB |
BIN
docs/images/platform/project-access-requests/access-comment.png
Normal file
BIN
docs/images/platform/project-access-requests/access-comment.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 305 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 256 KiB |
BIN
docs/images/platform/project-access-requests/request-access.png
Normal file
BIN
docs/images/platform/project-access-requests/request-access.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 268 KiB |
BIN
docs/images/secret-rotations-v2/generic/add-secret-rotation.png
Normal file
BIN
docs/images/secret-rotations-v2/generic/add-secret-rotation.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.2 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 805 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 775 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.2 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 700 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 837 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 744 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 725 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 801 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 774 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.2 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 727 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 822 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 745 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 711 KiB |
134
docs/integrations/app-connections/mssql.mdx
Normal file
134
docs/integrations/app-connections/mssql.mdx
Normal file
@@ -0,0 +1,134 @@
|
||||
---
|
||||
title: "Microsoft SQL Server Connection"
|
||||
description: "Learn how to configure a Microsoft SQL Server Connection for Infisical."
|
||||
---
|
||||
|
||||
Infisical supports connecting to Microsoft SQL Server using database principals.
|
||||
|
||||
## Configure a Microsoft SQL Server Principal for Infisical
|
||||
|
||||
<Steps>
|
||||
<Step title="Create a Principal">
|
||||
Infisical recommends creating a designated server login and database user in your Microsoft SQL Server database for your connection.
|
||||
```SQL
|
||||
-- Create login at the server level
|
||||
CREATE LOGIN [infisical_app] WITH PASSWORD = 'my-password';
|
||||
|
||||
-- Grant server-level connect permission
|
||||
GRANT CONNECT SQL TO [infisical_app];
|
||||
|
||||
-- If you intend to use Platform Managed Credentials (see below)
|
||||
GRANT ALTER ANY LOGIN TO [infisical_app];
|
||||
|
||||
-- Switch to the specific database where you want to create the user
|
||||
USE my_database;
|
||||
|
||||
-- Create the database user mapped to the login
|
||||
CREATE USER [infisical_app] FOR LOGIN [infisical_app];
|
||||
```
|
||||
</Step>
|
||||
<Step title="Grant Relevant Permissions">
|
||||
Depending on how you intend to use your Microsoft SQL Server connection, you'll need to grant one or more of the following permissions.
|
||||
|
||||
<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>
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Secret Rotation">
|
||||
For Secret Rotations, your Infisical user will require the ability to alter other logins' passwords:
|
||||
```SQL
|
||||
GRANT ALTER ANY LOGIN TO infisical_login;
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
</Step>
|
||||
<Step title="Get Connection Details">
|
||||
You'll need the following information to create your Microsoft SQL Server connection:
|
||||
- `host` - The hostname or IP address of your Microsoft SQL Server server
|
||||
- `port` - The port number your Microsoft SQL Server server is listening on (default: 1433)
|
||||
- `database` - The name of the specific database you want to connect to
|
||||
- `username` - The username of the login created in the steps above
|
||||
- `password` - The password of the login created in the steps above
|
||||
- `sslCertificate` (optional) - The SSL certificate required for connection (if configured)
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Create Connection in Infisical
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Infisical UI">
|
||||
1. Navigate to the App Connections tab on the Organization Settings page.
|
||||
|
||||
|
||||
2. Select the **Microsoft SQL Server Connection** option.
|
||||
|
||||
|
||||
3. Select the **Username & Password** method option and provide the details obtained from the previous section and press **Connect to Microsoft SQL Server**.
|
||||
<Note>
|
||||
Optionally, if you'd like Infisical to manage the credentials of this connection, you can enable the Platform Managed Credentials option.
|
||||
If enabled, Infisical will update the password of the connection on creation to prevent external access to this database role.
|
||||
</Note>
|
||||
|
||||
|
||||
4. Your **Microsoft SQL Server Connection** is now available for use.
|
||||
|
||||
</Tab>
|
||||
<Tab title="API">
|
||||
To create a Microsoft SQL Server Connection, make an API request to the [Create Microsoft SQL Server
|
||||
Connection](/api-reference/endpoints/app-connections/mssql/create) API endpoint.
|
||||
|
||||
<Note>
|
||||
Optionally, if you'd like Infisical to manage the credentials of this connection, you can set the `isPlatformManagedCredentials` option to `true`.
|
||||
If enabled, Infisical will update the password of the connection on creation to prevent external access to this database role.
|
||||
</Note>
|
||||
|
||||
### Sample request
|
||||
|
||||
```bash Request
|
||||
curl --request POST \
|
||||
--url https://app.infisical.com/api/v1/app-connections/mssql \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data '{
|
||||
"name": "my-mssql-connection",
|
||||
"method": "username-and-password",
|
||||
"isPlatformManagedCredentials": true,
|
||||
"credentials": {
|
||||
"host": "123.4.5.6",
|
||||
"port": 1433,
|
||||
"database": "default",
|
||||
"username": "infisical_login",
|
||||
"password": "my-password",
|
||||
"sslEnabled": true,
|
||||
"sslRejectUnauthorized": true
|
||||
},
|
||||
}'
|
||||
```
|
||||
|
||||
### Sample response
|
||||
|
||||
```bash Response
|
||||
{
|
||||
"appConnection": {
|
||||
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"name": "my-pg-connection",
|
||||
"version": 1,
|
||||
"orgId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"createdAt": "2023-11-07T05:31:56Z",
|
||||
"updatedAt": "2023-11-07T05:31:56Z",
|
||||
"app": "mssql",
|
||||
"method": "username-and-password",
|
||||
"isPlatformManagedCredentials": true,
|
||||
"credentials": {
|
||||
"host": "123.4.5.6",
|
||||
"port": 1433,
|
||||
"database": "default",
|
||||
"username": "infisical_login",
|
||||
"sslEnabled": true,
|
||||
"sslRejectUnauthorized": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
@@ -74,4 +74,9 @@ in the UI or by passing the associated `connectionId` when generating resources
|
||||
<Note>
|
||||
Infisical is continuously expanding its third-party application support. If your desired application isn't listed,
|
||||
you can still use previous methods of connecting to it such as our Native Integrations.
|
||||
</Note>
|
||||
</Note>
|
||||
|
||||
## Platform Managed Credentials
|
||||
|
||||
Some App Connections support the ability to have their credentials managed by Infisical. By enabling this option,
|
||||
Infisical will modify the credentials to prevent external use of the configured access entity.
|
||||
124
docs/integrations/app-connections/postgres.mdx
Normal file
124
docs/integrations/app-connections/postgres.mdx
Normal file
@@ -0,0 +1,124 @@
|
||||
---
|
||||
title: "PostgreSQL Connection"
|
||||
description: "Learn how to configure a PostgreSQL Connection for Infisical."
|
||||
---
|
||||
|
||||
Infisical supports connecting to PostgreSQL using a database role.
|
||||
|
||||
## Configure a PostgreSQL Role for Infisical
|
||||
|
||||
<Steps>
|
||||
<Step title="Create a Role">
|
||||
Infisical recommends creating a designated role in your PostgreSQL database for your connection.
|
||||
```SQL
|
||||
-- create user role
|
||||
CREATE ROLE infisical_role WITH LOGIN PASSWORD 'my-password';
|
||||
|
||||
-- grant login access to the specified database
|
||||
GRANT CONNECT ON DATABASE my_database TO infisical_role;
|
||||
```
|
||||
</Step>
|
||||
<Step title="Grant Relevant Permissions">
|
||||
Depending on how you intend to use your PostgreSQL connection, you'll need to grant one or more of the following permissions.
|
||||
<Tip>
|
||||
To learn more about PostgreSQL's permission system, please visit their [documentation](https://www.postgresql.org/docs/current/sql-grant.html).
|
||||
</Tip>
|
||||
<Tabs>
|
||||
<Tab title="Secret Rotation">
|
||||
For Secret Rotations, your Infisical user will require the ability to alter other users' passwords:
|
||||
```SQL
|
||||
-- enable permissions to alter login credentials
|
||||
ALTER ROLE infisical_role WITH CREATEROLE;
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
</Step>
|
||||
<Step title="Get Connection Details">
|
||||
You'll need the following information to create your PostgreSQL connection:
|
||||
- `host` - The hostname or IP address of your PostgreSQL server
|
||||
- `port` - The port number your PostgreSQL server is listening on (default: 5432)
|
||||
- `database` - The name of the specific database you want to connect to
|
||||
- `username` - The role name of the login created in the steps above
|
||||
- `password` - The role password of the login created in the steps above
|
||||
- `sslCertificate` (optional) - The SSL certificate required for connection (if configured)
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Create Connection in Infisical
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Infisical UI">
|
||||
1. Navigate to the App Connections tab on the Organization Settings page.
|
||||
|
||||
|
||||
2. Select the **PostgreSQL Connection** option.
|
||||
|
||||
|
||||
3. Select the **Username & Password** method option and provide the details obtained from the previous section and press **Connect to PostgreSQL**.
|
||||
<Note>
|
||||
Optionally, if you'd like Infisical to manage the credentials of this connection, you can enable the Platform Managed Credentials option.
|
||||
If enabled, Infisical will update the password of the connection on creation to prevent external access to this database role.
|
||||
</Note>
|
||||
|
||||
|
||||
4. Your **PostgreSQL Connection** is now available for use.
|
||||
|
||||
</Tab>
|
||||
<Tab title="API">
|
||||
To create a PostgreSQL Connection, make an API request to the [Create PostgreSQL
|
||||
Connection](/api-reference/endpoints/app-connections/postgres/create) API endpoint.
|
||||
|
||||
<Note>
|
||||
Optionally, if you'd like Infisical to manage the credentials of this connection, you can set the `isPlatformManagedCredentials` option to `true`.
|
||||
If enabled, Infisical will update the password of the connection on creation to prevent external access to this database role.
|
||||
</Note>
|
||||
|
||||
### Sample request
|
||||
|
||||
```bash Request
|
||||
curl --request POST \
|
||||
--url https://app.infisical.com/api/v1/app-connections/postgres \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data '{
|
||||
"name": "my-pg-connection",
|
||||
"method": "username-and-password",
|
||||
"isPlatformManagedCredentials": true,
|
||||
"credentials": {
|
||||
"host": "123.4.5.6",
|
||||
"port": 5432,
|
||||
"database": "default",
|
||||
"username": "infisical_role",
|
||||
"password": "my-password",
|
||||
"sslEnabled": true,
|
||||
"sslRejectUnauthorized": true
|
||||
},
|
||||
}'
|
||||
```
|
||||
|
||||
### Sample response
|
||||
|
||||
```bash Response
|
||||
{
|
||||
"appConnection": {
|
||||
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"name": "my-pg-connection",
|
||||
"version": 1,
|
||||
"orgId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"createdAt": "2023-11-07T05:31:56Z",
|
||||
"updatedAt": "2023-11-07T05:31:56Z",
|
||||
"app": "postgres",
|
||||
"method": "username-and-password",
|
||||
"isPlatformManagedCredentials": true,
|
||||
"credentials": {
|
||||
"host": "123.4.5.6",
|
||||
"port": 5432,
|
||||
"database": "default",
|
||||
"username": "infisical_role",
|
||||
"sslEnabled": true,
|
||||
"sslRejectUnauthorized": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
@@ -264,6 +264,7 @@ The available authentication methods are `universalAuth`, `kubernetesAuth`, `aws
|
||||
- `credentialsRef.secretName`: The name of the Kubernetes secret.
|
||||
- `credentialsRef.secretNamespace`: The namespace of the Kubernetes secret.
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
@@ -296,6 +297,9 @@ The available authentication methods are `universalAuth`, `kubernetesAuth`, `aws
|
||||
- `serviceAccountRef`: The name and namespace of the service account that will be used to authenticate with Infisical.
|
||||
- `serviceAccountRef.name`: The name of the service account.
|
||||
- `serviceAccountRef.namespace`: The namespace of the service account.
|
||||
- `autoCreateServiceAccountToken`: If set to `true`, the operator will automatically create a short-lived service account token on-demand for the service account. Defaults to `false`.
|
||||
- `serviceAccountTokenAudiences`: Optionally specify audience for the service account token. This field is only relevant if you have set `autoCreateServiceAccountToken` to `true`. No audience is specified by default.
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
@@ -303,6 +307,9 @@ The available authentication methods are `universalAuth`, `kubernetesAuth`, `aws
|
||||
spec:
|
||||
kubernetesAuth:
|
||||
identityId: <machine-identity-id>
|
||||
autoCreateServiceAccountToken: true # Automatically creates short-lived service account tokens for the service account.
|
||||
serviceAccountTokenAudiences:
|
||||
- <audience> # Optionally specify audience for the service account token. No audience is specified by default.
|
||||
serviceAccountRef:
|
||||
name: <secret-name>
|
||||
namespace: <secret-namespace>
|
||||
|
||||
@@ -291,6 +291,8 @@ After applying the InfisicalPushSecret CRD, you should notice that the secrets y
|
||||
- `serviceAccountRef`: The name and namespace of the service account that will be used to authenticate with Infisical.
|
||||
- `serviceAccountRef.name`: The name of the service account.
|
||||
- `serviceAccountRef.namespace`: The namespace of the service account.
|
||||
- `autoCreateServiceAccountToken`: If set to `true`, the operator will automatically create a short-lived service account token on-demand for the service account. Defaults to `false`.
|
||||
- `serviceAccountTokenAudiences`: Optionally specify audience for the service account token. This field is only relevant if you have set `autoCreateServiceAccountToken` to `true`. No audience is specified by default.
|
||||
|
||||
Example:
|
||||
|
||||
@@ -298,6 +300,9 @@ After applying the InfisicalPushSecret CRD, you should notice that the secrets y
|
||||
spec:
|
||||
kubernetesAuth:
|
||||
identityId: <machine-identity-id>
|
||||
autoCreateServiceAccountToken: true # Automatically creates short-lived service account tokens for the service account.
|
||||
serviceAccountTokenAudiences:
|
||||
- <audience> # Optionally specify audience for the service account token. No audience is specified by default.
|
||||
serviceAccountRef:
|
||||
name: <secret-name>
|
||||
namespace: <secret-namespace>
|
||||
|
||||
@@ -156,157 +156,420 @@ spec:
|
||||
<Accordion title="authentication.kubernetesAuth">
|
||||
The Kubernetes machine identity authentication method is used to authenticate with Infisical. The identity ID is stored in a field in the InfisicalSecret resource. This authentication method can only be used within a Kubernetes environment.
|
||||
|
||||
<Steps>
|
||||
<Step title="Obtaining the token reviewer JWT for Infisical">
|
||||
1.1. Start by creating a service account in your Kubernetes cluster that will be used by Infisical to authenticate with the Kubernetes API Server.
|
||||
<Tabs>
|
||||
<Tab title="Short-lived service account tokens (Recommended)">
|
||||
Short-lived service account tokens are automatically created by the operator and are valid only for a short period of time. This is the recommended approach for using Kubernetes auth in the Infisical Secrets Operator.
|
||||
|
||||
```yaml infisical-service-account.yaml
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: infisical-auth
|
||||
namespace: default
|
||||
<Steps>
|
||||
<Step title="Obtaining the token reviewer JWT for Infisical">
|
||||
**1.1.** Start by creating a reviewer service account in your Kubernetes cluster that will be used by Infisical to authenticate with the Kubernetes API Server.
|
||||
|
||||
```
|
||||
```yaml infisical-reviewer-service-account.yaml
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: infisical-token-reviewer
|
||||
namespace: default
|
||||
|
||||
```
|
||||
kubectl apply -f infisical-service-account.yaml
|
||||
```
|
||||
```
|
||||
|
||||
1.2. Bind the service account to the `system:auth-delegator` cluster role. As described [here](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#other-component-roles), this role allows delegated authentication and authorization checks, specifically for Infisical to access the [TokenReview API](https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-review-v1/). You can apply the following configuration file:
|
||||
```bash
|
||||
kubectl apply -f infisical-reviewer-service-account.yaml
|
||||
```
|
||||
|
||||
```yaml cluster-role-binding.yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
name: role-tokenreview-binding
|
||||
namespace: default
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: system:auth-delegator
|
||||
subjects:
|
||||
- kind: ServiceAccount
|
||||
name: infisical-auth
|
||||
namespace: default
|
||||
```
|
||||
**1.2.** Bind the reviewer service account to the `system:auth-delegator` cluster role. As described [here](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#other-component-roles), this role allows delegated authentication and authorization checks, specifically for Infisical to access the [TokenReview API](https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-review-v1/). You can apply the following configuration file:
|
||||
|
||||
```
|
||||
kubectl apply -f cluster-role-binding.yaml
|
||||
```
|
||||
```yaml infisical-reviewer-cluster-role-binding.yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
name: infisical-token-reviewer-role-binding
|
||||
namespace: default
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: system:auth-delegator
|
||||
subjects:
|
||||
- kind: ServiceAccount
|
||||
name: infisical-token-reviewer
|
||||
namespace: default
|
||||
```
|
||||
|
||||
1.3. Next, create a long-lived service account JWT token (i.e. the token reviewer JWT token) for the service account using this configuration file for a new `Secret` resource:
|
||||
```bash
|
||||
kubectl apply -f infisical-reviewer-cluster-role-binding.yaml
|
||||
```
|
||||
|
||||
```yaml service-account-token.yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
type: kubernetes.io/service-account-token
|
||||
metadata:
|
||||
name: infisical-auth-token
|
||||
annotations:
|
||||
kubernetes.io/service-account.name: "infisical-auth"
|
||||
```
|
||||
**1.3.** Next, create a long-lived service account JWT token (i.e. the token reviewer JWT token) for the service account using this configuration file for a new `Secret` resource:
|
||||
|
||||
```yaml service-account-reviewer-token.yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
type: kubernetes.io/service-account-token
|
||||
metadata:
|
||||
name: infisical-token-reviewer-token
|
||||
annotations:
|
||||
kubernetes.io/service-account.name: "infisical-token-reviewer"
|
||||
```
|
||||
|
||||
|
||||
```
|
||||
kubectl apply -f service-account-token.yaml
|
||||
```
|
||||
```bash
|
||||
kubectl apply -f service-account-reviewer-token.yaml
|
||||
```
|
||||
|
||||
1.4. Link the secret in step 1.3 to the service account in step 1.1:
|
||||
**1.4.** Link the secret in step 1.3 to the service account in step 1.1:
|
||||
|
||||
```bash
|
||||
kubectl patch serviceaccount infisical-auth -p '{"secrets": [{"name": "infisical-auth-token"}]}' -n default
|
||||
```
|
||||
```bash
|
||||
kubectl patch serviceaccount infisical-token-reviewer -p '{"secrets": [{"name": "infisical-token-reviewer-token"}]}' -n default
|
||||
```
|
||||
|
||||
1.5. Finally, retrieve the token reviewer JWT token from the secret.
|
||||
**1.5.** Finally, retrieve the token reviewer JWT token from the secret.
|
||||
|
||||
```bash
|
||||
kubectl get secret infisical-auth-token -n default -o=jsonpath='{.data.token}' | base64 --decode
|
||||
```
|
||||
```bash
|
||||
kubectl get secret infisical-token-reviewer-token -n default -o=jsonpath='{.data.token}' | base64 --decode
|
||||
```
|
||||
|
||||
Keep this JWT token handy as you will need it for the **Token Reviewer JWT** field when configuring the Kubernetes Auth authentication method for the identity in step 2.
|
||||
Keep this JWT token handy as you will need it for the **Token Reviewer JWT** field when configuring the Kubernetes Auth authentication method for the identity in step 2.
|
||||
</Step>
|
||||
|
||||
</Step>
|
||||
<Step title="Creating an identity">
|
||||
To create an identity, head to your Organization Settings > Access Control > Machine Identities and press **Create identity**.
|
||||
|
||||
<Step title="Creating an identity">
|
||||
To create an identity, head to your Organization Settings > Access Control > Machine Identities and press **Create identity**.
|
||||
|
||||
|
||||
|
||||
When creating an identity, you specify an organization level [role](/documentation/platform/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
|
||||
|
||||
When creating an identity, you specify an organization level [role](/documentation/platform/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
|
||||
|
||||
|
||||
|
||||
Now input a few details for your new identity. Here's some guidance for each field:
|
||||
|
||||
Now input a few details for your new identity. Here's some guidance for each field:
|
||||
- Name (required): A friendly name for the identity.
|
||||
- Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.
|
||||
|
||||
- Name (required): A friendly name for the identity.
|
||||
- Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.
|
||||
Once you've created an identity, you'll be prompted to configure the authentication method for it. Here, select **Kubernetes Auth**.
|
||||
|
||||
Once you've created an identity, you'll be prompted to configure the authentication method for it. Here, select **Kubernetes Auth**.
|
||||
<Info>
|
||||
To learn more about each field of the Kubernetes native authentication method, see step 2 of [guide](/documentation/platform/identities/kubernetes-auth#guide).
|
||||
</Info>
|
||||
|
||||
<Info>
|
||||
To learn more about each field of the Kubernetes native authentication method, see step 2 of [guide](/documentation/platform/identities/kubernetes-auth#guide).
|
||||
</Info>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Adding an identity to a project">
|
||||
To allow the operator to use the given identity to access secrets, you will need to add the identity to project(s) that you would like to grant it access to.
|
||||
</Step>
|
||||
<Step title="Adding an identity to a project">
|
||||
To allow the operator to use the given identity to access secrets, you will need to add the identity to project(s) that you would like to grant it access to.
|
||||
|
||||
To do this, head over to the project you want to add the identity to and go to Project Settings > Access Control > Machine Identities and press **Add identity**.
|
||||
To do this, head over to the project you want to add the identity to and go to Project Settings > Access Control > Machine Identities and press **Add identity**.
|
||||
|
||||
Next, select the identity you want to add to the project and the project level role you want to allow it to assume. The project role assigned will determine what project level resources this identity can have access to.
|
||||
Next, select the identity you want to add to the project and the project level role you want to allow it to assume. The project role assigned will determine what project level resources this identity can have access to.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Add your identity ID & service account to your InfisicalSecret resource">
|
||||
Once you have created your machine identity and added it to your project(s), you will need to add the identity ID to your InfisicalSecret resource.
|
||||
In the `authentication.kubernetesAuth.identityId` field, add the identity ID of the machine identity you created.
|
||||
See the example below for more details.
|
||||
</Step>
|
||||
<Step title="Add your Kubernetes service account token to the InfisicalSecret resource">
|
||||
Add the service account details from the previous steps under `authentication.kubernetesAuth.serviceAccountRef`.
|
||||
Here you will need to enter the name and namespace of the service account.
|
||||
The example below shows a complete InfisicalSecret resource with all required fields defined.
|
||||
</Step>
|
||||
</Step>
|
||||
|
||||
</Steps>
|
||||
<Step title="Create a new Kubernetes service account to authenticate with Infisical">
|
||||
You have already created the reviewer service account in step **1.1**. Now, create a new Kubernetes service account that will be used to authenticate with Infisical.
|
||||
This service account will create short-lived tokens that will be used to authenticate with Infisical. The operator itself will handle the creation of these tokens automatically.
|
||||
|
||||
<Info>
|
||||
Make sure to also populate the `secretsScope` field with the project slug
|
||||
_`projectSlug`_, environment slug _`envSlug`_, and secrets path
|
||||
_`secretsPath`_ that you want to fetch secrets from. Please see the example
|
||||
below.
|
||||
</Info>
|
||||
```yaml infisical-service-account.yaml
|
||||
kind: ServiceAccount
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: infisical-service-account
|
||||
```
|
||||
|
||||
## Example
|
||||
```bash
|
||||
kubectl apply -f infisical-service-account.yaml -n default
|
||||
```
|
||||
|
||||
```yaml example-kubernetes-auth.yaml
|
||||
apiVersion: secrets.infisical.com/v1alpha1
|
||||
kind: InfisicalSecret
|
||||
metadata:
|
||||
name: infisicalsecret-sample-crd
|
||||
spec:
|
||||
authentication:
|
||||
kubernetesAuth:
|
||||
identityId: <machine-identity-id>
|
||||
serviceAccountRef:
|
||||
name: <service-account-name>
|
||||
namespace: <service-account-namespace>
|
||||
</Step>
|
||||
|
||||
# secretsScope is identical to the secrets scope in the universalAuth field in this sample.
|
||||
secretsScope:
|
||||
projectSlug: your-project-slug
|
||||
envSlug: prod
|
||||
secretsPath: "/path"
|
||||
recursive: true
|
||||
...
|
||||
```
|
||||
<Step title="Add your identity ID & service account to your InfisicalSecret resource">
|
||||
Once you have created your machine identity and added it to your project(s), you will need to add the identity ID to your InfisicalSecret resource.
|
||||
In the `authentication.kubernetesAuth.identityId` field, add the identity ID of the machine identity you created.
|
||||
See the example below for more details.
|
||||
</Step>
|
||||
<Step title="Add your Kubernetes service account token to the InfisicalSecret resource">
|
||||
Add the service account details from the previous steps under `authentication.kubernetesAuth.serviceAccountRef`.
|
||||
Here you will need to enter the name and namespace of the service account.
|
||||
The example below shows a complete InfisicalSecret resource with all required fields defined.
|
||||
Make sure you set `authentication.kubernetesAuth.autoCreateServiceAccountToken` to `true` to automatically create short-lived service account tokens for the service account.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
<Info>
|
||||
Make sure to also populate the `secretsScope` field with the project slug
|
||||
_`projectSlug`_, environment slug _`envSlug`_, and secrets path
|
||||
_`secretsPath`_ that you want to fetch secrets from. Please see the example
|
||||
below.
|
||||
</Info>
|
||||
|
||||
## Example
|
||||
|
||||
```yaml example-kubernetes-auth.yaml
|
||||
apiVersion: secrets.infisical.com/v1alpha1
|
||||
kind: InfisicalSecret
|
||||
metadata:
|
||||
name: infisicalsecret-sample-crd
|
||||
spec:
|
||||
authentication:
|
||||
kubernetesAuth:
|
||||
identityId: <machine-identity-id>
|
||||
autoCreateServiceAccountToken: true # Automatically creates short-lived service account tokens for the service account.
|
||||
serviceAccountTokenAudiences:
|
||||
- <audience> # Optionally specify audience for the service account token. No audience is specified by default.
|
||||
serviceAccountRef:
|
||||
name: infisical-service-account # The service account we just created in the previous step.
|
||||
namespace: <service-account-namespace>
|
||||
|
||||
# secretsScope is identical to the secrets scope in the universalAuth field in this sample.
|
||||
secretsScope:
|
||||
projectSlug: your-project-slug
|
||||
envSlug: prod
|
||||
secretsPath: "/path"
|
||||
recursive: true
|
||||
...
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab title="Manual long-lived service account tokens">
|
||||
Manual long-lived service account tokens are manually created by the user and are valid indefinitely unless deleted or rotated. In most cases, you should be using the automatic short-lived service account tokens as they are more secure and easier to use.
|
||||
<Steps>
|
||||
<Step title="Obtaining the token reviewer JWT for Infisical">
|
||||
**1.1.** Start by creating a reviewer service account in your Kubernetes cluster that will be used by Infisical to authenticate with the Kubernetes API Server.
|
||||
|
||||
```yaml infisical-reviewer-service-account.yaml
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: infisical-token-reviewer
|
||||
namespace: default
|
||||
|
||||
```
|
||||
|
||||
```bash
|
||||
kubectl apply -f infisical-reviewer-service-account.yaml
|
||||
```
|
||||
|
||||
**1.2.** Bind the reviewer service account to the `system:auth-delegator` cluster role. As described [here](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#other-component-roles), this role allows delegated authentication and authorization checks, specifically for Infisical to access the [TokenReview API](https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-review-v1/). You can apply the following configuration file:
|
||||
|
||||
```yaml infisical-reviewer-cluster-role-binding.yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
name: infisical-token-reviewer-role-binding
|
||||
namespace: default
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: system:auth-delegator
|
||||
subjects:
|
||||
- kind: ServiceAccount
|
||||
name: infisical-token-reviewer
|
||||
namespace: default
|
||||
```
|
||||
|
||||
```bash
|
||||
kubectl apply -f infisical-reviewer-cluster-role-binding.yaml
|
||||
```
|
||||
|
||||
**1.3.** Next, create a long-lived service account JWT token (i.e. the token reviewer JWT token) for the service account using this configuration file for a new `Secret` resource:
|
||||
|
||||
```yaml service-account-reviewer-token.yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
type: kubernetes.io/service-account-token
|
||||
metadata:
|
||||
name: infisical-token-reviewer-token
|
||||
annotations:
|
||||
kubernetes.io/service-account.name: "infisical-token-reviewer"
|
||||
```
|
||||
|
||||
|
||||
```bash
|
||||
kubectl apply -f service-account-reviewer-token.yaml
|
||||
```
|
||||
|
||||
**1.4.** Link the secret in step 1.3 to the service account in step 1.1:
|
||||
|
||||
```bash
|
||||
kubectl patch serviceaccount infisical-token-reviewer -p '{"secrets": [{"name": "infisical-token-reviewer-token"}]}' -n default
|
||||
```
|
||||
|
||||
**1.5.** Finally, retrieve the token reviewer JWT token from the secret.
|
||||
|
||||
```bash
|
||||
kubectl get secret infisical-token-reviewer-token -n default -o=jsonpath='{.data.token}' | base64 --decode
|
||||
```
|
||||
|
||||
Keep this JWT token handy as you will need it for the **Token Reviewer JWT** field when configuring the Kubernetes Auth authentication method for the identity in step 2.
|
||||
</Step>
|
||||
|
||||
<Step title="Creating an identity">
|
||||
To create an identity, head to your Organization Settings > Access Control > Machine Identities and press **Create identity**.
|
||||
|
||||
|
||||
|
||||
When creating an identity, you specify an organization level [role](/documentation/platform/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
|
||||
|
||||
|
||||
|
||||
Now input a few details for your new identity. Here's some guidance for each field:
|
||||
|
||||
- Name (required): A friendly name for the identity.
|
||||
- Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.
|
||||
|
||||
Once you've created an identity, you'll be prompted to configure the authentication method for it. Here, select **Kubernetes Auth**.
|
||||
|
||||
<Info>
|
||||
To learn more about each field of the Kubernetes native authentication method, see step 2 of [guide](/documentation/platform/identities/kubernetes-auth#guide).
|
||||
</Info>
|
||||
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Adding an identity to a project">
|
||||
To allow the operator to use the given identity to access secrets, you will need to add the identity to project(s) that you would like to grant it access to.
|
||||
|
||||
To do this, head over to the project you want to add the identity to and go to Project Settings > Access Control > Machine Identities and press **Add identity**.
|
||||
|
||||
Next, select the identity you want to add to the project and the project level role you want to allow it to assume. The project role assigned will determine what project level resources this identity can have access to.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Create a new Kubernetes service account to authenticate with Infisical">
|
||||
You have already created the reviewer service account in step **1.1**. Now, create a new Kubernetes service account that will be used to authenticate with Infisical.
|
||||
|
||||
```yaml infisical-service-account.yaml
|
||||
kind: ServiceAccount
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: infisical-service-account
|
||||
```
|
||||
|
||||
```bash
|
||||
kubectl apply -f infisical-service-account.yaml -n default
|
||||
```
|
||||
</Step>
|
||||
|
||||
<Step title="Create a service account token for the Kubernetes service account">
|
||||
Create a service account token for the newly created Kubernetes service account from the previous step.
|
||||
|
||||
```yaml infisical-service-account-token.yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
type: kubernetes.io/service-account-token
|
||||
metadata:
|
||||
name: infisical-service-account-token
|
||||
annotations:
|
||||
kubernetes.io/service-account.name: "infisical-service-account"
|
||||
```
|
||||
|
||||
```bash
|
||||
kubectl apply -f infisical-service-account-token.yaml -n default
|
||||
```
|
||||
|
||||
Patch the service account with the newly created service account token.
|
||||
|
||||
```bash
|
||||
kubectl patch serviceaccount infisical-service-account -p '{"secrets": [{"name": "infisical-service-account-token"}]}' -n default
|
||||
```
|
||||
</Step>
|
||||
|
||||
<Step title="Add your identity ID & service account to your InfisicalSecret resource">
|
||||
Once you have created your machine identity and added it to your project(s), you will need to add the identity ID to your InfisicalSecret resource.
|
||||
In the `authentication.kubernetesAuth.identityId` field, add the identity ID of the machine identity you created.
|
||||
See the example below for more details.
|
||||
</Step>
|
||||
<Step title="Add your Kubernetes service account token to the InfisicalSecret resource">
|
||||
Add the service account details from the previous steps under `authentication.kubernetesAuth.serviceAccountRef`.
|
||||
Here you will need to enter the name and namespace of the service account.
|
||||
The example below shows a complete InfisicalSecret resource with all required fields defined.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
<Info>
|
||||
Make sure to also populate the `secretsScope` field with the project slug
|
||||
_`projectSlug`_, environment slug _`envSlug`_, and secrets path
|
||||
_`secretsPath`_ that you want to fetch secrets from. Please see the example
|
||||
below.
|
||||
</Info>
|
||||
|
||||
## Example
|
||||
|
||||
```yaml example-kubernetes-auth.yaml
|
||||
apiVersion: secrets.infisical.com/v1alpha1
|
||||
kind: InfisicalSecret
|
||||
metadata:
|
||||
name: infisicalsecret-sample-crd
|
||||
spec:
|
||||
authentication:
|
||||
kubernetesAuth:
|
||||
identityId: <machine-identity-id>
|
||||
serviceAccountRef:
|
||||
name: infisical-service-account # The service account we just created in the previous step. (*not* the reviewer service account)
|
||||
namespace: <service-account-namespace>
|
||||
|
||||
# secretsScope is identical to the secrets scope in the universalAuth field in this sample.
|
||||
secretsScope:
|
||||
projectSlug: your-project-slug
|
||||
envSlug: prod
|
||||
secretsPath: "/path"
|
||||
recursive: true
|
||||
...
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
</Accordion>
|
||||
|
||||
|
||||
@@ -187,12 +187,15 @@ Supports conditions and permission inversion
|
||||
|
||||
#### Subject: `secret-rotation`
|
||||
|
||||
| Action | Description |
|
||||
| -------- | ------------------------------------- |
|
||||
| `read` | View secret rotation policies |
|
||||
| `create` | Set up automatic secret rotation |
|
||||
| `edit` | Modify rotation schedules or policies |
|
||||
| `delete` | Remove rotation policies |
|
||||
Supports conditions and permission inversion
|
||||
| Action | Description |
|
||||
| ------------------------------ | ---------------------------------------------- |
|
||||
| `read` | View secret rotation configurations |
|
||||
| `read-generated-credentials` | View the generated credentials of a rotation |
|
||||
| `create` | Set up secret rotation configurations |
|
||||
| `edit` | Modify secret rotation configurations |
|
||||
| `rotate-secrets` | Rotate the generated credentials of a rotation |
|
||||
| `delete` | Remove secret rotation configurations |
|
||||
|
||||
#### Subject: `secret-syncs`
|
||||
|
||||
|
||||
@@ -161,6 +161,7 @@
|
||||
"documentation/platform/access-controls/additional-privileges",
|
||||
"documentation/platform/access-controls/temporary-access",
|
||||
"documentation/platform/access-controls/access-requests",
|
||||
"documentation/platform/access-controls/project-access-requests",
|
||||
"documentation/platform/pr-workflows",
|
||||
"documentation/platform/groups"
|
||||
]
|
||||
@@ -177,11 +178,8 @@
|
||||
"group": "Secret Rotation",
|
||||
"pages": [
|
||||
"documentation/platform/secret-rotation/overview",
|
||||
"documentation/platform/secret-rotation/sendgrid",
|
||||
"documentation/platform/secret-rotation/postgres",
|
||||
"documentation/platform/secret-rotation/mysql",
|
||||
"documentation/platform/secret-rotation/mssql",
|
||||
"documentation/platform/secret-rotation/aws-iam"
|
||||
"documentation/platform/secret-rotation/mssql"
|
||||
]
|
||||
},
|
||||
{
|
||||
@@ -210,7 +208,10 @@
|
||||
},
|
||||
{
|
||||
"group": "Gateway",
|
||||
"pages": ["documentation/platform/gateways/overview", "documentation/platform/gateways/gateway-security"]
|
||||
"pages": [
|
||||
"documentation/platform/gateways/overview",
|
||||
"documentation/platform/gateways/gateway-security"
|
||||
]
|
||||
},
|
||||
"documentation/platform/project-templates",
|
||||
{
|
||||
@@ -419,7 +420,9 @@
|
||||
"integrations/app-connections/databricks",
|
||||
"integrations/app-connections/gcp",
|
||||
"integrations/app-connections/github",
|
||||
"integrations/app-connections/humanitec"
|
||||
"integrations/app-connections/humanitec",
|
||||
"integrations/app-connections/mssql",
|
||||
"integrations/app-connections/postgres"
|
||||
]
|
||||
}
|
||||
]
|
||||
@@ -579,7 +582,8 @@
|
||||
"api-reference/endpoints/identities/update",
|
||||
"api-reference/endpoints/identities/delete",
|
||||
"api-reference/endpoints/identities/get-by-id",
|
||||
"api-reference/endpoints/identities/list"
|
||||
"api-reference/endpoints/identities/list",
|
||||
"api-reference/endpoints/identities/search"
|
||||
]
|
||||
},
|
||||
{
|
||||
@@ -823,6 +827,39 @@
|
||||
"api-reference/endpoints/secret-imports/delete"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Secret Rotations",
|
||||
"pages": [
|
||||
"api-reference/endpoints/secret-rotations/list",
|
||||
"api-reference/endpoints/secret-rotations/options",
|
||||
{
|
||||
"group": "Microsoft SQL Server Credentials",
|
||||
"pages": [
|
||||
"api-reference/endpoints/secret-rotations/mssql-credentials/create",
|
||||
"api-reference/endpoints/secret-rotations/mssql-credentials/delete",
|
||||
"api-reference/endpoints/secret-rotations/mssql-credentials/get-by-id",
|
||||
"api-reference/endpoints/secret-rotations/mssql-credentials/get-by-name",
|
||||
"api-reference/endpoints/secret-rotations/mssql-credentials/get-generated-credentials-by-id",
|
||||
"api-reference/endpoints/secret-rotations/mssql-credentials/list",
|
||||
"api-reference/endpoints/secret-rotations/mssql-credentials/rotate-secrets",
|
||||
"api-reference/endpoints/secret-rotations/mssql-credentials/update"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "PostgreSQL Credentials",
|
||||
"pages": [
|
||||
"api-reference/endpoints/secret-rotations/postgres-credentials/create",
|
||||
"api-reference/endpoints/secret-rotations/postgres-credentials/delete",
|
||||
"api-reference/endpoints/secret-rotations/postgres-credentials/get-by-id",
|
||||
"api-reference/endpoints/secret-rotations/postgres-credentials/get-by-name",
|
||||
"api-reference/endpoints/secret-rotations/postgres-credentials/get-generated-credentials-by-id",
|
||||
"api-reference/endpoints/secret-rotations/postgres-credentials/list",
|
||||
"api-reference/endpoints/secret-rotations/postgres-credentials/rotate-secrets",
|
||||
"api-reference/endpoints/secret-rotations/postgres-credentials/update"
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Identity Specific Privilege",
|
||||
"pages": [
|
||||
@@ -922,6 +959,30 @@
|
||||
"api-reference/endpoints/app-connections/humanitec/update",
|
||||
"api-reference/endpoints/app-connections/humanitec/delete"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Microsoft SQL Server",
|
||||
"pages": [
|
||||
"api-reference/endpoints/app-connections/mssql/list",
|
||||
"api-reference/endpoints/app-connections/mssql/available",
|
||||
"api-reference/endpoints/app-connections/mssql/get-by-id",
|
||||
"api-reference/endpoints/app-connections/mssql/get-by-name",
|
||||
"api-reference/endpoints/app-connections/mssql/create",
|
||||
"api-reference/endpoints/app-connections/mssql/update",
|
||||
"api-reference/endpoints/app-connections/mssql/delete"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "PostgreSQL",
|
||||
"pages": [
|
||||
"api-reference/endpoints/app-connections/postgres/list",
|
||||
"api-reference/endpoints/app-connections/postgres/available",
|
||||
"api-reference/endpoints/app-connections/postgres/get-by-id",
|
||||
"api-reference/endpoints/app-connections/postgres/get-by-name",
|
||||
"api-reference/endpoints/app-connections/postgres/create",
|
||||
"api-reference/endpoints/app-connections/postgres/update",
|
||||
"api-reference/endpoints/app-connections/postgres/delete"
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
|
||||
Reference in New Issue
Block a user