Merge remote-tracking branch 'origin/main' into feat/acme-and-external-ca

This commit is contained in:
Sheen Capadngan
2025-05-19 20:11:48 +08:00
292 changed files with 9372 additions and 1110 deletions
@@ -0,0 +1,4 @@
---
title: "Available"
openapi: "GET /api/v1/app-connections/oci/available"
---
@@ -0,0 +1,8 @@
---
title: "Create"
openapi: "POST /api/v1/app-connections/oci"
---
<Note>
Check out the configuration docs for [OCI Connections](/integrations/app-connections/oci) to learn how to obtain the required credentials.
</Note>
@@ -0,0 +1,4 @@
---
title: "Delete"
openapi: "DELETE /api/v1/app-connections/oci/{connectionId}"
---
@@ -0,0 +1,4 @@
---
title: "Get by ID"
openapi: "GET /api/v1/app-connections/oci/{connectionId}"
---
@@ -0,0 +1,4 @@
---
title: "Get by Name"
openapi: "GET /api/v1/app-connections/oci/connection-name/{connectionName}"
---
@@ -0,0 +1,4 @@
---
title: "List"
openapi: "GET /api/v1/app-connections/oci"
---
@@ -0,0 +1,8 @@
---
title: "Update"
openapi: "PATCH /api/v1/app-connections/oci/{connectionId}"
---
<Note>
Check out the configuration docs for [OCI Connections](/integrations/app-connections/oci) to learn how to obtain the required credentials.
</Note>
@@ -0,0 +1,4 @@
---
title: "Attach"
openapi: "POST /api/v1/auth/oci-auth/identities/{identityId}"
---
@@ -0,0 +1,4 @@
---
title: "Login"
openapi: "POST /api/v1/auth/oci-auth/login"
---
@@ -0,0 +1,4 @@
---
title: "Retrieve"
openapi: "GET /api/v1/auth/oci-auth/identities/{identityId}"
---
@@ -0,0 +1,4 @@
---
title: "Revoke"
openapi: "DELETE /api/v1/auth/oci-auth/identities/{identityId}"
---
@@ -0,0 +1,4 @@
---
title: "Update"
openapi: "PATCH /api/v1/auth/oci-auth/identities/{identityId}"
---
@@ -0,0 +1,4 @@
---
title: "Create"
openapi: "POST /api/v1/secret-syncs/oci-vault"
---
@@ -0,0 +1,4 @@
---
title: "Delete"
openapi: "DELETE /api/v1/secret-syncs/oci-vault/{syncId}"
---
@@ -0,0 +1,4 @@
---
title: "Get by ID"
openapi: "GET /api/v1/secret-syncs/oci-vault/{syncId}"
---
@@ -0,0 +1,4 @@
---
title: "Get by Name"
openapi: "GET /api/v1/secret-syncs/oci-vault/sync-name/{syncName}"
---
@@ -0,0 +1,4 @@
---
title: "Import Secrets"
openapi: "POST /api/v1/secret-syncs/oci-vault/{syncId}/import-secrets"
---
@@ -0,0 +1,4 @@
---
title: "List"
openapi: "GET /api/v1/secret-syncs/oci-vault"
---
@@ -0,0 +1,4 @@
---
title: "Remove Secrets"
openapi: "POST /api/v1/secret-syncs/oci-vault/{syncId}/remove-secrets"
---
@@ -0,0 +1,4 @@
---
title: "Sync Secrets"
openapi: "POST /api/v1/secret-syncs/oci-vault/{syncId}/sync-secrets"
---
@@ -0,0 +1,4 @@
---
title: "Update"
openapi: "PATCH /api/v1/secret-syncs/oci-vault/{syncId}"
---
@@ -13,17 +13,17 @@ To interact with the Infisical API, you will need to obtain an access token. Fol
<AccordionGroup>
<Accordion title="Why can I not create, read, update, or delete an identity?">
There are a few reasons for why this might happen:
- You have insufficient organization permissions to create, read, update, delete identities.
- The identity you are trying to read, update, or delete is more privileged than yourself.
- The role you are trying to create an identity for or update an identity to is more privileged than yours.
</Accordion>
<Accordion title="Why is the Infisical API rejecting my identity credentials?">
There are a few reasons for why this might happen:
- The client secret or access token has expired.
- The identity is insufficently permissioned to interact with the resources you wish to access.
- The identity is insufficiently permissioned to interact with the resources you wish to access.
- You are attempting to access a `/raw` secrets endpoint that requires your project to disable E2EE.
- The client secret/access token is being used from an untrusted IP.
</Accordion>
</AccordionGroup>
</AccordionGroup>
+20 -20
View File
@@ -10,15 +10,15 @@ In this brief, we'll explore how to fetch a secret back from a project on [Infis
<Step title="Create a project with a secret">
To create a project, head to your Organization Overview and press **Add New Project**; we'll call the project **Demo App**.
![create project](../../images/getting-started/api/org-create-project-1.png)
![create project](../../images/getting-started/api/org-create-project-2.png)
Next, let's head to the **Development** environment of the project and add a secret `FOO=BAR` to it.
![explore project env](../../images/getting-started/api/project-explore-env.png)
![create secret](../../images/getting-started/api/project-create-secret.png)
![project dashboard](../../images/getting-started/api/project-dashboard.png)
<Note>
@@ -29,13 +29,13 @@ In this brief, we'll explore how to fetch a secret back from a project on [Infis
Next, we need to create an identity to represent your application. To create one, head to your Organization Settings > Access Control > Machine Identities and press **Create identity**.
![identities organization](../../images/platform/identities/identities-org.png)
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.
![identities organization create](../../images/platform/identities/identities-org-create.png)
Once you've created an identity, you'll be prompted to configure the **Universal Auth** authentication method for it.
![identities organization create auth method](../../images/platform/identities/identities-org-create-auth-method.png)
</Step>
@@ -44,7 +44,7 @@ In this brief, we'll explore how to fetch a secret back from a project on [Infis
of the identity and a **Client Secret** for it; you can think of these credentials akin to a username
and password used to authenticate with the Infisical API. With that, press on the key icon on the identity to generate a **Client Secret**
for it.
![identities client secret create](../../images/platform/identities/identities-org-client-secret.png)
![identities client secret create](../../images/platform/identities/identities-org-client-secret-create-1.png)
![identities client secret create](../../images/platform/identities/identities-org-client-secret-create-2.png)
@@ -55,14 +55,14 @@ In this brief, we'll explore how to fetch a secret back from a project on [Infis
Next, select the identity you want to add to the project and the role you want to assign it.
![identities project](../../images/platform/identities/identities-project.png)
![identities project create](../../images/platform/identities/identities-project-create.png)
</Step>
<Step title="Get an access token for the Infisical API">
To access the Infisical API as the identity, you should first perform a login operation
that is to exchange the **Client ID** and **Client Secret** of the identity for an access token
by making a request to the `/api/v1/auth/universal-auth/login` endpoint.
#### Sample request
```
@@ -71,9 +71,9 @@ In this brief, we'll explore how to fetch a secret back from a project on [Infis
--data-urlencode 'clientSecret=<client_secret>' \
--data-urlencode 'clientId=<client_id>'
```
#### Sample response
```
{
"accessToken": "...",
@@ -83,9 +83,9 @@ In this brief, we'll explore how to fetch a secret back from a project on [Infis
```
Next, we can use the access token to authenticate with the [Infisical API](/api-reference/overview/introduction) to read/write secrets
<Note>
Each identity access token has a time-to-live (TLL) which you can infer from the response of the login operation;
Each identity access token has a time-to-live (TTL) which you can infer from the response of the login operation;
the default TTL is `7200` seconds which can be adjusted.
If an identity access token expires, it can no longer authenticate with the Infisical API. In this case,
@@ -96,12 +96,12 @@ In this brief, we'll explore how to fetch a secret back from a project on [Infis
Finally, you can fetch the secret `FOO=BAR` back from **Step 1** by including the access token in the previous step in another request to the `/api/v3/secrets/raw/{secretName}` endpoint.
### Sample request
```
curl --location --request GET 'http://localhost:8080/api/v3/secrets/raw/FOO?workspaceId=657830d579cfc8415d06ce5b&environment=dev' \
--header 'Authorization: Bearer <access_token>'
```
### Sample response
```
@@ -118,11 +118,11 @@ In this brief, we'll explore how to fetch a secret back from a project on [Infis
}
}
```
Note that you can fetch a list of secrets back by making a request to the `/api/v3/secrets/raw` endpoint.
</Step>
</Steps>
See also:
- [API Reference](/api-reference/overview/introduction)
- [API Reference](/api-reference/overview/introduction)
@@ -158,14 +158,4 @@ Once authenticated, the Gateway establishes a secure connection with Infisical t
To confirm your Gateway is working, check the deployment status by looking for the message **"Gateway started successfully"** in the Gateway logs. This indicates the Gateway is running properly. Next, verify its registration by opening your Infisical dashboard, navigating to **Organization Access Control**, and selecting the **Gateways** tab. Your newly deployed Gateway should appear in the list.
![Gateway List](../../../images/platform/gateways/gateway-list.png)
</Step>
<Step title="Link Gateway to Projects">
To enable Infisical features like dynamic secrets or secret rotation to access private resources through the Gateway, you need to link the Gateway to the relevant projects.
Start by accessing the **Gateway settings** then locate the Gateway in the list, click the options menu (**:**), and select **Edit Details**.
![Edit Gateway Option](../../../images/platform/gateways/edit-gateway.png)
In the edit modal that appears, choose the projects you want the Gateway to access and click **Save** to confirm your selections.
![Project Assignment Modal](../../../images/platform/gateways/assign-project.png)
Once added to a project, the Gateway becomes available for use by any feature that supports Gateways within that project.
</Step>
</Steps>
@@ -311,7 +311,7 @@ access the Infisical API using the AWS Auth authentication method.
</Tip>
<Note>
Each identity access token has a time-to-live (TLL) which you can infer from the response of the login operation;
Each identity access token has a time-to-live (TTL) which you can infer from the response of the login operation;
the default TTL is `7200` seconds which can be adjusted.
If an identity access token expires, it can no longer authenticate with the Infisical API. In this case,
@@ -173,7 +173,7 @@ access the Infisical API using the Azure Auth authentication method.
We recommend using one of Infisical's clients like SDKs or the Infisical Agent to authenticate with Infisical using Azure Auth as they handle the authentication process including retrieving the client access token.
</Tip>
<Note>
Each identity access token has a time-to-live (TLL) which you can infer from the response of the login operation;
Each identity access token has a time-to-live (TTL) which you can infer from the response of the login operation;
the default TTL is `7200` seconds which can be adjusted.
If an identity access token expires, it can no longer authenticate with the Infisical API. In this case,
a new access token should be obtained by performing another login operation.
@@ -168,7 +168,7 @@ access the Infisical API using the GCP ID Token authentication method.
We recommend using one of Infisical's clients like SDKs or the Infisical Agent to authenticate with Infisical using GCP IAM Auth as they handle the authentication process including generating the signed JWT token.
</Tip>
<Note>
Each identity access token has a time-to-live (TLL) which you can infer from the response of the login operation;
Each identity access token has a time-to-live (TTL) which you can infer from the response of the login operation;
the default TTL is `7200` seconds which can be adjusted.
If an identity access token expires, it can no longer authenticate with the Infisical API. In this case,
a new access token should be obtained by performing another login operation.
@@ -179,7 +179,7 @@ access the Infisical API using the GCP ID Token authentication method.
</Tab>
<Tab title="GCP IAM Auth">
## Diagram
The following sequence diagram illustrates the GCP IAM Auth workflow for authenticating GCP IAM service accounts with Infisical.
@@ -352,7 +352,7 @@ access the Infisical API using the GCP IAM authentication method.
We recommend using one of Infisical's clients like SDKs or the Infisical Agent to authenticate with Infisical using GCP IAM Auth as they handle the authentication process including generating the signed JWT token.
</Tip>
<Note>
Each identity access token has a time-to-live (TLL) which you can infer from the response of the login operation;
Each identity access token has a time-to-live (TTL) which you can infer from the response of the login operation;
the default TTL is `7200` seconds which can be adjusted.
If an identity access token expires, it can no longer authenticate with the Infisical API. In this case,
a new access token should be obtained by performing another login operation.
@@ -361,5 +361,5 @@ access the Infisical API using the GCP IAM authentication method.
</Steps>
</Tab>
</Tabs>
@@ -56,7 +56,7 @@ In the following steps, we explore how to create and use identities for your app
<Step title="Obtaining the token reviewer JWT for Infisical">
<Tabs>
<Tab title="Option 1: Reviewer JWT Token">
<Note>
**When to use this option**: Choose this approach when you want centralized authentication management. Only one service account needs special permissions, and your application service accounts remain unchanged.
</Note>
@@ -190,7 +190,7 @@ In the following steps, we explore how to create and use identities for your app
Here's some more guidance on each field:
- Kubernetes Host / Base Kubernetes API URL: The host string, host:port pair, or URL to the base of the Kubernetes API server. This can usually be obtained by running `kubectl cluster-info`.
- Token Reviewer JWT: A long-lived service account JWT token for Infisical to access the [TokenReview API](https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-review-v1/) to validate other service account JWT tokens submitted by applications/pods. This is the JWT token obtained from step 1.5(Reviewer Tab). If omitted, the client's own JWT will be used instead, which requires the client to have the `system:auth-delegator` ClusterRole binding.
- Token Reviewer JWT: A long-lived service account JWT token for Infisical to access the [TokenReview API](https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-review-v1/) to validate other service account JWT tokens submitted by applications/pods. This is the JWT token obtained from step 1.5(Reviewer Tab). If omitted, the client's own JWT will be used instead, which requires the client to have the `system:auth-delegator` ClusterRole binding.
This is shown in step 1, option 2.
- Allowed Service Account Names: A comma-separated list of trusted service account names that are allowed to authenticate with Infisical.
- Allowed Namespaces: A comma-separated list of trusted namespaces that service accounts must belong to authenticate with Infisical.
@@ -257,7 +257,7 @@ In the following steps, we explore how to create and use identities for your app
</Tip>
<Note>
Each identity access token has a time-to-live (TLL) which you can infer from the response of the login operation;
Each identity access token has a time-to-live (TTL) which you can infer from the response of the login operation;
the default TTL is `7200` seconds which can be adjusted.
If an identity access token exceeds its max ttl, it can no longer authenticate with the Infisical API. In this case,
@@ -280,7 +280,7 @@ In the following steps, we explore how to create and use identities for your app
There are a few reasons for why this might happen:
- The access token has expired.
- The identity is insufficently permissioned to interact with the resources you wish to access.
- The identity is insufficiently permissioned to interact with the resources you wish to access.
- The client access token is being used from an untrusted IP.
</Accordion>
@@ -0,0 +1,212 @@
---
title: OCI Auth
description: "Learn how to authenticate with Infisical using OCI user accounts."
---
**OCI Auth** is an OCI-native authentication method that verifies Oracle Cloud Infrastructure users through signature validation, allowing secure access to Infisical resources.
## Diagram
The following sequence diagram illustrates the OCI Auth workflow for authenticating OCI users with Infisical.
```mermaid
sequenceDiagram
participant Client
participant Infisical
participant OCI
Note over Client,Client: Step 1: Sign user identity request
Note over Client,Infisical: Step 2: Login Operation
Client->>Infisical: Send signed request details to /api/v1/auth/oci-auth/login
Note over Infisical,OCI: Step 3: Request verification
Infisical->>OCI: Forward signed request
OCI-->>Infisical: Return user details
Note over Infisical: Step 4: Identity property validation
Infisical->>Client: Return short-lived access token
Note over Client,Infisical: Step 5: Access Infisical API with token
Client->>Infisical: Make authenticated requests using the short-lived access token
```
## Concept
At a high level, Infisical authenticates an OCI user by verifying its identity and checking that it meets specific requirements (e.g., its username is authorized, its part of a tenancy) at the `/api/v1/auth/oci-auth/login` endpoint. If successful,
then Infisical returns a short-lived access token that can be used to make authenticated requests to the Infisical API.
To be more specific:
1. The client [signs](https://docs.oracle.com/en-us/iaas/Content/API/Concepts/signingrequests.htm) a `/20160918/users/{userId}` request using an OCI user's [private key](https://docs.oracle.com/en-us/iaas/Content/API/Concepts/apisigningkey.htm#Required_Keys_and_OCIDs); this is done using the [OCI SDK](https://infisical.com/docs/documentation/platform/identities/oci-auth#accessing-the-infisical-api-with-the-identity) or API.
2. The client sends the signed request's headers and their user OCID to Infisical at the `/api/v1/auth/oci-auth/login` endpoint.
3. Infisical reconstructs the request and sends it to OCI via the [Get User](https://docs.oracle.com/en/engineered-systems/private-cloud-appliance/3.0-latest/ceapi/op-20160918-users-user_id-get.html) endpoint for verification and obtains the identity associated with the OCI user.
4. Infisical checks the user's properties against set criteria such as **Allowed Usernames** and **Tenancy OCID**.
5. If all checks pass, Infisical returns a short-lived access token that the client can use to make authenticated requests to the Infisical API.
## Prerequisite
In order to sign requests, you must have an OCI user with credentials such as the private key. If you're unaware of how to create a user and obtain the needed credentials, expand the menu below.
<Accordion title="Creating an OCI user">
<Steps>
<Step title="Search for 'Domains' and click as shown">
![Search Domains](/images/app-connections/oci/search-domains.png)
</Step>
<Step title="Select domain">
Select the domain in which you want to create the Infisical user account.
![Select Domain](/images/app-connections/oci/select-domain.png)
</Step>
<Step title="Navigate to 'Users'">
![Select Users](/images/app-connections/oci/select-users.png)
</Step>
<Step title="Click 'Create user'">
![Click Create User](/images/app-connections/oci/click-create-user.png)
</Step>
<Step title="Create user">
The name, email, and username can be anything.
![Create User](/images/app-connections/oci/create-user.png)
</Step>
<Step title="Navigate to 'API keys'">
After you've created a user, you'll be redirected to the user's page. Navigate to 'API keys'.
![Select API Keys](/images/app-connections/oci/select-api-keys.png)
</Step>
<Step title="Add API key">
Click on 'Add API key' and then download or import the private key. After you've obtained the private key, click 'Add'.
![Add API Key](/images/app-connections/oci/add-api-key.png)
<Note>
At the end of the downloaded private key file, you'll see `OCI_API_KEY`. This is not apart of the private key, and should not be included when you use the private key to sign requests.
</Note>
</Step>
<Step title="Store configuration">
After creating the API key, you'll be shown a modal with relevant information. Save the highlighted values (and the private key) for later steps.
![User Info](/images/app-connections/oci/user-info.png)
</Step>
</Steps>
</Accordion>
## Guide
In the following steps, we explore how to create and use identities for your workloads and applications on OCI to
access the Infisical API using the OCI request signing authentication method.
### Creating an identity
To create an identity, head to your Organization Settings > Access Control > [Identities](https://app.infisical.com/organization/access-management?selectedTab=identities) and press **Create identity**.
![identities organization](/images/platform/identities/identities-org.png)
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](https://app.infisical.com/organization/access-management?selectedTab=roles).
![identities organization create](/images/platform/identities/identities-org-create.png)
Input some details for your new identity:
- **Name (required):** A friendly name for the identity.
- **Role (required):** A role from the [**Organization Roles**](https://app.infisical.com/organization/access-management?selectedTab=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 redirected to a page where you can manage the identity.
![identities page](/images/platform/identities/identities-page.png)
Since the identity has been configured with [Universal Auth](https://infisical.com/docs/documentation/platform/identities/universal-auth) by default, you should reconfigure it to use OCI Auth instead. To do this, click the cog next to **Universal Auth** and then select **Delete** in the options dropdown.
![identities press cog](/images/platform/identities/identities-press-cog.png)
![identities page remove default auth](/images/platform/identities/identities-page-remove-default-auth.png)
Now create a new OCI Auth Method.
![identities create oci auth method](/images/platform/identities/identities-org-create-oci-auth-method.png)
Here's some information about each field:
- **Tenancy OCID:** The OCID of your tenancy. All users authenticating must be part of this Tenancy.
- **Allowed Usernames:** A comma-separated list of trusted OCI users that are allowed to authenticate with Infisical.
- **Access Token TTL (default is `2592000` equivalent to 30 days):** The lifetime for an access token in seconds. This value will be referenced at renewal time.
- **Access Token Max TTL (default is `2592000` equivalent to 30 days):** The maximum lifetime for an access token in seconds. This value will be referenced at renewal time.
- **Access Token Max Number of Uses (default is `0`):** The maximum number of times that an access token can be used; a value of `0` implies an infinite number of uses.
- **Access Token Trusted IPs:** The IPs or CIDR ranges that access tokens can be used from. By default, each token is given the `0.0.0.0/0`, allowing usage from any network address.
### Adding an identity to a project
In order to allow an identity to access project-level resources such as secrets, you must add it to the relevant projects.
To do this, head over to the project you want to add the identity to and navigate to Project Settings > Access Control > Machine Identities and press **Add Identity**.
![identities project](/images/platform/identities/identities-project.png)
Select the identity you want to add to the project and the project-level role you want it to assume. The project role given to the identity will determine what project-level resources this identity can access.
![identities project create](/images/platform/identities/identities-project-create.png)
### Accessing the Infisical API with the identity
To access the Infisical API as the identity, you need to construct a signed [Get User](https://docs.oracle.com/en/engineered-systems/private-cloud-appliance/3.0-latest/ceapi/op-20160918-users-user_id-get.html) request using [OCI Signature v1](https://docs.oracle.com/en-us/iaas/Content/API/Concepts/signingrequests.htm#Request_Signatures) and then make a request to the `/api/v1/auth/oci-auth/login` endpoint passing the signed header data and user OCID.
Below is an example of how you can authenticate with Infisical using the `oci-sdk` for NodeJS.
```typescript
import { common } from "oci-sdk";
// Change these credentials to match your OCI user
const tenancyId = "ocid1.tenancy.oc1..example";
const userId = "ocid1.user.oc1..example";
const fingerprint = "00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00";
const region = "us-ashburn-1";
const privateKey = "..."; // Must be PEM format
const provider = new common.SimpleAuthenticationDetailsProvider(
tenancyId,
userId,
fingerprint,
privateKey,
null,
common.Region.fromRegionId(region),
);
// Build request
const headers = new Headers({
host: `identity.${region}.oraclecloud.com`,
});
const request: common.HttpRequest = {
method: "GET",
uri: `/20160918/users/${userId}`,
headers,
body: null,
};
// Sign request
const signer = new common.DefaultRequestSigner(provider);
await signer.signHttpRequest(request);
// Forward signed request to Infisical
const requestAsJson = {
identityId: "2dd11664-68e3-471d-b366-907206ab1bff",
userOcid: userId,
headers: Object.fromEntries(request.headers.entries()),
};
const res = await fetch("https://app.infisical.com/api/v1/auth/oci-auth/login", {
method: "POST",
headers: {
"Content-Type": "application/json",
},
body: JSON.stringify(requestAsJson),
});
const json = await res.json();
console.log("Infisical Response:", json);
```
<Note>
Each identity access token has a time-to-live (TTL) which you can infer from the response of the login operation; the default TTL is `7200` seconds, which can be adjusted.
If an identity access token expires, it can no longer access the Infisical API. A new access token should be obtained by performing another login operation.
</Note>
@@ -163,7 +163,7 @@ In the following steps, we explore how to create and use identities to access th
}
```
<Note>
Each identity access token has a time-to-live (TLL) which you can infer from the response of the login operation;
Each identity access token has a time-to-live (TTL) which you can infer from the response of the login operation;
the default TTL is `7200` seconds which can be adjusted.
If an identity access token expires, it can no longer authenticate with the Infisical API. In this case,
@@ -159,7 +159,7 @@ In the following steps, we explore how to create and use identities to access th
</Tip>
<Note>
Each identity access token has a time-to-live (TLL) which you can infer from the response of the login operation;
Each identity access token has a time-to-live (TTL) which you can infer from the response of the login operation;
the default TTL is `7200` seconds which can be adjusted.
If an identity access token expires, it can no longer authenticate with the Infisical API. In this case,
@@ -159,7 +159,7 @@ In the following steps, we explore how to create and use identities to access th
</Tip>
<Note>
Each identity access token has a time-to-live (TLL) which you can infer from the response of the login operation;
Each identity access token has a time-to-live (TTL) which you can infer from the response of the login operation;
the default TTL is `7200` seconds which can be adjusted.
If an identity access token expires, it can no longer authenticate with the Infisical API. In this case,
@@ -77,9 +77,9 @@ using the Token Auth authentication method.
</Step>
<Step title="Creating a Token">
In order to use the identity with Token Auth, you'll need to create an (access) token; you can think of this token akin
In order to use the identity with Token Auth, you'll need to create an (access) token; you can think of this token akin
to an API Key used to authenticate with the Infisical API. With that, press **Create Token**.
![identities client secret create](/images/platform/identities/identities-token-auth-create-1.png)
![identities client secret create](/images/platform/identities/identities-token-auth-create-2.png)
@@ -106,7 +106,7 @@ using the Token Auth authentication method.
to authenticate with the [Infisical API](/api-reference/overview/introduction).
<Note>
Each identity access token has a time-to-live (TLL) which you can infer from the response of the login operation;
Each identity access token has a time-to-live (TTL) which you can infer from the response of the login operation;
the default TTL is `7200` seconds which can be adjusted in the Token Auth configuration.
If an identity access token expires, it can no longer authenticate with the Infisical API. In this case,
@@ -121,14 +121,14 @@ using the Token Auth authentication method.
<AccordionGroup>
<Accordion title="Why is the Infisical API rejecting my access token?">
There are a few reasons for why this might happen:
- The access token has expired. If this is the case, you should obtain a new access token or consider extending the token's TTL.
- The identity is insufficently permissioned to interact with the resources you wish to access.
- The identity is insufficiently permissioned to interact with the resources you wish to access.
- The access token is being used from an untrusted IP.
</Accordion>
<Accordion title="What is access token renewal and TTL/Max TTL?">
A identity access token can have a time-to-live (TTL) or incremental lifetime after which it expires.
In certain cases, you may want to extend the lifespan of an access token; to do so, you must set a max TTL parameter.
A token can be renewed any number of times where each call to renew it can extend the token's lifetime by increments of the access token's TTL.
@@ -84,15 +84,15 @@ using the Universal Auth authentication method.
<Step title="Creating a Client Secret">
In order to use the identity, you'll need the non-sensitive **Client ID**
of the identity and a **Client Secret** for it; you can think of these credentials akin to a username
and password used to authenticate with the Infisical API.
and password used to authenticate with the Infisical API.
With that, press **Create Client Secret**.
![identities client secret create](/images/platform/identities/identities-universal-auth-create-1.png)
![identities client secret create](/images/platform/identities/identities-universal-auth-create-2.png)
![identities client secret create](/images/platform/identities/identities-universal-auth-create-3.png)
Feel free to input any (optional) details for the **Client Secret** configuration:
- Description: A description for the **Client Secret**.
- TTL (default is `0`): The time-to-live for the **Client Secret**. By default, the TTL will be set to 0 which implies that the **Client Secret** will never expire; a value of `0` implies an infinite lifetime.
- Max Number of Uses (default is `0`): The maximum number of times that the **Client Secret** can be used together with the **Client ID** to get back an access token; a value of `0` implies infinite number of uses.
@@ -113,10 +113,10 @@ using the Universal Auth authentication method.
To access the Infisical API as the identity, you should first perform a login operation
that is to exchange the **Client ID** and **Client Secret** of the identity for an access token
by making a request to the `/api/v1/auth/universal-auth/login` endpoint.
<Tip>
Choose the correct base URL based on your region:
- For Infisical Cloud US users: `https://app.infisical.com`
- For Infisical Cloud EU users: `https://eu.infisical.com`
</Tip>
@@ -144,7 +144,7 @@ using the Universal Auth authentication method.
Next, you can use the access token to authenticate with the [Infisical API](/api-reference/overview/introduction)
<Note>
Each identity access token has a time-to-live (TLL) which you can infer from the response of the login operation;
Each identity access token has a time-to-live (TTL) which you can infer from the response of the login operation;
the default TTL is `7200` seconds which can be adjusted in the Universal Auth configuration.
If an identity access token expires, it can no longer authenticate with the Infisical API. In this case,
@@ -159,14 +159,14 @@ using the Universal Auth authentication method.
<AccordionGroup>
<Accordion title="Why is the Infisical API rejecting my identity credentials?">
There are a few reasons for why this might happen:
- The client secret or access token has expired.
- The identity is insufficently permissioned to interact with the resources you wish to access.
- The identity is insufficiently permissioned to interact with the resources you wish to access.
- The client secret/access token is being used from an untrusted IP.
</Accordion>
<Accordion title="What is access token renewal and TTL/Max TTL?">
A identity access token can have a time-to-live (TTL) or incremental lifetime after which it expires.
In certain cases, you may want to extend the lifespan of an access token; to do so, you must set a max TTL parameter.
A token can be renewed any number of times where each call to renew it can extend the token's lifetime by increments of the access token's TTL.
+21 -9
View File
@@ -5,23 +5,23 @@ description: "Learn how to enable a set of policies to manage changes to sensiti
<Info>
Approval Workflows is a paid feature.
If you're using Infisical Cloud, then it is available under the **Pro Tier** and **Enterprise Tire**.
If you're using Infisical Cloud, then it is available under the **Pro Tier** and **Enterprise Tier**.
If you're self-hosting Infisical, then you should contact [email protected] to purchase an enterprise license to use it.
</Info>
## Problem at hand
Updating secrets in high-stakes environments (e.g., production) can have a number of problematic issues:
- Most developers should not have access to secrets in production environments. Yet, they are the ones who often need to add new secrets or change the existing ones. Many organizations have in-house policies with regards to what person should be contacted in the case of needing to make changes to secrets. This slows down software development lifecycle and distracts engineers from working on things that matter the most.
- As a general rule, before making changes in production environments, those changes have to be looked over by at least another person. An extra pair of eyes can help reduce the risk of human error and make sure that the change will not affect the application in an unintended way.
- After making updates to secrets, the corresponding applications need to be redeployed with the right set of secrets and configurations. This process is often not automated and hence prone to human error.
Updating secrets in high-stakes environments (e.g., production) can have a number of problematic issues:
- Most developers should not have access to secrets in production environments. Yet, they are the ones who often need to add new secrets or change the existing ones. Many organizations have in-house policies with regards to what person should be contacted in the case of needing to make changes to secrets. This slows down software development lifecycle and distracts engineers from working on things that matter the most.
- As a general rule, before making changes in production environments, those changes have to be looked over by at least another person. An extra pair of eyes can help reduce the risk of human error and make sure that the change will not affect the application in an unintended way.
- After making updates to secrets, the corresponding applications need to be redeployed with the right set of secrets and configurations. This process is often not automated and hence prone to human error.
## Solution
As a wide-spread software engineering practice, developers have to submit their code as a PR that needs to be approved before the code is merged into the main branch.
As a wide-spread software engineering practice, developers have to submit their code as a PR that needs to be approved before the code is merged into the main branch.
In a similar way, to solve the above-mentioned issues, Infisical provides a feature called `Approval Workflows` for secret management. This is a set of policies and workflows that help advance access controls, compliance procedures, and stability of a particular environment. In other words, **Approval Workflows** help you secure, stabilize, and streamline the change of secrets in high-stakes environments.
In a similar way, to solve the above-mentioned issues, Infisical provides a feature called `Approval Workflows` for secret management. This is a set of policies and workflows that help advance access controls, compliance procedures, and stability of a particular environment. In other words, **Approval Workflows** help you secure, stabilize, and streamline the change of secrets in high-stakes environments.
### Setting a policy
@@ -33,6 +33,10 @@ First, you would need to create a set of policies for a certain environment. In
The enforcement level determines how strict the policy is. A **Hard** enforcement level means that any change that matches the policy will need full approval prior merging. A **Soft** enforcement level allows for break glass functionality on the request. If a change request is bypassed, the approvers will be notified via email.
### Self approvals
If the **Self Approvals** option is enabled, users who are designated as approvers on the policy can approve requests that they themselves have submitted.
### Example of creating a change policy
When creating a policy, you can choose the type of policy you want to create. In this case, we will be creating a `Change Policy`. Other types of policies include `Access Policy` that creates policies for **[Access Requests](/documentation/platform/access-controls/access-requests)**.
@@ -41,10 +45,18 @@ When creating a policy, you can choose the type of policy you want to create. In
### Example of updating secrets with Approval workflows
When a user submits a change to an enviropnment that is under a particular policy, a corresponsing change request will go to a predefined approver (or multiple approvers).
When a user submits a change to an environment that is under a particular policy, a corresponding change request will go to a predefined approver (or multiple approvers).
![secret update change requests](../../images/platform/pr-workflows/secret-update-request.png)
Approvers are notified by email and/or Slack as soon as the request is initiated. In the Infisical Dashboard, they will be able to `approve` and `merge` (or `deny`) a request for a change in a particular environment. After that, depending on the workflows setup, the change will be automatically propagated to the right applications (e.g., using [Infisical Kubernetes Operator](https://infisical.com/docs/integrations/platforms/kubernetes)).
![secrets update pull request](../../images/platform/pr-workflows/secret-update-pr.png)
## FAQ
<AccordionGroup>
<Accordion title="Is it possible to disable self-approval for policies?">
Yes, if you'd like to require an approval from an approver other than the one who created the request, then you can disable the **Self Approvals** feature inside of your target policy.
</Accordion>
</AccordionGroup>
@@ -182,10 +182,10 @@ In the following steps, we explore the end-to-end workflow for setting up this s
<AccordionGroup>
<Accordion title="Why are my AWS IAM credentials not rotating?">
There are a few reasons for why this might happen:
There are a few reasons for why this might happen:
- The strategy configuration is invalid (e.g. the managing IAM user's credentials are incorrect, the target AWS region is incorrect, etc.)
- The managing IAM user is insufficently permissioned to rotate the credentials of the target IAM user. For instance, you may have setup
- The managing IAM user is insufficiently permissioned to rotate the credentials of the target IAM user. For instance, you may have setup
[paths](https://aws.amazon.com/blogs/security/optimize-aws-administration-with-iam-paths/) for the managing IAM user and the policy does not have the necessary
permissions to rotate the credentials.
permissions to rotate the credentials.
</Accordion>
</AccordionGroup>
@@ -0,0 +1,55 @@
---
title: "General OIDC Group Membership Mapping"
sidebarTitle: "Group Membership Mapping"
description: "Learn how to sync OIDC group members to matching groups in Infisical."
---
You can have Infisical automatically sync group
memberships between your OIDC provider and Infisical by configuring a `groups` claim on your provider tokens.
When a user logs in via OIDC, they will be added to Infisical groups that are present in their OIDC `groups` claim,
and removed from any Infisical groups not present in the claim.
<Info>
When enabled, manual
management of Infisical group memberships will be disabled.
</Info>
<Warning>
Group membership changes in your OIDC provider only sync with Infisical when a
user logs in via OIDC. For example, if you remove a user from a group in your OIDC provider,
this change will not be reflected in Infisical until their next OIDC login.
To ensure this behavior, Infisical recommends enabling Enforce OIDC SSO in the OIDC settings.
</Warning>
<Steps>
<Step title="Configure a groups claim in your OIDC provider">
To enable OIDC Group Membership Mapping, you must configure a `groups` claim in your OIDC provider.
Add a `groups` property with a list of the user's OIDC group names to your token.
Example of expected token payload:
```json
{
// "email": "[email protected]",
// "given_name": "John",
// ...other claims
"groups": ["Billing Group", "Sales Group"]
}
```
<Note>
Setup varies between OIDC providers. Please refer to your OIDC provider's documentation for more information.
</Note>
</Step>
<Step title="Setup groups in Infisical and enable OIDC Group Membership Mapping">
2.1. In Infisical, create any groups you would like to sync users to. Make sure the name of the Infisical group is an exact match of the OIDC group name.
![OIDC general infisical group](/images/sso/keycloak-oidc/group-membership-mapping/create-infisical-group.png)
2.2. Next, enable **OIDC Group Membership Mapping** on the **Single Sign-On (SSO)** page under the **General** tab.
![OIDC general enable group membership mapping](/images/sso/keycloak-oidc/group-membership-mapping/enable-group-membership-mapping.png)
2.3. The next time a user logs in they will be synced to their matching OIDC groups.
![OIDC general synced users](/images/sso/keycloak-oidc/group-membership-mapping/synced-users.png)
</Step>
</Steps>
@@ -1,5 +1,6 @@
---
title: "General OIDC"
sidebarTitle: "Overview"
description: "Learn how to configure OIDC for Infisical SSO with any OIDC-compliant identity provider"
---
@@ -29,7 +30,7 @@ Prerequisites:
</Step>
<Step title="Finish configuring OIDC in Infisical">
2.1. Back in Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Select **Connect** for **OIDC**.
![OIDC SSO Connect](../../../images/sso/connect-oidc.png)
![OIDC SSO Connect](../../../../images/sso/connect-oidc.png)
2.2. You can configure OIDC either through the Discovery URL (Recommended) or by inputting custom endpoints.
@@ -39,10 +40,10 @@ Prerequisites:
Note that the Discovery Document URL typically takes the form: `https://<idp-domain>/.well-known/openid-configuration`.
</Note>
![OIDC general discovery config](../../../images/sso/general-oidc/discovery-oidc-form.png)
![OIDC general discovery config](../../../../images/sso/general-oidc/discovery-oidc-form.png)
To configure OIDC via the custom endpoints, set the **Configuration Type** field to **Custom** and input the required endpoint fields.
![OIDC general custom config](../../../images/sso/general-oidc/custom-oidc-form.png)
![OIDC general custom config](../../../../images/sso/general-oidc/custom-oidc-form.png)
2.3. Select the appropriate JWT signature algorithm for your IdP. Currently, the supported options are RS256, RS512, HS256, and EdDSA.
@@ -55,7 +56,7 @@ Prerequisites:
<Step title="Enable OIDC SSO in Infisical">
Enabling OIDC SSO allows members in your organization to log into Infisical via the configured Identity Provider
![OIDC general enable OIDC](../../../images/sso/general-oidc/org-oidc-enable.png)
![OIDC general enable OIDC](../../../../images/sso/general-oidc/org-oidc-enable.png)
</Step>
<Step title="Enforce OIDC SSO in Infisical">
Binary file not shown.

After

Width:  |  Height:  |  Size: 1.1 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 952 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 738 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 765 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.6 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.0 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.4 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 299 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.4 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 715 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.0 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.7 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.9 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.9 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.9 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.2 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 649 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 410 KiB

After

Width:  |  Height:  |  Size: 590 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 656 KiB

After

Width:  |  Height:  |  Size: 1.0 MiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 534 KiB

After

Width:  |  Height:  |  Size: 666 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 549 KiB

After

Width:  |  Height:  |  Size: 1.1 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.1 MiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 414 KiB

After

Width:  |  Height:  |  Size: 579 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 645 KiB

After

Width:  |  Height:  |  Size: 1.0 MiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 43 KiB

After

Width:  |  Height:  |  Size: 133 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 885 KiB

After

Width:  |  Height:  |  Size: 782 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 878 KiB

After

Width:  |  Height:  |  Size: 779 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 682 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 654 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 643 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 670 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.1 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 739 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 683 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 653 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 639 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.1 MiB

+189
View File
@@ -0,0 +1,189 @@
---
title: "OCI Connection"
description: "Learn how to configure an Oracle Cloud Infrastructure Connection for Infisical."
---
Infisical supports the use of [API Signing Key Authentication](https://docs.oracle.com/en-us/iaas/Content/API/Concepts/apisigningkey.htm) to connect with OCI.
## Create OCI User
<Steps>
<Step title="Search for 'Domains' and click as shown">
![Search Domains](/images/app-connections/oci/search-domains.png)
</Step>
<Step title="Select domain">
Select the domain in which you want to create the Infisical user account.
![Select Domain](/images/app-connections/oci/select-domain.png)
</Step>
<Step title="Navigate to 'Users'">
![Select Users](/images/app-connections/oci/select-users.png)
</Step>
<Step title="Click 'Create user'">
![Click Create User](/images/app-connections/oci/click-create-user.png)
</Step>
<Step title="Create user">
The name, email, and username can be anything.
![Create User](/images/app-connections/oci/create-user.png)
</Step>
<Step title="Navigate to 'API keys'">
After you've created a user, you'll be redirected to the user's page. Navigate to 'API keys'.
![Select API Keys](/images/app-connections/oci/select-api-keys.png)
</Step>
<Step title="Add API key">
Click on 'Add API key' and then download or import the private key. After you've obtained the private key, click 'Add'.
![Add API Key](/images/app-connections/oci/add-api-key.png)
</Step>
<Step title="Store configuration">
After creating the API key, you'll be shown a modal with relevant information. Save the highlighted values (and the private key) for later steps.
![User Info](/images/app-connections/oci/user-info.png)
</Step>
</Steps>
## Create OCI Group
<Steps>
<Step title="Search for 'Domains' and click as shown">
![Search Domains](/images/app-connections/oci/search-domains.png)
</Step>
<Step title="Select domain">
Select the domain in which you want to create the Infisical user account.
![Select Domain](/images/app-connections/oci/select-domain.png)
</Step>
<Step title="Navigate to 'Groups'">
![Select Groups](/images/app-connections/oci/select-groups.png)
</Step>
<Step title="Create group">
The name and description can be anything. **Ensure that you assign the user created in earlier steps to this group**.
![Create Group](/images/app-connections/oci/create-group.png)
</Step>
<Step title="Store group name">
After creating the group, take note of its name. It will be used in later steps.
</Step>
</Steps>
## Create OCI Policy
<Steps>
<Step title="Search for 'Policies' and click as shown">
![Search Policies](/images/app-connections/oci/search-policies.png)
</Step>
<Step title="Click 'Create Policy'">
![Click Create Policy](/images/app-connections/oci/click-create-policy.png)
</Step>
<Step title="Create policy">
The name and description can be anything. Click 'Show manual editor' and paste in the policy rules relevant to your task:
<Tabs>
<Tab title="Secret Sync">
```
Allow group <group name> to manage secret-family in compartment <compartment name>
Allow group <group name> to use keys in compartment <compartment name>
Allow group <group name> to use vaults in compartment <compartment name>
Allow group <group name> to inspect compartments in tenancy
```
- **Group Name:** The name of the group you created in earlier steps.
- **Compartment Name:** The name of the compartment which has your secrets vault.
If you'd like to grant Infisical access to all compartments, replace instances of `compartment <compartment name>` with `tenancy`.
</Tab>
</Tabs>
![Create Policy](/images/app-connections/oci/create-policy.png)
<Note>
**You must create this policy on the root compartment**, otherwise some functionality may not work.
</Note>
</Step>
</Steps>
## Create OCI Connection in Infisical
<Tabs>
<Tab title="Infisical UI">
<Steps>
<Step title="Navigate to App Connections">
In your Infisical dashboard, go to **Organization Settings** and select the [**App Connections**](https://app.infisical.com/organization/app-connections) tab.
![App Connections Tab](/images/app-connections/general/add-connection.png)
</Step>
<Step title="Select OCI Connection">
Click the **+ Add Connection** button and select the **OCI Connection** option from the available integrations.
![Select OCI Connection](/images/app-connections/oci/app-connection-option.png)
</Step>
<Step title="Fill out the OCI Connection Modal">
Complete the OCI Connection form by entering:
- A descriptive name for the connection
- An optional description for future reference
- The User OCID from [earlier steps](https://infisical.com/docs/integrations/app-connections/oci#create-oci-user)
- The Tenancy OCID from [earlier steps](https://infisical.com/docs/integrations/app-connections/oci#create-oci-user)
- The Region from [earlier steps](https://infisical.com/docs/integrations/app-connections/oci#create-oci-user)
- The Fingerprint from [earlier steps](https://infisical.com/docs/integrations/app-connections/oci#create-oci-user)
- The Private Key PEM from [earlier steps](https://infisical.com/docs/integrations/app-connections/oci#create-oci-user)
![OCI Connection Modal](/images/app-connections/oci/app-connection-modal.png)
</Step>
<Step title="Connection Created">
After clicking Create, your **OCI Connection** is established and ready to use with your Infisical projects.
![OCI Connection Created](/images/app-connections/oci/app-connection-created.png)
</Step>
</Steps>
</Tab>
<Tab title="API">
To create an OCI Connection, make an API request to the [Create OCI Connection](/api-reference/endpoints/app-connections/oci/create) API endpoint.
### Sample request
```bash Request
curl --request POST \
--url https://app.infisical.com/api/v1/app-connections/oci \
--header 'Content-Type: application/json' \
--data '{
"name": "my-oci-connection",
"method": "access-key",
"credentials": {
"userOcid": "ocid1.user.oc1..aaaaaaaagrp35tbkvvad4y2j7sug7xonua7dl2gfp4at2u5i5xj4ghnitg3a",
"tenancyOcid": "ocid1.tenancy.oc1..aaaaaaaaotfma465m4zumfe2ua64mj2m5dwmlw2llh4g4dnfttnakiifonta",
"region": "us-ashburn-1",
"fingerprint": "9c:f6:18:23:92:73:f8:e1:85:2c:6a:e3:2c:7d:ec:8f",
"privateKey": "[PRIVATE KEY PEM]"
}
}'
```
### Sample response
```bash Response
{
"appConnection": {
"id": "e5d18aca-86f7-4026-a95e-efb8aeb0d8e6",
"name": "my-oci-connection",
"description": null,
"version": 1,
"orgId": "6f03caa1-a5de-43ce-b127-95a145d3464c",
"createdAt": "2025-04-23T19:46:34.831Z",
"updatedAt": "2025-04-23T19:46:34.831Z",
"isPlatformManagedCredentials": false,
"credentialsHash": "7c2d371dec195f82a6a0d5b41c970a229cfcaf88e894a5b6395e2dbd0280661f",
"app": "oci",
"method": "access-key",
"credentials": {
"userOcid": "ocid1.user.oc1..aaaaaaaagrp35tbkvvad4y2j7sug7xonua7dl2gfp4at2u5i5xj4ghnitg3a",
"tenancyOcid": "ocid1.tenancy.oc1..aaaaaaaaotfma465m4zumfe2ua64mj2m5dwmlw2llh4g4dnfttnakiifonta",
"region": "us-ashburn-1",
"fingerprint": "9c:f6:18:23:92:73:f8:e1:85:2c:6a:e3:2c:7d:ec:8f"
}
}
}
```
</Tab>
</Tabs>
+12 -13
View File
@@ -22,11 +22,11 @@ description: "How to sync secrets from Infisical to Heroku"
</Step>
<Step title="Start integration">
Select which Infisical environment secrets you want to sync to which Heroku app and press create integration to start syncing secrets to Heroku.
![integrations heroku](../../images/integrations/heroku/integrations-heroku-create.png)
Here's some guidance on each field:
- Project Environment: The environment in the current Infisical project from which you want to sync secrets from.
- Secrets Path: The path in the current Infisical project from which you want to sync secrets from such as `/` (for secrets that do not reside in a folder) or `/foo/bar` (for secrets nested in a folder, in this case a folder called `bar` in another folder called `foo`).
- Heroku App: The application in Heroku that you want to sync secrets to.
@@ -34,7 +34,7 @@ description: "How to sync secrets from Infisical to Heroku"
- **No Import - Overwrite all values in Heroku**: Sync secrets and overwrite any existing secrets in Heroku.
- **Import - Prefer values from Infisical**: Import secrets from Heroku to Infisical; if a secret with the same name already exists in Infisical, do nothing. Afterwards, sync secrets to Heroku.
- **Import - Prefer values from Heroku**: Import secrets from Heroku to Infisical; if a secret with the same name already exists in Infisical, replace its value with the one from Heroku. Afterwards, sync secrets to Heroku.
![integrations heroku](../../images/integrations/heroku/integrations-heroku.png)
</Step>
</Steps>
@@ -46,27 +46,26 @@ description: "How to sync secrets from Infisical to Heroku"
<Step title="Create an API client in Heroku">
Navigate to your user Account settings > Applications to create a new API client.
![integrations Heroku config](../../images/integrations/heroku/integrations-heroku-config-settings.png)
![integrations Heroku config](../../images/integrations/heroku/integrations-heroku-config-applications.png)
![integrations Heroku config](../../images/integrations/heroku/integrations-heroku-config-new-app.png)
![integrations Heroku config](../../images/integrations/heroku/integrations-heroku-config-settings.png)
![integrations Heroku config](../../images/integrations/heroku/integrations-heroku-config-applications.png)
![integrations Heroku config](../../images/integrations/heroku/integrations-heroku-config-new-app.png)
Create the API client. As part of the form, set the **OAuth callback URL** to `https://your-domain.com/integrations/heroku/oauth2/callback`.
![integrations Heroku config](../../images/integrations/heroku/integrations-heroku-config-new-app-form.png)
![integrations Heroku config](../../images/integrations/heroku/integrations-heroku-config-new-app-form.png)
</Step>
<Step title="Add your Heroku API client credentials to Infisical">
Obtain the **Client ID** and **Client Secret** for your Heroku API client.
![integrations Heroku config](../../images/integrations/heroku/integrations-heroku-config-credentials.png)
![integrations Heroku config](../../images/integrations/heroku/integrations-heroku-config-credentials.png)
Back in your Infisical instance, add two new environment variables for the credentials of your Heroku API client.
- `CLIENT_ID_HEROKU`: The **Client ID** of your Heroku API client.
- `CLIENT_SECRET_HEROKU`: The **Client Secret** of your Heroku API client.
Once added, restart your Infisical instance and use the Heroku integration.
</Step>
</Steps>
</Tab>
</Tabs>
+14
View File
@@ -0,0 +1,14 @@
---
title: "Pulumi"
description: "Using Infisical with Pulumi via the Terraform Bridge"
---
Infisical can be integrated with Pulumi by leveraging Pulumi’s [Terraform Bridge](https://www.pulumi.com/blog/any-terraform-provider/),
which allows Terraform providers to be used seamlessly within Pulumi projects. This enables infrastructure and platform teams to manage Infisical secrets and resources
using Pulumi’s familiar programming languages (including TypeScript, Python, Go, and C#), without any change to existing workflows.
The Terraform Bridge wraps the [Infisical Terraform provider](/integrations/frameworks/terraform) and exposes its resources (such as `infisical_secret`, `infisical_project`, and `infisical_service_token`)
in a Pulumi-compatible interface. This makes it easy to integrate secret management directly into Pulumi-based IaC pipelines, ensuring secrets stay in sync with
the rest of your cloud infrastructure. Authentication is handled through the same methods as Terraform: using environment variables such as `INFISICAL_TOKEN` and `INFISICAL_SITE_URL`.
By bridging the Infisical provider, teams using Pulumi can adopt secure, centralized secrets management without compromising on their toolchain or language preferences.
@@ -40,6 +40,10 @@ description: "Learn how to configure an AWS Parameter Store Sync for Infisical."
- **Overwrite Destination Secrets**: Removes any secrets at the destination endpoint not present in Infisical.
- **Import Secrets (Prioritize Infisical)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Infisical over Parameter Store when keys conflict.
- **Import Secrets (Prioritize AWS Parameter Store)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Parameter Store over Infisical when keys conflict.
- **Key Schema**: Template that determines how secret names are transformed when syncing, using `{{secretKey}}` as a placeholder for the original secret name.
<Note>
We highly recommend using a Key Schema to ensure that Infisical only manages the specific keys you intend, keeping everything else untouched.
</Note>
- **KMS Key**: The AWS KMS key ID or alias to encrypt parameters with.
- **Tags**: Optional resource tags to add to parameters synced by Infisical.
- **Sync Secret Metadata as Resource Tags**: If enabled, metadata attached to secrets will be added as resource tags to parameters synced by Infisical.
@@ -43,6 +43,10 @@ description: "Learn how to configure an AWS Secrets Manager Sync for Infisical."
- **Overwrite Destination Secrets**: Removes any secrets at the destination endpoint not present in Infisical.
- **Import Secrets (Prioritize Infisical)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Infisical over Secrets Manager when keys conflict.
- **Import Secrets (Prioritize AWS Secrets Manager)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Secrets Manager over Infisical when keys conflict.
- **Key Schema**: Template that determines how secret names are transformed when syncing, using `{{secretKey}}` as a placeholder for the original secret name.
<Note>
We highly recommend using a Key Schema to ensure that Infisical only manages the specific keys you intend, keeping everything else untouched.
</Note>
- **KMS Key**: The AWS KMS key ID or alias to encrypt secrets with.
- **Tags**: Optional tags to add to secrets synced by Infisical.
- **Sync Secret Metadata as Tags**: If enabled, metadata attached to secrets will be added as tags to secrets synced by Infisical.
@@ -48,7 +48,10 @@ description: "Learn how to configure an Azure App Configuration Sync for Infisic
- **Overwrite Destination Secrets**: Removes any secrets at the destination endpoint not present in Infisical.
- **Import Secrets (Prioritize Infisical)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Infisical over Secrets Manager when keys conflict.
- **Import Secrets (Prioritize Azure App Configuration)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Secrets Manager over Infisical when keys conflict.
- **Key Schema**: Template that determines how secret names are transformed when syncing, using `{{secretKey}}` as a placeholder for the original secret name.
<Note>
We highly recommend using a Key Schema to ensure that Infisical only manages the specific keys you intend, keeping everything else untouched.
</Note>
- **Auto-Sync Enabled**: If enabled, secrets will automatically be synced from the source location when changes occur. Disable to enforce manual syncing only.
- **Disable Secret Deletion**: If enabled, Infisical will not remove secrets from the sync destination. Enable this option if you intend to manage some secrets manually outside of Infisical.
@@ -51,6 +51,10 @@ description: "Learn how to configure a Azure Key Vault Sync for Infisical."
- **Overwrite Destination Secrets**: Removes any secrets at the destination endpoint not present in Infisical.
- **Import Secrets (Prioritize Infisical)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Infisical over Secrets Manager when keys conflict.
- **Import Secrets (Prioritize Azure Key Vault)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Secrets Manager over Infisical when keys conflict.
- **Key Schema**: Template that determines how secret names are transformed when syncing, using `{{secretKey}}` as a placeholder for the original secret name.
<Note>
We highly recommend using a Key Schema to ensure that Infisical only manages the specific keys you intend, keeping everything else untouched.
</Note>
- **Auto-Sync Enabled**: If enabled, secrets will automatically be synced from the source location when changes occur. Disable to enforce manual syncing only.
- **Disable Secret Deletion**: If enabled, Infisical will not remove secrets from the sync destination. Enable this option if you intend to manage some secrets manually outside of Infisical.
@@ -39,6 +39,10 @@ description: "Learn how to configure a Camunda Sync for Infisical."
- **Overwrite Destination Secrets**: Removes any secrets at the destination endpoint not present in Infisical.
- **Import Secrets (Prioritize Infisical)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Infisical over Camunda when keys conflict.
- **Import Secrets (Prioritize Camunda)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Camunda over Infisical when keys conflict.
- **Key Schema**: Template that determines how secret names are transformed when syncing, using `{{secretKey}}` as a placeholder for the original secret name.
<Note>
We highly recommend using a Key Schema to ensure that Infisical only manages the specific keys you intend, keeping everything else untouched.
</Note>
- **Auto-Sync Enabled**: If enabled, secrets will automatically be synced from the source location when changes occur. Disable to enforce manual syncing only.
- **Disable Secret Deletion**: If enabled, Infisical will not remove secrets from the sync destination. Enable this option if you intend to manage some secrets manually outside of Infisical.
@@ -46,6 +46,10 @@ description: "Learn how to configure a Databricks Sync for Infisical."
<Note>
Databricks does not support importing secrets.
</Note>
- **Key Schema**: Template that determines how secret names are transformed when syncing, using `{{secretKey}}` as a placeholder for the original secret name.
<Note>
We highly recommend using a Key Schema to ensure that Infisical only manages the specific keys you intend, keeping everything else untouched.
</Note>
- **Auto-Sync Enabled**: If enabled, secrets will automatically be synced from the source location when changes occur. Disable to enforce manual syncing only.
- **Disable Secret Deletion**: If enabled, Infisical will not remove secrets from the sync destination. Enable this option if you intend to manage some secrets manually outside of Infisical.
@@ -42,6 +42,10 @@ description: "Learn how to configure a GCP Secret Manager Sync for Infisical."
- **Overwrite Destination Secrets**: Removes any secrets at the destination endpoint not present in Infisical.
- **Import Secrets (Prioritize Infisical)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Infisical over GCP Secret Manager when keys conflict.
- **Import Secrets (Prioritize GCP Secret Manager)**: Imports secrets from the destination endpoint before syncing, prioritizing values from GCP Secret Manager over Infisical when keys conflict.
- **Key Schema**: Template that determines how secret names are transformed when syncing, using `{{secretKey}}` as a placeholder for the original secret name.
<Note>
We highly recommend using a Key Schema to ensure that Infisical only manages the specific keys you intend, keeping everything else untouched.
</Note>
- **Auto-Sync Enabled**: If enabled, secrets will automatically be synced from the source location when changes occur. Disable to enforce manual syncing only.
- **Disable Secret Deletion**: If enabled, Infisical will not remove secrets from the sync destination. Enable this option if you intend to manage some secrets manually outside of Infisical.
@@ -62,6 +62,10 @@ description: "Learn how to configure a GitHub Sync for Infisical."
<Note>
GitHub does not support importing secrets.
</Note>
- **Key Schema**: Template that determines how secret names are transformed when syncing, using `{{secretKey}}` as a placeholder for the original secret name.
<Note>
We highly recommend using a Key Schema to ensure that Infisical only manages the specific keys you intend, keeping everything else untouched.
</Note>
- **Auto-Sync Enabled**: If enabled, secrets will automatically be synced from the source location when changes occur. Disable to enforce manual syncing only.
- **Disable Secret Deletion**: If enabled, Infisical will not remove secrets from the sync destination. Enable this option if you intend to manage some secrets manually outside of Infisical.
@@ -54,6 +54,10 @@ description: "Learn how to configure a Hashicorp Vault Sync for Infisical."
- **Overwrite Destination Secrets**: Removes any secrets at the destination endpoint not present in Infisical.
- **Import Secrets (Prioritize Infisical)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Infisical over Hashicorp Vault when keys conflict.
- **Import Secrets (Prioritize Hashicorp Vault)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Hashicorp Vault over Infisical when keys conflict.
- **Key Schema**: Template that determines how secret names are transformed when syncing, using `{{secretKey}}` as a placeholder for the original secret name.
<Note>
We highly recommend using a Key Schema to ensure that Infisical only manages the specific keys you intend, keeping everything else untouched.
</Note>
- **Auto-Sync Enabled**: If enabled, secrets will automatically be synced from the source location when changes occur. Disable to enforce manual syncing only.
- **Disable Secret Deletion**: If enabled, Infisical will not remove secrets from the sync destination. Enable this option if you intend to manage some secrets manually outside of Infisical.
</Step>
@@ -55,6 +55,10 @@ description: "Learn how to configure a Humanitec Sync for Infisical."
<Note>
Humanitec does not support importing secrets.
</Note>
- **Key Schema**: Template that determines how secret names are transformed when syncing, using `{{secretKey}}` as a placeholder for the original secret name.
<Note>
We highly recommend using a Key Schema to ensure that Infisical only manages the specific keys you intend, keeping everything else untouched.
</Note>
- **Auto-Sync Enabled**: If enabled, secrets will automatically be synced from the source location when changes occur. Disable to enforce manual syncing only.
- **Disable Secret Deletion**: If enabled, Infisical will not remove secrets from the sync destination. Enable this option if you intend to manage some secrets manually outside of Infisical.
@@ -0,0 +1,180 @@
---
title: "OCI Vault Sync"
description: "Learn how to configure an Oracle Cloud Infrastructure Vault Sync for Infisical."
---
**Prerequisites:**
- Create an [OCI Connection](/integrations/app-connections/oci) with the required **Secret Sync** permissions
- [Create](https://docs.oracle.com/en-us/iaas/Content/Identity/compartments/To_create_a_compartment.htm) or use an existing OCI Compartment (which the OCI Connection is authorized to access)
- [Create](https://docs.oracle.com/en-us/iaas/Content/KeyManagement/Tasks/managingvaults_topic-To_create_a_new_vault.htm#createnewvault) or use an existing OCI Vault
<Tabs>
<Tab title="Infisical UI">
<Steps>
<Step title="Add Sync">
Navigate to **Project** > **Integrations** and select the **Secret Syncs** tab. Click on the **Add Sync** button.
![Secret Syncs Tab](/images/secret-syncs/general/secret-sync-tab.png)
</Step>
<Step title="Select 'OCI Vault'">
![Select OCI Vault](/images/secret-syncs/oci-vault/select-option.png)
</Step>
<Step title="Configure source">
Configure the **Source** from where secrets should be retrieved, then click **Next**.
![Configure Source](/images/secret-syncs/oci-vault/configure-source.png)
- **Environment**: The project environment to retrieve secrets from.
- **Secret Path**: The folder path to retrieve secrets from.
<Tip>
If you need to sync secrets from multiple folder locations, check out [secret imports](/documentation/platform/secret-reference#secret-imports).
</Tip>
</Step>
<Step title="Configure destination">
Configure the **Destination** to where secrets should be deployed, then click **Next**.
![Configure Destination](/images/secret-syncs/oci-vault/configure-destination.png)
- **OCI Connection**: The OCI Connection to authenticate with.
- **Compartment**: The compartment where the vault is located.
- **Vault**: The vault to sync secrets to.
- **Encryption Key**: The encryption key to use when creating secrets in the vault.
</Step>
<Step title="Configure sync options">
Configure the **Sync Options** to specify how secrets should be synced, then click **Next**.
![Configure Sync Options](/images/secret-syncs/oci-vault/configure-sync-options.png)
- **Initial Sync Behavior**: Determines how Infisical should resolve the initial sync.
- **Overwrite Destination Secrets**: Removes any secrets at the destination endpoint not present in Infisical.
- **Import Secrets (Prioritize Infisical)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Infisical over OCI Vault when keys conflict.
- **Import Secrets (Prioritize OCI Vault)**: Imports secrets from the destination endpoint before syncing, prioritizing values from OCI Vault over Infisical when keys conflict.
- **Key Schema**: Template that determines how secret names are transformed when syncing, using `{{secretKey}}` as a placeholder for the original secret name.
<Note>
We highly recommend using a Key Schema to ensure that Infisical only manages the specific keys you intend, keeping everything else untouched.
</Note>
- **Auto-Sync Enabled**: If enabled, secrets will automatically be synced from the source location when changes occur. Disable to enforce manual syncing only.
- **Disable Secret Deletion**: If enabled, Infisical will not remove secrets from the sync destination. Enable this option if you intend to manage some secrets manually outside of Infisical.
</Step>
<Step title="Configure details">
Configure the **Details** of your OCI Vault Sync, then click **Next**.
![Configure Details](/images/secret-syncs/oci-vault/configure-details.png)
- **Name**: The name of your sync. Must be slug-friendly.
- **Description**: An optional description for your sync.
</Step>
<Step title="Review configuration">
Review your OCI Vault Sync configuration, then click **Create Sync**.
![Review Configuration](/images/secret-syncs/oci-vault/review-configuration.png)
</Step>
<Step title="Sync created">
If enabled, your OCI Vault Sync will begin syncing your secrets to the destination endpoint.
![Sync Created](/images/secret-syncs/oci-vault/sync-created.png)
</Step>
</Steps>
</Tab>
<Tab title="API">
To create an **OCI Vault Sync**, make an API request to the [Create OCI Vault Sync](/api-reference/endpoints/secret-syncs/oci-vault/create) API endpoint.
### Sample request
```bash Request
curl --request POST \
--url https://app.infisical.com/api/v1/secret-syncs/oci-vault \
--header 'Content-Type: application/json' \
--data '{
"name": "my-oci-vault-sync",
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"description": "an example sync",
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"environment": "dev",
"secretPath": "/my-secrets",
"isEnabled": true,
"syncOptions": {
"initialSyncBehavior": "overwrite-destination"
},
"destinationConfig": {
"compartmentOcid": "...",
"vaultOcid": "...",
"keyOcid": "..."
}
}'
```
### Sample response
```bash Response
{
"secretSync": {
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"name": "my-oci-vault-sync",
"description": "an example sync",
"isEnabled": true,
"version": 1,
"folderId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"createdAt": "2023-11-07T05:31:56Z",
"updatedAt": "2023-11-07T05:31:56Z",
"syncStatus": "succeeded",
"lastSyncJobId": "123",
"lastSyncMessage": null,
"lastSyncedAt": "2023-11-07T05:31:56Z",
"importStatus": null,
"lastImportJobId": null,
"lastImportMessage": null,
"lastImportedAt": null,
"removeStatus": null,
"lastRemoveJobId": null,
"lastRemoveMessage": null,
"lastRemovedAt": null,
"syncOptions": {
"initialSyncBehavior": "overwrite-destination"
},
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"connection": {
"app": "oci",
"name": "my-oci-connection",
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a"
},
"environment": {
"slug": "dev",
"name": "Development",
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a"
},
"folder": {
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"path": "/my-secrets"
},
"destination": "oci-vault",
"destinationConfig": {
"compartmentOcid": "...",
"vaultOcid": "...",
"keyOcid": "..."
}
}
}
```
</Tab>
</Tabs>
## FAQ
<AccordionGroup>
<Accordion title="How are non-active lifecycle states treated?">
When Infisical attempts to sync secrets, the sync will fail and attempt to re-sync if **any secret** has one of the following lifecycle states:
- SchedulingDeletion
- CancellingDeletion
- Deleting
- Creating
- Updating
We do this to prevent any desync issues.
</Accordion>
<Accordion title="What happens if I create / update a variable that's scheduled for deletion in OCI Vault?">
In the case that a variable is created or updated while it's scheduled for deletion in OCI Vault, we cancel the deletion and update the variable. This action may take up to a minute since Infisical must wait for OCI to completely cancel the deletion and then update the variable.
</Accordion>
</AccordionGroup>
+23 -1
View File
@@ -93,4 +93,26 @@ via the UI or API for the third-party service you intend to sync secrets to.
<Note>
Infisical is continuously expanding it's Secret Sync third-party service support. If the service you need isn't available,
you can still use our Native Integrations in the interim, or contact us at [email protected] to make a request .
</Note>
</Note>
## Key Schemas
Key Schemas transform your secret keys by applying a prefix, suffix, or format pattern during sync to external destinations. This makes it clear which secrets are managed by Infisical and prevents accidental changes to unrelated secrets.
**Example:**
- Infisical key: `SECRET_1`
- Schema: `INFISICAL_{{secretKey}}`
- Synced key: `INFISICAL_SECRET_1`
<div align="center">
```mermaid
graph LR
A[Infisical: **SECRET_1**] -->|Apply Schema| B[Destination: **INFISICAL_SECRET_1**]
style B fill:#F4FFE6,stroke:#96D600,stroke-width:2px,color:black,rx:15px
style A fill:#E6F4FF,stroke:#0096D6,stroke-width:2px,color:black,rx:15px
```
</div>
<Note>
When importing secrets from the destination into Infisical, the schema is stripped from imported secret keys.
</Note>
+4 -1
View File
@@ -48,7 +48,10 @@ description: "Learn how to configure a TeamCity Sync for Infisical."
<Note>
Infisical only syncs secrets from within the target scope; inherited secrets will not be imported.
</Note>
- **Key Schema**: Template that determines how secret names are transformed when syncing, using `{{secretKey}}` as a placeholder for the original secret name.
<Note>
We highly recommend using a Key Schema to ensure that Infisical only manages the specific keys you intend, keeping everything else untouched.
</Note>
- **Auto-Sync Enabled**: If enabled, secrets will automatically be synced from the source location when changes occur. Disable to enforce manual syncing only.
- **Disable Secret Deletion**: If enabled, Infisical will not remove secrets from the sync destination. Enable this option if you intend to manage some secrets manually outside of Infisical.
@@ -56,6 +56,10 @@ description: "Learn how to configure a Terraform Cloud Sync for Infisical."
<Note>
Terraform Cloud does not support importing secrets.
</Note>
- **Key Schema**: Template that determines how secret names are transformed when syncing, using `{{secretKey}}` as a placeholder for the original secret name.
<Note>
We highly recommend using a Key Schema to ensure that Infisical only manages the specific keys you intend, keeping everything else untouched.
</Note>
- **Auto-Sync Enabled**: If enabled, secrets will automatically be synced from the source location when changes occur. Disable to enforce manual syncing only.
- **Disable Secret Deletion**: If enabled, Infisical will not remove secrets from the sync destination. Enable this option if you intend to manage some secrets manually outside of Infisical.
@@ -43,6 +43,10 @@ description: "Learn how to configure a Vercel Sync for Infisical."
- **Overwrite Destination Secrets**: Removes any secrets at the destination endpoint not present in Infisical.
- **Import Secrets (Prioritize Infisical)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Infisical over Vercel when keys conflict.
- **Import Secrets (Prioritize Vercel)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Vercel over Infisical when keys conflict.
- **Key Schema**: Template that determines how secret names are transformed when syncing, using `{{secretKey}}` as a placeholder for the original secret name.
<Note>
We highly recommend using a Key Schema to ensure that Infisical only manages the specific keys you intend, keeping everything else untouched.
</Note>
- **Auto-Sync Enabled**: If enabled, secrets will automatically be synced from the source location when changes occur. Disable to enforce manual syncing only.
- **Disable Secret Deletion**: If enabled, Infisical will not remove secrets from the sync destination. Enable this option if you intend to manage some secrets manually outside of Infisical.
@@ -44,6 +44,10 @@ description: "Learn how to configure a Windmill Sync for Infisical."
- **Overwrite Destination Secrets**: Removes any secrets at the destination endpoint not present in Infisical.
- **Import Secrets (Prioritize Infisical)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Infisical over Windmill when keys conflict.
- **Import Secrets (Prioritize Windmill)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Windmill over Infisical when keys conflict.
- **Key Schema**: Template that determines how secret names are transformed when syncing, using `{{secretKey}}` as a placeholder for the original secret name.
<Note>
We highly recommend using a Key Schema to ensure that Infisical only manages the specific keys you intend, keeping everything else untouched.
</Note>
- **Auto-Sync Enabled**: If enabled, secrets will automatically be synced from the source location when changes occur. Disable to enforce manual syncing only.
- **Disable Secret Deletion**: If enabled, Infisical will not remove secrets from the sync destination. Enable this option if you intend to manage some secrets manually outside of Infisical.
@@ -218,3 +218,4 @@ Supports conditions and permission inversion
| `create-gateways` | Add new gateways to organization |
| `edit-gateways` | Modify existing gateway settings |
| `delete-gateways` | Remove gateways from organization |
| `attach-gateways` | Attach gateways to resources |
+64 -13
View File
@@ -267,14 +267,25 @@
"documentation/platform/sso/google-saml",
"documentation/platform/sso/auth0-saml",
{
"group": "Keycloak OIDC",
"group": "OIDC",
"pages": [
"documentation/platform/sso/keycloak-oidc/overview",
"documentation/platform/sso/keycloak-oidc/group-membership-mapping"
{
"group": "Keycloak OIDC",
"pages": [
"documentation/platform/sso/keycloak-oidc/overview",
"documentation/platform/sso/keycloak-oidc/group-membership-mapping"
]
},
"documentation/platform/sso/auth0-oidc",
{
"group": "General OIDC",
"pages": [
"documentation/platform/sso/general-oidc/overview",
"documentation/platform/sso/general-oidc/group-membership-mapping"
]
}
]
},
"documentation/platform/sso/auth0-oidc",
"documentation/platform/sso/general-oidc"
}
]
},
{
@@ -301,14 +312,14 @@
{
"group": "Machine Identities",
"pages": [
"documentation/platform/identities/aws-auth",
"documentation/platform/identities/azure-auth",
"documentation/platform/identities/gcp-auth",
"documentation/platform/identities/jwt-auth",
"documentation/platform/identities/kubernetes-auth",
"documentation/platform/identities/oci-auth",
"documentation/platform/identities/token-auth",
"documentation/platform/identities/universal-auth",
"documentation/platform/identities/kubernetes-auth",
"documentation/platform/identities/gcp-auth",
"documentation/platform/identities/azure-auth",
"documentation/platform/identities/aws-auth",
"documentation/platform/identities/jwt-auth",
{
"group": "OIDC Auth",
"pages": [
@@ -351,7 +362,8 @@
"group": "Linux Package",
"pages": [
"self-hosting/deployment-options/native/linux-package/installation",
"self-hosting/deployment-options/native/linux-package/commands-configuration"
"self-hosting/deployment-options/native/linux-package/commands-configuration",
"self-hosting/deployment-options/linux-upgrade"
]
},
"self-hosting/guides/upgrading-infisical",
@@ -446,6 +458,7 @@
]
},
"integrations/frameworks/terraform",
"integrations/frameworks/pulumi",
"integrations/platforms/ansible",
"integrations/platforms/apache-airflow"
]
@@ -470,6 +483,7 @@
"integrations/app-connections/humanitec",
"integrations/app-connections/ldap",
"integrations/app-connections/mssql",
"integrations/app-connections/oci",
"integrations/app-connections/postgres",
"integrations/app-connections/teamcity",
"integrations/app-connections/terraform-cloud",
@@ -496,6 +510,7 @@
"integrations/secret-syncs/github",
"integrations/secret-syncs/hashicorp-vault",
"integrations/secret-syncs/humanitec",
"integrations/secret-syncs/oci-vault",
"integrations/secret-syncs/teamcity",
"integrations/secret-syncs/terraform-cloud",
"integrations/secret-syncs/vercel",
@@ -697,6 +712,16 @@
"api-reference/endpoints/aws-auth/revoke"
]
},
{
"group": "OCI Auth",
"pages": [
"api-reference/endpoints/oci-auth/login",
"api-reference/endpoints/oci-auth/attach",
"api-reference/endpoints/oci-auth/retrieve",
"api-reference/endpoints/oci-auth/update",
"api-reference/endpoints/oci-auth/revoke"
]
},
{
"group": "Azure Auth",
"pages": [
@@ -1172,6 +1197,18 @@
"api-reference/endpoints/app-connections/mssql/delete"
]
},
{
"group": "OCI",
"pages": [
"api-reference/endpoints/app-connections/oci/list",
"api-reference/endpoints/app-connections/oci/available",
"api-reference/endpoints/app-connections/oci/get-by-id",
"api-reference/endpoints/app-connections/oci/get-by-name",
"api-reference/endpoints/app-connections/oci/create",
"api-reference/endpoints/app-connections/oci/update",
"api-reference/endpoints/app-connections/oci/delete"
]
},
{
"group": "PostgreSQL",
"pages": [
@@ -1375,6 +1412,20 @@
"api-reference/endpoints/secret-syncs/humanitec/remove-secrets"
]
},
{
"group": "OCI",
"pages": [
"api-reference/endpoints/secret-syncs/oci-vault/list",
"api-reference/endpoints/secret-syncs/oci-vault/get-by-id",
"api-reference/endpoints/secret-syncs/oci-vault/get-by-name",
"api-reference/endpoints/secret-syncs/oci-vault/create",
"api-reference/endpoints/secret-syncs/oci-vault/update",
"api-reference/endpoints/secret-syncs/oci-vault/delete",
"api-reference/endpoints/secret-syncs/oci-vault/sync-secrets",
"api-reference/endpoints/secret-syncs/oci-vault/import-secrets",
"api-reference/endpoints/secret-syncs/oci-vault/remove-secrets"
]
},
{
"group": "TeamCity",
"pages": [
@@ -0,0 +1,390 @@
---
title: "Upgrading"
description: "How to upgrade Infisical deployment using linux package"
---
This guide explains how to upgrade Infisical Linux package installations to newer versions.
The Infisical Linux package includes only the Infisical service component itself, as PostgreSQL and Redis databases are managed separately.
Upgrades for PostgreSQL and Redis are not covered in this guide as they depend on your specific database deployment method.
## Upgrade Options
There are two primary methods to upgrade Infisical:
1. **Standard Upgrade (with brief downtime)**: The simplest approach that briefly takes Infisical offline during the upgrade.
2. **Minimal-Downtime Upgrade**: For multi-node deployments where high availability is required.
## Before You Begin
### Checking Your Current Version
Before upgrading, note your current Infisical version:
```bash
cat /opt/infisical-core/version-manifest.txt
```
Look for `infisical` component. This will be the version of Infisical currently installed.
### Prerequisites
- Verify that your PostgreSQL and Redis instances are up and running
- Back up your PostgreSQL database before proceeding with any upgrade
- Review release notes for the version you're upgrading to
### Creating a Database Backup
We strongly recommend backing up your database before upgrading.
Your backup approach may look different depending on how you configured PostgreSQL and whether it's self-managed or using a managed service.
Here is a sample of how you would perform a manual backup:
```bash
# Example PostgreSQL backup command (adjust parameters as needed)
pg_dump -U <username> -h <db-host> -d <db-name> > infisical_backup.sql
```
### Database Migrations During Upgrade
By default, Infisical runs database migrations automatically on startup.
- It uses database locks to ensure only one instance runs migrations at a time
- Other instances will wait for the lock to be released before continuing startup
- This prevents race conditions and database conflicts
## Standard Upgrade (with Downtime)
This method is suitable for single-node deployments or situations where a brief downtime is acceptable.
<Steps>
<Step title="Stop the Infisical service">
```bash
infisical-ctl stop
```
</Step>
<Step title="Upgrade the Infisical package">
To upgrade to the latest version:
<Tabs>
<Tab title="Debian/Ubuntu">
```bash
sudo apt-get update && sudo apt-get install -y infisical-core
```
</Tab>
<Tab title="RHEL/CentOS/Amazon Linux">
```bash
sudo yum update infisical-core
```
</Tab>
</Tabs>
To upgrade to a specific version:
<Tabs>
<Tab title="Debian/Ubuntu">
```bash
sudo apt-get install -y infisical-core=<version>
```
</Tab>
<Tab title="RHEL/CentOS/Amazon Linux">
```bash
sudo yum install infisical-core-<version>
```
</Tab>
</Tabs>
</Step>
<Step title="Apply configuration changes">
```bash
infisical-ctl reconfigure
```
</Step>
<Step title="Start Infisical">
```bash
infisical-ctl start
```
</Step>
<Step title="Verify the upgrade">
```bash
infisical-ctl status
```
Check the logs for any issues:
```bash
infisical-ctl tail
```
</Step>
</Steps>
## Minimal-Downtime Upgrade
For multi-node setups where you need to maintain availability during upgrades, follow this procedure. This approach requires at least two Infisical nodes behind a load balancer.
### Understanding Traffic Draining
"Draining" a server means gracefully removing it from the pool of active servers without disrupting existing connections. When you drain a server:
1. The load balancer stops sending new requests to the server
2. Existing connections are allowed to complete naturally
3. Once all connections finish, the server can be safely taken offline for maintenance
This approach ensures users/machines do not experience sudden connection errors during the upgrade process.
### Preparing for the Upgrade
1. **Designate a deploy node**: Choose any single node that will run migrations. This node will be upgraded first.
2. **Configure your load balancer**: Ensure your load balancer can perform health checks against Infisical's `api/status` endpoint.
### Upgrade Process
#### On the deploy node:
<Steps>
<Step title="Drain traffic from the node">
Drain the traffic on this node gracefully. You can do this in a number of ways depending on the load balancer you have configured.
Approaches for some common load balancers are provided below:
<Tabs>
<Tab title="NGINX">
If using NGINX as a load balancer, you can remove the server from the upstream pool temporarily:
```bash
# Edit your NGINX configuration to comment out or remove the server
sudo nano /path/to/your/nginx-config.conf
# Reload NGINX to apply changes
sudo nginx -s reload
```
</Tab>
<Tab title="HAProxy">
If using HAProxy, you can put the server in maintenance mode:
```bash
# Using the HAProxy socket command
echo "disable server infisical_backend/infisical-node1" | socat stdio /var/lib/haproxy/stats
```
</Tab>
<Tab title="AWS ALB/ELB">
Deregister the instance from the load balancer using the AWS console or CLI
</Tab>
<Tab title="Other load balancers">
Follow your load balancer's documentation for instructions on draining procedure
</Tab>
</Tabs>
</Step>
<Step title="Verify no new traffic is arriving">
Verify no new traffic is arriving before proceeding with the upgrade.
</Step>
<Step title="Stop Infisical on this node">
```bash
infisical-ctl stop
```
</Step>
<Step title="Upgrade the Infisical package">
To upgrade to the latest version:
<Tabs>
<Tab title="Debian/Ubuntu">
```bash
sudo apt-get update && sudo apt-get install -y infisical-core
```
</Tab>
<Tab title="RHEL/CentOS/Amazon Linux">
```bash
sudo yum update infisical-core
```
</Tab>
</Tabs>
To upgrade to a specific version:
<Tabs>
<Tab title="Debian/Ubuntu">
```bash
sudo apt-get install -y infisical-core=<version>
```
</Tab>
<Tab title="RHEL/CentOS/Amazon Linux">
```bash
sudo yum install infisical-core-<version>
```
</Tab>
</Tabs>
</Step>
<Step title="Apply configuration and start the service">
```bash
infisical-ctl reconfigure
```
</Step>
<Step title="Verify the upgrade and migration success">
```bash
infisical-ctl tail
```
Look for successful migration messages in the logs.
</Step>
<Step title="Return this node to load balancer pool">
Re-enable the server in your load balancer using the same method you used to remove it.
</Step>
</Steps>
#### On all remaining nodes (one at a time):
<Steps>
<Step title="Drain traffic from the node">
Follow the same draining procedure as described for the deploy node:
- Remove the server from your load balancer's active pool
- Wait for existing connections to complete
- Verify the node is no longer receiving traffic
</Step>
<Step title="Stop Infisical on this node">
```bash
infisical-ctl stop
```
</Step>
<Step title="Upgrade the Infisical package">
To upgrade to the latest version:
<Tabs>
<Tab title="Debian/Ubuntu">
```bash
sudo apt-get update && sudo apt-get install -y infisical-core
```
</Tab>
<Tab title="RHEL/CentOS/Amazon Linux">
```bash
sudo yum update infisical-core
```
</Tab>
</Tabs>
To upgrade to a specific version:
<Tabs>
<Tab title="Debian/Ubuntu">
```bash
sudo apt-get install -y infisical-core=<version>
```
</Tab>
<Tab title="RHEL/CentOS/Amazon Linux">
```bash
sudo yum install infisical-core-<version>
```
</Tab>
</Tabs>
</Step>
<Step title="Apply configuration and start the service">
```bash
infisical-ctl reconfigure
```
</Step>
<Step title="Verify the upgrade success">
```bash
infisical-ctl status
infisical-ctl tail
```
</Step>
<Step title="Wait for service to be fully operational">
- Check logs to ensure the service has started successfully
- Verify it can connect to the database and Redis
</Step>
<Step title="Return the node to service">
Re-enable the server in your load balancer using the same method you used to remove it.
</Step>
<Step title="Verify traffic is flowing correctly">
Check logs and monitoring to ensure traffic is flowing correctly.
</Step>
<Step title="Repeat for each remaining node">
Repeat steps 1-7 for each remaining node, one at a time.
</Step>
<Step title="Verify application functionality">
After all nodes are upgraded, verify that the application is functioning correctly:
- Test core functionality
- Check logs for any errors
</Step>
</Steps>
## Rolling Back
If you need to roll back to a previous version of Infisical, follow steps below.
<Steps>
<Step title="Stop the Infisical service">
```bash
infisical-ctl stop
```
</Step>
<Step title="Install the previous version">
For Debian/Ubuntu:
```bash
sudo apt-get install -y infisical-core=<previous-version>
```
For RHEL/CentOS/Amazon Linux:
```bash
sudo yum downgrade infisical-core-<previous-version>
```
</Step>
<Step title="Restore your database from backup">
Restore your Postgres/Redis database from backup.
</Step>
<Step title="Start the service">
```bash
infisical-ctl reconfigure
```
</Step>
<Step title="Verify the rollback">
```bash
infisical-ctl status
```
</Step>
</Steps>
## Troubleshooting
<AccordionGroup>
<Accordion title="Migration Issues">
If you encounter database migration issues:
1. Check the logs:
```bash
infisical-ctl tail
```
2. Ensure the database user has sufficient privileges to create/modify tables.
3. If migrations fail repeatedly, consider restoring from the backup you took prior to upgrading.
</Accordion>
<Accordion title="Service Won't Start After Upgrade">
1. Check for configuration errors:
```bash
infisical-ctl tail
infisical-ctl status
```
2. Verify all required environment variables are set in your `/etc/infisical/infisical.rb` file.
</Accordion>
</AccordionGroup>
@@ -4,19 +4,19 @@ description: "Learn how to configure Infisical with custom certificates"
---
By default, the Infisical Docker image includes certificates from well-known public certificate authorities.
However, some integrations with Infisical may need to communicate with your internal services that use private certificate authorities.
However, some integrations with Infisical may need to communicate with your internal services that use private certificate authorities.
To configure trust for custom certificates, follow these steps. This is particularly useful for connecting Infisical with self-hosted services like GitLab.
## Prerequisites
- Docker
- Standalone [Infisical image](https://hub.docker.com/r/infisical/infisical)
- Certificate public key `.pem` files
- Certificate public key `.crt` files
## Setup
1. Place all your public key `.pem` files into a single directory.
2. Mount the directory containing the `.pem` files to the `usr/local/share/ca-certificates/` path in the Infisical container.
1. Place all your public key `.crt` files into a single directory.
2. Mount the directory containing the `.crt` files to the `/usr/local/share/ca-certificates/` path in the Infisical container.
3. Set the following environment variable on your Infisical container:
```
NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-certificates.crt