mirror of
https://github.com/awatertrevi/infisical.git
synced 2026-10-02 18:25:45 +00:00
Merge remote-tracking branch 'origin/main' into feat/acme-and-external-ca
This commit is contained in:
Sheen Capadngan
@@ -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.
|
||||
|
||||
</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**.
|
||||
|
||||
In the edit modal that appears, choose the projects you want the Gateway to access and click **Save** to confirm your selections.
|
||||
|
||||
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">
|
||||
|
||||
</Step>
|
||||
<Step title="Select domain">
|
||||
Select the domain in which you want to create the Infisical user account.
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Navigate to 'Users'">
|
||||
|
||||
</Step>
|
||||
<Step title="Click 'Create user'">
|
||||
|
||||
</Step>
|
||||
<Step title="Create user">
|
||||
The name, email, and username can be anything.
|
||||
|
||||
|
||||
</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'.
|
||||
|
||||
|
||||
</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'.
|
||||
|
||||
|
||||
|
||||
<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.
|
||||
|
||||
|
||||
</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**.
|
||||
|
||||
|
||||
|
||||
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).
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Now create a new OCI Auth Method.
|
||||
|
||||
|
||||
|
||||
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**.
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
### 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**.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -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**.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
@@ -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).
|
||||
|
||||
|
||||
|
||||
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)).
|
||||
|
||||
|
||||
|
||||
## 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.
|
||||
|
||||
|
||||
2.2. Next, enable **OIDC Group Membership Mapping** on the **Single Sign-On (SSO)** page under the **General** tab.
|
||||
|
||||
|
||||
2.3. The next time a user logs in they will be synced to their matching OIDC groups.
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
+5
-4
@@ -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**.
|
||||
|
||||
|
||||
|
||||
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>
|
||||
|
||||
|
||||
|
||||
|
||||
To configure OIDC via the custom endpoints, set the **Configuration Type** field to **Custom** and input the required endpoint fields.
|
||||
|
||||
|
||||
|
||||
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
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Enforce OIDC SSO in Infisical">
|
||||
Reference in New Issue
Block a user