By default, Infisical Cloud is a secure, multi-tenant service. For enterprises with stricter isolation or regulatory needs, dedicated cloud instances are available.
Contact [sales@infisical.com](mailto:sales@infisical.com) to learn more.
The open-source core is available under the MIT license. Additional enterprise features and support are available with a commercial license.
Contact [sales@infisical.com](mailto:sales@infisical.com) to learn more.
## Projects
A [project](/documentation/platform/project) belongs to an organization and defines a specific scope of work. Each project has a product type such as Secrets Management, SSH, or PKI that determines what features are available in that project.
For example:
* A Secrets Management project manages application secrets across environments.
* An SSH project enables certificate-based access to infrastructure.
* A PKI project manages certificate authorities and X.509 certificate workflows.
Users are added to a project and assigned [project-level roles](/documentation/platform/access-controls/role-based-access-controls#project-level-access-controls) that determine what they can manage—such as secrets, access policies, or certificate authorities. A user can have different roles across projects, allowing for flexible and fine-grained access control that reflects how teams operate in practice.
## Key Characteristics
* Projects are isolated in terms of configuration, permissions, and product workflows.
* Access is managed independently at both the organization and project level.
* All projects within an organization share the same billing and user directory.
Teams can adopt Infisical incrementally—starting with one product and expanding as needed.
# Platform Identity and Access Management
Source: https://infisical.com/docs/documentation/getting-started/concepts/platform-iam
Understand how users, machine identities, roles, and permissions are managed.
Infisical uses identity-based access control to govern how users and systems interact with secrets, certificates, infrastructure, and other resources on the platform.
There are two types of identities:
* [User identities](/documentation/platform/identities/user-identities): Represent individuals such as developers or administrators that typically access the platform via browser.
* [Machine identities](/documentation/platform/identities/machine-identities): Represent systems such as CI pipelines or applications that programmatically interact with the platform.
Each identity is granted access based on its assigned roles and permissions and must authenticate with the platform in order to access any resources.
To learn more, refer to the [identities documentation](/documentation/platform/identities/overview).
## Roles and Access
Infisical provides a robust and flexible access control system. The primary authorization mechanism is [role-based access control (RBAC)](/documentation/platform/access-controls/role-based-access-controls), where identities are assigned roles at two access control levels:
* [Organization-level access control](/documentation/platform/access-controls/role-based-access-controls#organization-level-access-controls): Control billing, member management, and platform-wide settings
* [Project-level access control](/documentation/platform/access-controls/role-based-access-controls#project-level-access-controls): Control access to specific product resources like secrets, SSH hosts, or certificates
Beyond RBAC, Infisical also supports additional project-level permissioning features, [including attribute-based access control (ABAC)](/documentation/platform/access-controls/abac/overview), [temporary access grants](/documentation/platform/access-controls/temporary-access), and [additional privileges](/documentation/platform/access-controls/additional-privileges) for select project types.
To learn more, refer to the [access control documentation](/documentation/platform/access-controls/overview).
# What is Infisical?
Source: https://infisical.com/docs/documentation/getting-started/introduction
The open source platform for managing secrets, certificates, and secure infrastructure access.
## What is Infisical?
[Infisical](https://infisical.com) is the [open source](https://github.com/Infisical/infisical), all-in-one platform for secrets, certificates, and privileged access management.
It provides modern security workflows — including secrets rotation, dynamic credentials, access approvals, and SSH certificate-based access — all within one platform designed for developers, infrastructure, and security teams.
Start managing secrets securely with [Infisical Cloud](https://app.infisical.com) or learn how to [host Infisical](/self-hosting/overview) yourself.
## Why use Infisical?
Managing secrets, credentials, and infrastructure access is a critical concern for engineering teams. As infrastructure scales and environments become more complex, [secrets start to sprawl](https://infisical.com/blog/what-is-secret-sprawl) — across codebases, CI/CD pipelines, configuration files, and cloud services. This makes them difficult to track, rotate, and secure.
Without proper management, secret sprawl turns into risk: hardcoded credentials, unrotated keys, fragmented access controls that attackers can exploit amongst other things.
Infisical addresses this challenge by providing an all-in-one platform and workflows to:
* Securely store and manage application secrets from development to production.
* Scan code and pipelines for exposed credentials.
* Automate X.509 certificate issuance and renewal.
* Manage SSH access using short-lived, policy-driven certificates.
* Encrypt and decrypt sensitive data with centralized key control.
* Audit every access, credential use, and change.
Infisical is designed to integrate cleanly into your stack—improving security without adding complexity.
## What does Infisical include?
Infisical consists of several tightly integrated products, each designed to solve a specific part of the infrastructure security surface:
* [Secrets Management](/documentation/platform/secrets-mgmt/overview): Securely store, access, and distribute secrets across environments with fine-grained controls, automatic rotation, and audit logging.
* [Secrets Scanning](/documentation/platform/secret-scanning/overview): Detect hardcoded secrets in code, CI pipelines, and infrastructure—integrated with GitHub, GitLab, Bitbucket, and more.
* [Certificate Management](/documentation/platform/pki/overview): Issue and manage X.509 certificates using protocols like EST, with support for internal and external CAs.
* [Infisical SSH](/documentation/platform/ssh/overview): Provide short-lived SSH access to servers using certificate-based authentication, replacing static keys with policy-driven, time-bound control.
* [Infisical KMS](/documentation/platform/kms/overview): Encrypt and decrypt data using centrally managed keys with enforced access policies and full audit visibility.
* [Infisical PAM](/documentation/platform/pam/overview): Manage access to resources like databases, servers, and accounts with policy-based controls and approvals.
# Overview
Source: https://infisical.com/docs/documentation/getting-started/overview
The open source platform for managing secrets, certificates, and secure infrastructure access.
2. Edit the `dynamic-secret-crd` with the proper machine **Identity ID**, **Project Slug**, **dynamicSecret.secretName** (same as the **Secret Name** you gave to the dynamic secret in Infisical), and managedSecretReference.secretName (name of the kubernetes secret that Infisical Operator will create/populate in the cluster).
* If you want to keep the **managedSecretReference.secretName** then you can leave it as **dynamic-secret-test**
3. Once the changes have been saved, apply the yaml:
```console theme={"dark"}
kubectl apply -f dynamic-secret-crd.yaml
```
4. After applying the CRD, you should notice that the dynamic secret lease has been created and synced with your cluster. Verify by running:
```console theme={"dark"}
kubectl get secret dynamic-secret-test -n default -o yaml
```
5. Once the dynamic secret lease has been created, you should see that the secret has data that contains the lease credentials.
### Personal Overrides
By default, all the secrets in the Infisical environments are shared among project members who have the permission to access those environment. At the same time, when doing local development, it is often desirable to change the value of a certain secret only for a particular self. For such use cases, Infisical supports the functionality of **Personal Overrides** – which allow developers to override values of any secrets without affecting the workflows of the rest of the team. Personal Overrides can be created both in the dashboard or via [Infisical CLI](/cli/overview).
### Secret Scanning
In addition, Infisical also provides a set of tools to automatically prevent secret leaks to git history. This functionality can be set up on the level of [Infisical CLI using pre-commit hooks](/cli/scanning-overview#automatically-scan-changes-before-you-commit) or through a direct integration with platforms like GitHub.
# Microsoft Power Apps
Source: https://infisical.com/docs/documentation/guides/microsoft-power-apps
Learn how to manage secrets in Microsoft Power Apps with Infisical.
In recent years, there has been a shift towards so-called low-code and no-code platforms. These platforms are particularly appealing to businesses without internal development capabilities, yet teams often discover that some coding is necessary to fully satisfy their business needs.
Low-code platforms have become increasingly sophisticated and useful, leading to a rise in their adoption by businesses. A prime example is Microsoft Power Apps, which offers a range of data sources and service integrations right out of the box. However, even with advanced tools, you might not always find a ready-made solution for every challenge. This means that low-code doesn't equate to no-code, as some coding and customization are still required to cater to specific needs.
Consider the need for data integrations where an HTTP-based call to a web service might be necessary, typically requiring authentication through an API key or another type of secret.
Importantly, it's crucial to avoid hardcoding these secrets, as they would then be accessible to anyone with collaboration rights to the code. This underscores the importance of using a secret management solution like Infisical.
In this article, we'll demonstrate how to retrieve app secrets from Infisical for use in a Power Apps application. We'll create a simple application with a dedicated data connector to illustrate the ease of integrating Infisical with Power Apps. This tutorial assumes some prior programming experience in C#.
Prerequisites:
* Created Microsoft Power App.
Place it in a subscription using any resource group. The name of the function is arbitrary. We'll use .NET as a runtime stack, but you can use whatever you're most comfortable with. The OS choice is also up to you. While Linux may look like a lightweight solution, Windows actually has more Azure Functions support. For instance, you cannot edit a Linux-based Azure Function within the Azure management portal.
By using a consumption plan, we'll only pay for the resources we use when they are requested. This is the classic “serverless” approach, where you do not pay for running servers, only for interactivity.
Once the new Azure Functions instance is ready, we add a function. In this case, we can do that already from the Azure Management Portal. Use the “HTTP trigger” template and choose the “function” authorization level.
The code for the first function can be as simple as:
```
using System.Net;
public static async Task
We can now fill out the fields using the information for our created function. The combination boxes are automatically filled in order. Once we select one of the reachable subscriptions (tied to the same account we’ve used to log in to create a Power App), the available services are displayed. Once we select our Azure Functions service, we select the function for retrieving the secret.
In your policies, metadata values are accessed as follows:
* **User ID:** `{{ identity.id }}` (always available)
* **Username:** `{{ identity.username }}` (always available)
* **Metadata Attributes:** `{{ identity.metadata.
2. When a developer requests access to one of such sensitive resources, the request is visible in the dashboard, and the corresponding eligible approvers get an email notification about it.
3. An eligible approver can approve or reject the access request.
2. Click `Add Additional Privileges` in the corresponding section of the permission management modal.
3. Fill out the necessary parameters in the privilege entry that appears. It is possible to specify the `Environment` and `Secret Path` to which you want to enable access.
It is also possible to define the range of permissions (`View`, `Create`, `Modify`, `Delete`) as well as how long the access should last (e.g., permanent or timed).
4. Click the `Save` button to enable the additional privilege.
# Assume Privileges
Source: https://infisical.com/docs/documentation/platform/access-controls/assume-privilege
Learn how to temporarily assume the privileges of a user or machine identity within a project.
This feature allows authorized users to temporarily take on the permissions of another user or identity. It helps administrators and access managers test and verify permissions before granting access, ensuring everything is set up correctly.
It also reduces back-and-forth with end users when troubleshooting permission-related issues.
## How It Works
When an authorized user activates assume privileges mode, they temporarily inherit the target user or identity’s permissions for up to one hour.\
During this time, they can perform actions within the system with the same level of access as the target user.
* **Permission-based**: Only permissions are inherited, not the full identity
* **Time-limited**: Access automatically expires after one hour
* **Audited**: All actions are logged under the original user's account. This means any action taken during the session will be recorded under the entity assuming the privileges, not the target entity.
* **Authorization required**: Only users with the specific **assume privilege** permission can use this feature
* **Scoped to a single project**: You can only assume privileges for one project at a time
## How to Assume Privileges
# Requesting Access to a Project
To request access to a project you don't currently have access for:
1. Click the **Request Access** button next to the project name
2. Add a comment explaining why you need access
3. Click **Submit Request**
## Project-level access controls
By default, every user in a project is either a **viewer**, **developer**, or an **admin**. Each of these roles comes with a varying access to different features and resources inside projects.
As such:
* **Admin**: This role enables identities to have access to all environments, folders, secrets, and actions within the project.
* **Developers**: This role restricts identities from performing project control actions, updating Approval Workflow policies, managing roles, editing and removing project members, and more.
* **Viewer**: The most limiting bulit-in role on the project level – it forbids user and machine identities to perform any action and rather shows them in the read-only mode.
## Creating custom roles
By creating custom roles, you are able to adjust permissions to the needs of your organization. This can be useful for:
* Creating superadmin roles, roles specific to SRE engineers, etc.
* Restricting access of users to specific secrets, folders, and environments.
* Embedding these specific roles into [Approval Workflow policies](/documentation/platform/pr-workflows).
# Temporary Access
Source: https://infisical.com/docs/documentation/platform/access-controls/temporary-access
Learn how to set up timed access to sensitive resources for user and machine identities.
Certain environments and secrets are so sensitive that it is recommended to not give any user permanent access to those. For such use cases, Infisical supports the functionality of **Temporary Access** provisioning.
To provision temporary access through Web UI:
1. Click on the `Edit` button next to the set of roles for user or identities.
2. Click `Permanent` next to the role or specific privilege that you want to make temporary.
3. Specify the duration of remporary access (e.g., `1m`, `2h`, `3d`).
4. Click `Grant`.
5. Click the corresponding `Save` button to enable remporary access.
## General Tab
Configure general settings for your instance.
### Allow User Signups
User signups are enabled by default, allowing **Anyone** with access to your instance to sign up. This can alternatively be **Disabled** to prevent any users from signing up.
### Restrict Signup Domain
Signup can be restricted to users matching one or more email domains, such as your organization's domain, to control who has access to your instance.
### Default Organization
If you're using SAML/LDAP/OIDC for only one organization on your instance, you can specify a default organization to use at login to skip requiring users to manually enter the organization slug.
### Trust Emails
By default, users signing up through SAML/LDAP/OIDC will still need to verify their email address to prevent email spoofing. This requirement can be skipped by enabling the switch to trust logins through the respective method.
### Broadcast Messages
Auth consent content is displayed to users on the login page. They can be used to display important information to users, such as a maintenance message or a new feature announcement. Both HTML and Markdown formatting are supported, allowing for customized styling like below:
```
**You are entering a confidential website**
```
```html theme={"dark"}
You are entering a confidential website
```
Page frame content is displayed as a header and footer in ALL protected pages. Like the auth consent content, both HTML and Markdown formatting are supported here as well.
## Authentication Tab
From this tab, you can configure which login methods are enabled for your instance.
## Rate Limit Tab
This tab allows you to set various rate limits for your Infisical instance. You do not need to redeploy when making changes to rate limits as these will be propagated automatically.
Once you're finished, click **Create Log Stream**.
Configure your Data Collection Endpoint by providing an **Endpoint Name**, **Subscription**, and a **Resource group**. Then click **Review + Create**.
After creation, it may take a few minutes for the Data Collection Endpoint to appear. Once visible, click on it and copy the **Logs Ingestion** URL. You will need this URL in later steps.
Configure your Log Analytics Workspace by providing a **Subscription**, **Resource group**, and a **Name**. Then click **Review + Create**.
Once the workspace is deployed, click **Go to resource** to access it.
Configure the Custom Log Table: Provide a **Table name** (e.g., `InfisicalLogs`), select the **Data collection endpoint** created in Step 1, and create a new **Data collection rule** as illustrated in the image below. Then, click **Next**.
On the **Schema and transformation** page, you'll be prompted to upload a **Log Sample**. Create a `.json` file with the following content and upload it:
```json theme={"dark"}
{
"id": "00000000-0000-0000-0000-000000000000",
"actor": "user",
"actorMetadata": {
"email": "user@example.com",
"userId": "00000000-0000-0000-0000-000000000000",
"username": "user@example.com"
},
"ipAddress": "0.0.0.0",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36",
"userAgentType": "web",
"eventType": "get-secrets",
"eventMetadata": {},
"projectName": "MyProject",
"orgId": "00000000-0000-0000-0000-000000000000",
"projectId": "00000000-0000-0000-0000-000000000000",
"TimeGenerated": "2025-01-01T00:00:00.000Z"
}
```
Optionally, you can add **Transformations** to further destructure the data. For example, to extract actor email and userId:
```
source
| extend
ActorEmail = tostring(actorMetadata.email),
ActorUserId = tostring(actorMetadata.userId)
```
On the final step, click **Create**.
Once your source is created, take note of the **endpoint** and **Source token** for the next step.
1. Fill in the endpoint URL with your Better Stack source endpoint
2. Create a new header with key `Authorization` and set the value as `Bearer
Once you're finished, click **Create Log Stream**.
Within your Worker Group, navigate to **Data > Sources > HTTP** and click **Add Source**.
Configure the **Input ID**, **Port**, and **Cribl HTTP event API** path (e.g., `/infisical`). Then, generate an **Auth Token**.
You can optionally configure TLS in the **TLS Settings** tab and add a pipeline in the **Pre-Processing** tab.
Once you've configured the Data Source, click **Save** and deploy your changes.
Once you're finished, click **Create Log Stream**.
Once you're finished, click **Create Log Stream**.
Click on **HTTP Event Collector**.
Click on **New Token** in the top left.
Provide a name and click **Next**.
On the next page, click **Review** and then **Submit** at the top. On the final page you'll see your token.
Copy the **Token Value** and your Splunk hostname from the URL to be used for later.
Once you're finished, click **Create Log Stream**.
## Audit Log Structure
Each log contains the following data:
| Field | Type | Description | Purpose |
| ------------------------- | -------- | --------------------------------------------------------- | ------------------------------------------------------------- |
| **event** | Object | Contains details about the action performed | Captures what happened |
| event.type | String | The specific action that occurred (e.g., "create-secret") | Identifies the exact operation |
| event.metadata | Object | Context-specific details about the event | Provides detailed information relevant to the specific action |
| **actor** | Object | Information about who performed the action | Identifies the responsible entity |
| actor.type | String | Category of actor (user, service, identity, etc.) | Distinguishes between human and non-human actors |
| actor.metadata | Object | Details about the specific actor | Provides identity information |
| actor.metadata.userId | String | Unique identifier for user actors | Links to specific user account |
| actor.metadata.email | String | Email address for user actors | Email of the executing user |
| actor.metadata.username | String | Username for user actors | Username of the executing user |
| actor.metadata.serviceId | String | Identifier for service actors | ID of specific service token |
| actor.metadata.identityId | String | Identifier for identity actors | ID to specific identity |
| actor.metadata.permission | Object | Permission context for the action | Shows permission template data when action was performed |
| **orgId** | String | Organization identifier | Indicates which organization the action occurred in |
| **projectId** | String | Project identifier | Indicates which project the action affected |
| **ipAddress** | String | Source IP address | Shows where the request originated from |
| **userAgent** | String | Client application information | Identifies browser or application used |
| **userAgentType** | String | Category of client (web, CLI, SDK, etc.) | Classifies the access method |
| **timestamp** | DateTime | When the action occurred | Records the exact time of the event |
2. Scroll down to the `Emergency Kit` section.
3. Enter your current password and click `Save`.
### Change Password
You can update your account password at any time:
1. Open the `Personal Settings` menu.
2. Navigate to the `Authentication` tab.
3. In the `Change Password` section, enter your current password and new password.
4. Click `Save` to save your new password.
### Change Email
You can update your account email address:
1. Open the `Personal Settings` menu.
2. Navigate to the `Authentication` tab.
3. In the `Change Email` section, enter your new email address.
4\. Click `Send Verification Code` to receive an 6-digit verification code at your new email address.
5\. Check your new email inbox and enter the verification code.
6\. Click `Confirm Email Change` to complete the process.
7\. You will be logged out and need to sign in again with your new email address.
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
## Renew Leases
To extend the life of the generated dynamic secret leases past its initial time to live, simply click on the **Renew** button as illustrated below.
2. Select **AWS Account** as the **Trusted Entity Type**.
3. Select **Another AWS Account** and provide the appropriate Infisical AWS Account ID: use **381492033652** for the **US region**, and **345594589636** for the **EU region**. This restricts the role to be assumed only by Infisical. If self-hosting, provide your AWS account number instead.
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
5. Attach the permission policy detailed in the **Prerequisite** section at the top of this page.
6. After creating the role, edit its **Trust relationship** to specify the service account Infisical is using in your cluster. This ensures only the Infisical pod can assume this role.
```json theme={"dark"}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
## Renew Leases
To extend the life of the generated dynamic secret lease past its initial time to live, simply click on the **Renew** button as illustrated below.
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
## Renew Leases
To extend the life of the generated dynamic secret leases past its initial time to live, simply click on the **Renew** button as illustrated below.
Azure SQL Database dynamic secrets use predefined SQL statements that follow Azure's security best practices:
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
## Renew Leases
To extend the life of the generated dynamic secret leases past its initial time to live, simply click on the **Renew** button as illustrated below.
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
## Renew Leases
To extend the life of the generated dynamic secret lease past its initial time to live, simply click on the **Renew** button as illustrated below.
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
## Renew Leases
To extend the life of the generated dynamic secret leases past its initial time to live, simply click on the **Renew** button as illustrated below.
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
## Renew Leases
To extend the life of the generated dynamic secret leases past its initial time to live, simply click on the **Renew** button as illustrated below.
Press "DONE" after creating the service account.
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
## Renew Leases
To extend the life of the generated dynamic secret leases past its initial time to live, simply click on the **Renew** button as illustrated below.
Give the application a name and a homepage URL. These values do not need to be anything specific.
Disable webhook by unchecking the Active checkbox.
Configure the app's permissions to grant the necessary access for the dynamic secret's short-lived tokens based on your use case.
Create the GitHub Application.
Save these for later steps.
Once you've installed the app, **copy the installation ID** from the URL and save it for later steps.
When generating these secrets, the TTL will be fixed to 1 hour.
Once you click the `Submit` button, a new secret lease will be generated and the credentials from it will be shown to you.
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
## Audit or Revoke Leases
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
This will allow you to see the lease details and delete the lease ahead of its expiration time.
# LDAP
Source: https://infisical.com/docs/documentation/platform/dynamic-secrets/ldap
Learn how to dynamically generate user credentials via LDAP.
The Infisical LDAP dynamic secret allows you to generate user credentials on demand via LDAP. The integration is general to any LDAP implementation but has been tested with OpenLDAP and Active directory as of now.
## Prerequisites
1. Create a user with the necessary permissions to create users in your LDAP server.
2. Ensure your LDAP server is reachable via Infisical instance.
## Create LDAP Credentials
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
## Renew Leases
To extend the life of the generated dynamic secret leases past its initial time to live, simply click on the **Renew** button as illustrated below.
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
## Renew Leases
To extend the life of the generated dynamic secret leases past its initial time to live, simply click on the **Renew** button as illustrated below.
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
## Renew Leases
To extend the life of the generated dynamic secret leases past its initial time to live, simply click on the **Renew** button as illustrated below.
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
## Renew Leases
To extend the life of the generated dynamic secret leases past its initial time to live, simply click on the **Renew** button as illustrated below.
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
## Renew Leases
To extend the life of the generated dynamic secret leases past its initial time to live, simply click on the **Renew** button as illustrated below.
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
## Renew Leases
To extend the life of the generated dynamic secret leases past its initial time to live, simply click on the **Renew** button as illustrated below.
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
## Renew Leases
To extend the life of the generated dynamic secret leases past its initial time to live, simply click on the **Renew** button as illustrated below.
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
## Renew Leases
To extend the life of the generated dynamic secret leases past its initial time to live, simply click on the **Renew** button as illustrated below.
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
## Renew Leases
To extend the life of the generated dynamic secret lease past its initial time to live, simply click on the **Renew** as illustrated below.
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
## Renew Leases
To extend the life of the generated dynamic secret lease past its initial time to live, simply click on the **Renew** button as illustrated below.
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how
long the credentials are valid for.
## Renew Leases
To extend the life of the generated dynamic secret lease past its initial time to live, simply click on the **Renew** button as illustrated below.
Once you click the `Generate` button, a new secret lease will be generated and the TOTP will be shown to you.
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
## Renew Leases
To extend the life of the generated dynamic secret leases past its initial time to live, simply click on the **Renew** button as illustrated below.
On your project page, open **Project Settings** from the sidebar.
In the Project name section, click **Copy Project ID** to copy your Project ID, or extract it from the URL:
`https://app.infisical.com/project/
Navigate to **Access Management**, then select **Project Roles**.
You can either edit an existing role or create a new role
for event subscriptions.
Select the specific resources that the role should have access
to. 
Ensure the **Subscribe** action is selected for the relevant resources and events.
## Conditions
By default, the role will have access to all events for the selected resources in this project.
**Request Parameters:**
* `projectId`: Project whose events you want to subscribe to
* `register`: List of event filters
* `conditions`: Conditions to filter events on
* `environmentSlug`: Project environment
* `secretPath`: Path of the secrets
The subscribe endpoint responds with a `text/event-stream` content type to initiate SSE streaming.
For more specific details, please refer to our [API Reference](/api-reference/endpoints/events).
# Migrating from EnvKey to Infisical
Source: https://infisical.com/docs/documentation/platform/external-migrations/envkey
Learn how to migrate secrets from EnvKey to Infisical.
## Migrating from EnvKey
Configure your namespace:
* **Namespace**: Enter your Vault namespace path (e.g., `admin/namespace1`). If you intend to use the root namespace, set the namespace value to "root".
* **Connection**: Select the App Connection you created in the previous step.
4. Choose your Vault namespace and the secret path you want to import
5. Click **"Import Secrets"**
The secrets will be imported into your current environment and folder path.
#### Import Kubernetes Authentication Configurations
When setting up Kubernetes authentication for a machine identity, you can import the configuration from Vault:
1. Navigate to **Access Control > Machine Identities** and select an identity
2. Click **"Add Authentication Method"** and choose **Kubernetes Auth**
3. In the configuration modal, click **"Load from Vault"**
4. Select your Vault namespace and the Kubernetes role
5. Click **"Load"**
The authentication settings (service accounts, TTL, policies, etc.) will be automatically populated from your Vault configuration.
5. Select your Vault namespace, Kubernetes secrets engine mount, and role
6. Click **"Load Configuration"**
The form will be automatically populated with the role's configuration including:
* Cluster URL and CA certificate
* Credential type (Static or Dynamic)
* Service account name or Kubernetes role settings
* Allowed namespaces
* Token TTL values
* Token audiences
3. Select your Vault namespace
4. Either choose an existing policy from the dropdown or paste your own HCL policy
5. Review the automatically translated Infisical permissions
6. Make any adjustments and save
Under the "Bulk Data Import" section, click **"+ Import"**.
* **Vault URL**: Your Vault instance URL (e.g., `https://vault.example.com`)
* **Vault Namespace**: Optional - only needed if using Vault Enterprise namespaces
* **Vault Access Token**: The token you generated in step 2
* **Project Mapping**: Choose how to structure your Infisical projects (see [Understanding Project Mapping](#understanding-project-mapping))
Click **"Import Data"** to start the migration.
To delete a folder, hover over it and press the **X** button that appears on the right side.
### Comparing folders
It's possible to compare the contents of folders across environments in the **Secrets Overview** page.
When you click on a folder, the table will display the items within it across environments.
In the image below, you can see that the **Development** environment is the only one that contains items
in the `/users` folder, being other folders `/user-a`, `/user-b`, ... `/user-f`.
### Replicating Folder Contents
If you want to copy secrets or folders from one path to another, you can utilize the **Replicate Secrets** functionality located in the **Add Secret** dropdown.
First, select the **Source Environment** and the **Source Root Path** you want to copy secrets *from*. In the example provided, we select `/dev-folder` as the source root path from the Development environment. This means any secrets within `/dev-folder` from Development will be replicated. By default, these secrets are copied into the *currently active* folder/path in your target environment (e.g., the root folder of your Staging environment in this scenario).
As a final step, you can select the specific secrets you wish to copy and then click **Replicate Secrets**.
The result shows two secrets successfully copied from the `/dev-folder` in the Development environment into the root folder of the Staging environment.
The Infisical Gateway provides secure access to private resources within your network without needing direct inbound connections to your environment.
This is particularly useful when Infisical isn't hosted within the same network as the resources it needs to reach.
This method keeps your resources fully protected from external access while enabling Infisical to securely interact with resources like databases.
2. Click the **Configure** button and provide the name of your GitHub Organization.
2. Select the organization you have connected.
3. Grant access to Infisical oauth application to your configured organization. Infisical shown here is an organization, just for walkthrough.
The sync operation will process all organization members who have previously logged in with GitHub and update their team memberships accordingly.
When creating a group, you specify an organization level [role](/documentation/platform/access-controls/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
Now input a few details for your new group. Here’s some guidance for each field:
* Name (required): A friendly name for the group like `Engineering`.
* Slug (required): A unique identifier for the group like `engineering`.
* Role (required): A role from the Organization Roles tab for the group to assume. The organization role assigned will determine what organization level resources this group can have access to.
In this example, we're assigning **Alan Turing** and **Ada Lovelace** to the group **Engineering**.
Next, select the group you want to add to the project and the project level role you want to allow it to assume. The project role assigned will determine what project level resources this group can have access to.
That's it!
The users of the group now have access to the project under the role you assigned to the group.
When creating an identity, you specify an organization-level [role](/documentation/platform/access-controls/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 Alibaba Cloud Auth instead. To do this, click the cog next to **Universal Auth** and then select **Delete** in the options dropdown.
Now create a new Alibaba Cloud Auth Method.
Here's some information about each field:
* **Allowed ARNs:** A comma-separated list of trusted Alibaba Cloud ARNs 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 `GetCallerIdentity` request and then make a request to the `/api/v1/auth/alicloud-auth/login` endpoint passing the signed data and signature.
Below is an example of how you can authenticate with Infisical using NodeJS.
```ts theme={"dark"}
import crypto from "crypto";
// We highly recommend using environment variables instead of hardcoding these values
const ALICLOUD_ACCESS_KEY_ID = "...";
const ALICLOUD_ACCESS_KEY_SECRET = "...";
const params: { [key: string]: string } = {
Action: "GetCallerIdentity",
Format: "JSON",
Version: "2015-04-01",
AccessKeyId: ALICLOUD_ACCESS_KEY_ID,
SignatureMethod: "HMAC-SHA1",
Timestamp: new Date().toISOString(),
SignatureVersion: "1.0",
SignatureNonce: crypto.randomBytes(16).toString("hex"),
};
const canonicalizedQueryString = Object.keys(params)
.sort()
.map((key) => `${encodeURIComponent(key)}=${encodeURIComponent(params[key])}`)
.join("&");
const stringToSign = `GET&%2F&${encodeURIComponent(canonicalizedQueryString)}`;
const signature = crypto
.createHmac("sha1", `${ALICLOUD_ACCESS_KEY_SECRET}&`)
.update(stringToSign)
.digest("base64");
const res = await fetch(
"https://app.infisical.com/api/v1/auth/alicloud-auth/login",
{
method: "POST",
headers: {
"Content-Type": "application/json",
},
body: JSON.stringify({
identityId: "...", // Replace with your identity ID
Signature: signature,
...params,
}),
},
);
const json = await res.json();
console.log("Infisical Response:", JSON.stringify(json));
```
### Creating a Template
Select the authentication method you want to create a template for (currently supports LDAP Auth).
* **Template Name**: A descriptive name for your template
* **URL**: The LDAP server to connect to such as `ldap://ldap.your-org.com`, `ldaps://ldap.myorg.com:636` *(for connection over SSL/TLS)*, etc.
* **Bind DN**: The DN to bind to the LDAP server with.
* **Bind Pass**: The password to bind to the LDAP server with.
* **Search Base / DN**: Base DN under which to perform user search such as `ou=Users,dc=acme,dc=com`.
* **CA Certificate**: The CA certificate to use when verifying the LDAP server certificate. This field is optional but recommended.
### Managing Template Usage
You can view which identities are using a specific template by clicking **View Usages** in the template's dropdown menu.
## FAQ
When creating an identity, you specify an organization level [role](/documentation/platform/access-controls/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
Now input a few details for your new identity. Here's some guidance for each field:
* Name (required): A friendly name for the identity.
* Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.
Once you've created an identity, you'll be redirected to a page where you can manage the identity.
Since the identity has been configured with Universal Auth by default, you should re-configure it to use AWS Auth instead. To do this, press to edit the **Authentication** section,
remove the existing Universal Auth configuration, and add a new AWS Auth configuration onto the identity.
Here's some more guidance on each field:
* Allowed Principal ARNs: A comma-separated list of trusted IAM principal ARNs that are allowed to authenticate with Infisical. The values should take one of three forms: `arn:aws:iam::123456789012:user/MyUserName`, `arn:aws:iam::123456789012:role/MyRoleName`, or `arn:aws:iam::123456789012:*`. Using a wildcard in this case allows any IAM principal in the account `123456789012` to authenticate with Infisical under the identity.
* Allowed Account IDs: A comma-separated list of trusted AWS account IDs that are allowed to authenticate with Infisical.
* STS Endpoint (default is `https://sts.amazonaws.com/`): The endpoint URL for the AWS STS API. This value should be adjusted based on the AWS region you are operating in (e.g. `https://sts.us-east-1.amazonaws.com/`); refer to the list of regional STS endpoints [here](https://docs.aws.amazon.com/general/latest/gr/sts.html).
* Access Token TTL (default is `2592000` equivalent to 30 days): The lifetime for an acccess 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 acccess 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 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.
When creating an identity, you specify an organization level [role](/documentation/platform/access-controls/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
Now input a few details for your new identity. Here's some guidance for each field:
* Name (required): A friendly name for the identity.
* Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.
Once you've created an identity, you'll be redirected to a page where you can manage the identity.
Since the identity has been configured with Universal Auth by default, you should re-configure it to use Azure Auth instead. To do this, press to edit the **Authentication** section,
remove the existing Universal Auth configuration, and add a new Azure Auth configuration onto the identity.
Here's some more guidance on each field:
* Tenant ID: The [tenant ID](https://learn.microsoft.com/en-us/entra/fundamentals/how-to-find-tenant) for the Azure AD organization.
* Resource / Audience: The resource URL for the application registered in Azure AD. The value is expected to match the `aud` claim of the access token JWT later used in the login operation against Infisical. See the [resource](https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/how-to-use-vm-token#get-a-token-using-http) parameter for how the audience is set when requesting a JWT access token from the Azure Instance Metadata Service (IMDS) endpoint. In most cases, this value should be `https://management.azure.com/` which is the default.
* Allowed Service Principal IDs: A comma-separated list of Azure AD service principal IDs that are allowed to authenticate with Infisical.
* Access Token TTL (default is `2592000` equivalent to 30 days): The lifetime for an acccess 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 acccess 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 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.
When creating an identity, you specify an organization level [role](/documentation/platform/access-controls/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
Now input a few details for your new identity. Here's some guidance for each field:
* Name (required): A friendly name for the identity.
* Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.
Once you've created an identity, you'll be redirected to a page where you can manage the identity.
Since the identity has been configured with Universal Auth by default, you should re-configure it to use GCP Auth instead. To do this, press to edit the **Authentication** section,
remove the existing Universal Auth configuration, and add a new GCP Auth configuration onto the identity; set the **Type** field to **GCP ID Token Auth**.
Here's some more guidance on each field:
* Allowed Service Account Emails: A comma-separated list of trusted service account emails corresponding to the GCE resource(s) allowed to authenticate with Infisical; this could be something like `test@project.iam.gserviceaccount.com`, `12345-compute@developer.gserviceaccount.com`, etc.
* Allowed Projects: A comma-separated list of trusted GCP projects that the GCE instance must belong to authenticate with Infisical. Note that this validation property will only work for GCE instances.
* Allowed Zones: A comma-separated list of trusted zones that the GCE instances must belong to authenticate with Infisical; this should be the fully-qualified zone name in the format `
When creating an identity, you specify an organization level [role](/documentation/platform/access-controls/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
Now input a few details for your new identity. Here's some guidance for each field:
* Name (required): A friendly name for the identity.
* Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.
Once you've created an identity, you'll be redirected to a page where you can manage the identity.
Since the identity has been configured with Universal Auth by default, you should re-configure it to use GCP Auth instead. To do this, press to edit the **Authentication** section,
remove the existing Universal Auth configuration, and add a new GCP Auth configuration onto the identity; set the **Type** field to **GCP IAM Auth**.
Here's some more guidance on each field:
* Allowed Service Account Emails: A comma-separated list of trusted IAM service account emails that are allowed to authenticate with Infisical; this could be something like `test@project.iam.gserviceaccount.com`, `12345-compute@developer.gserviceaccount.com`, etc.
* Access Token TTL (default is `2592000` equivalent to 30 days): The lifetime for an acccess 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 acccess 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 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.
When creating an identity, you specify an organization level [role](/documentation/platform/access-controls/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
Now input a few details for your new identity. Here's some guidance for each field:
* Name (required): A friendly name for the identity.
* Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.
Once you've created an identity, you'll be redirected to a page where you can manage the identity.
Since the identity has been configured with Universal Auth by default, you should re-configure it to use JWT Auth instead. To do this, press to edit the **Authentication** section,
remove the existing Universal Auth configuration, and add a new JWT Auth configuration onto the identity.
When creating an identity, you specify an organization level [role](/documentation/platform/access-controls/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
Now input a few details for your new identity. Here's some guidance for each field:
* Name (required): A friendly name for the identity.
* Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.
Once you've created an identity, you'll be redirected to a page where you can manage the identity.
Since the identity has been configured with Universal Auth by default, you should re-configure it to use Kubernetes Auth instead. To do this, press to edit the **Authentication** section,
remove the existing Universal Auth configuration, and add a new Kubernetes Auth configuration onto the identity.
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.
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.
* Allowed Audience: An optional audience claim that the service account JWT token must have to authenticate with Infisical.
* CA Certificate: The PEM-encoded CA cert for the Kubernetes API server. This is used by the TLS client for secure communication with the Kubernetes API server.
* Access Token TTL (default is `2592000` equivalent to 30 days): The lifetime for an acccess 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 acccess 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 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.
When creating an identity, you specify an organization level role for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
Now input a few details for your new identity. Here's some guidance for each field:
* Name (required): A friendly name for the identity.
* Role (required): A role from the Organization Roles tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.
Once you've created an identity, you'll be redirected to a page where you can manage the identity.
Now select **LDAP Auth** from the list of available auth methods for the identity.
After selecting **LDAP Auth**, you'll see the form you need to fill out to configure LDAP auth for your identity. The following fields are available:
**Configuration Tab**
* `URL`: The LDAP server to connect to such as `ldap://ldap.your-org.com`, `ldaps://ldap.myorg.com:636` *(for connection over SSL/TLS)*, etc.
* `Bind DN`: The DN to bind to the LDAP server with.
* `Bind Pass`: The password to bind to the LDAP server with.
* `Search Base / DN`: Base DN under which to perform user search such as `ou=Users,dc=acme,dc=com`.
* `User Search Filter`: Template used to construct the LDAP user search filter such as `(uid={{username}})`; use literal `{{username}}` to have the given username used in the search. The default is `(uid={{username}})` which is compatible with several common directory schemas.
* `Required Attributes`: A key/value pair of attributes that must be present in the LDAP user entry for them to be authenticated. As an example, if you set key `uid` to value `user1,user2,user3`, then only users with `uid` of `user1`, `user2`, or `user3` will be able to login with this identity. Each value is a comma separated list of attributes.
* `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 infinite number of uses.
**Lockout Tab**
* `Lockout` *(enabled by default)*: The lockout feature will temporarily block login attempts after X consecutive login failures.
* `Lockout Threshold` *(default is 3)*: The amount of times login must fail before locking the identity auth method.
* `Lockout Duration` *(default is 5 minutes)*: How long an identity auth method lockout lasts.
* `Lockout Counter Reset` *(default is 30 seconds)*: How long to wait from the most recent failed login until resetting the lockout counter.
**Advanced Tab**
* `CA Certificate`: The CA certificate to use when verifying the LDAP server certificate. This field is optional but recommended.
* `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.
Once you've filled out the form, press **Add** to save your changes.
When creating an identity, you specify an organization level role for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
Now input a few details for your new identity. Here's some guidance for each field:
* Name (required): A friendly name for the identity.
* Role (required): A role from the Organization Roles tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.
Once you've created an identity, you'll be redirected to a page where you can manage the identity.
Now select **LDAP Auth** from the list of available auth methods for the identity.
After selecting **LDAP Auth**, you'll see the form you need to fill out to configure LDAP auth for your identity. The following fields are available:
* `URL`: The LDAP server to connect to (`ldaps://ldap.jumpcloud.com:636`).
* `Bind DN`: The distinguished name of object to bind when performing the user search (`uid=
Key Features:
* Role Assignment: Identities must be assigned [roles](/documentation/platform/access-controls/role-based-access-controls). These roles determine the scope of access to resources, either at the organization level or project level.
* Auth/Token Configuration: Identities must be configured with corresponding authentication methods and access token properties to securely interact with the Infisical API.
## Scopes
Identities can be created either at the organization-level or the project-level. Outside of identity management and scope of operation, organization and project identities are functionally identical.
* Project identities are managed at the project-level and can only operate within their respective project.
Project-level identities are useful for organizations that delegate responsibility to autonomous teams via projects.
* Organization identities are managed at the organization-level and can be assigned to one or more projects, as well as
perform organization-level operations. Organization-level identities are useful for organizations that have cross-project operations.
## Workflow
When creating an identity, you specify an organization-level [role](/documentation/platform/access-controls/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 theme={"dark"}
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);
```
When creating an identity, you specify an organization level [role](/documentation/platform/access-controls/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
Now input a few details for your new identity. Here's some guidance for each field:
* Name (required): A friendly name for the identity.
* Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.
Once you've created an identity, you'll be redirected to a page where you can manage the identity.
Since the identity has been configured with Universal Auth by default, you should re-configure it to use OIDC Auth instead. To do this, press to edit the **Authentication** section,
remove the existing Universal Auth configuration, and add a new OIDC Auth configuration onto the identity.
**OIDC Discovery URL**: The URL used to retrieve the OpenID Connect configuration from the identity provider. This is used to fetch the public keys needed to verify the JWT. For Azure, set this to `https://login.microsoftonline.com/{tenant-id}/v2.0` (replace `{tenant-id}` with your Azure AD tenant ID).
* **Issuer**: The value of the `iss` claim that the token must match. For Azure, this should be `https://login.microsoftonline.com/{tenant-id}/v2.0`.
* **Subject**: This must match the `sub` claim in the JWT.
* **Audiences**: Values that must match the `aud` claim.
* **Claims**: Additional claims that must be present. Refer to [Azure DevOps docs](https://learn.microsoft.com/en-us/azure/devops/pipelines/library/connect-to-azure?view=azure-devops#workload-identity-federation) for available claims.
* **Access Token TTL**: Lifetime of the issued token (in seconds), e.g., `2592000` (30 days)
* **Access Token Max TTL**: Maximum allowed lifetime of the token
* **Access Token Max Number of Uses**: Max times the token can be used (`0` = unlimited)
* **Access Token Trusted IPs**: List of allowed IP ranges (defaults to `0.0.0.0/0`)
When creating an identity, you specify an organization level [role](/documentation/platform/access-controls/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
Now input a few details for your new identity. Here's some guidance for each field:
* Name (required): A friendly name for the identity.
* Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.
Once you've created an identity, you'll be redirected to a page where you can manage the identity.
Since the identity has been configured with Universal Auth by default, you should re-configure it to use OIDC Auth instead. To do this, press to edit the **Authentication** section,
remove the existing Universal Auth configuration, and add a new OIDC Auth configuration onto the identity.
When creating an identity, you specify an organization level [role](/documentation/platform/access-controls/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
Now input a few details for your new identity. Here's some guidance for each field:
* Name (required): A friendly name for the identity.
* Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.
Once you've created an identity, you'll be redirected to a page where you can manage the identity.
Since the identity has been configured with Universal Auth by default, you should re-configure it to use OIDC Auth instead. To do this, press to edit the **Authentication** section,
remove the existing Universal Auth configuration, and add a new OIDC Auth configuration onto the identity.
When creating an identity, you specify an organization level [role](/documentation/platform/access-controls/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
Now input a few details for your new identity. Here's some guidance for each field:
* Name (required): A friendly name for the identity.
* Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.
Once you've created an identity, you'll be redirected to a page where you can manage the identity.
Since the identity has been configured with Universal Auth by default, you should re-configure it to use OIDC Auth instead. To do this, press to edit the **Authentication** section,
remove the existing Universal Auth configuration, and add a new OIDC Auth configuration onto the identity.
When creating an identity, you specify an organization level [role](/documentation/platform/access-controls/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
Now input a few details for your new identity. Here's some guidance for each field:
* Name (required): A friendly name for the identity.
* Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.
Once you've created an identity, you'll be redirected to a page where you can manage the identity.
Since the identity has been configured with Universal Auth by default, you should re-configure it to use OIDC Auth instead. To do this, press to edit the **Authentication** section,
remove the existing Universal Auth configuration, and add a new OIDC Auth configuration onto the identity.
When creating an identity, you specify an organization level [role](/documentation/platform/access-controls/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
Now input a few details for your new identity. Here's some guidance for each field:
* Name (required): A friendly name for the identity.
* Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.
Once you've created an identity, you'll be redirected to a page where you can manage the identity.
Since the identity has been configured with Universal Auth by default, you should re-configure it to use OIDC Auth instead. To do this, press to edit the **Authentication** section,
remove the existing Universal Auth configuration, and add a new OIDC Auth configuration onto the identity.
When creating an identity, you specify an organization-level [role](/documentation/platform/access-controls/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 TLS Certificate Auth instead. To do this, click the cog next to **Universal Auth** and then select **Delete** in the options dropdown.
Now create a new TLS Certificate Auth Method.
Here's some information about each field:
* **CA Certificate:** A PEM encoded CA Certificate used to validate incoming TLS request client certificate.
* **Allowed Common Names:** A comma separated list of client certificate common names allowed.
* **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 send a TLS request to `/api/v1/auth/tls-cert-auth/login` endpoint.
Below is an example of how you can authenticate with Infisical using NodeJS.
```javascript theme={"dark"}
const fs = require("fs");
const https = require("https");
const axios = require("axios");
try {
const clientCertificate = fs.readFileSync("client-cert.pem", "utf8");
const clientKeyCertificate = fs.readFileSync("client-key.pem", "utf8");
const infisicalUrl = "https://app.infisical.com:8443"; // or your self-hosted Infisical URL
const identityId = "
When creating an identity, you specify an organization level [role](/documentation/platform/access-controls/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
Now input a few details for your new identity. Here's some guidance for each field:
* Name (required): A friendly name for the identity.
* Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.
Once you've created an identity, you'll be redirected to a page where you can manage the identity.
Since the identity has been configured with Universal Auth by default, you should re-configure it to use Token Auth instead. To do this, press to edit the **Authentication** section,
remove the existing Universal Auth configuration, and add a new Token Auth configuration onto the identity.
Here's some more guidance on each field:
* Access Token TTL (default is `2592000` equivalent to 30 days): The lifetime for an acccess 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 acccess 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 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.
Copy the token and keep it handy as you'll need it to authenticate with the Infisical API.
When creating an identity, you specify an organization level [role](/documentation/platform/access-controls/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
Now input a few details for your new identity. Here's some guidance for each field:
* Name (required): A friendly name for the identity.
* Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.
Once you've created an identity, you'll be redirected to a page where you can manage the identity.
Once you've created an identity, you'll be prompted to configure the **Universal Auth** authentication method for it.
By default, the identity has been configured with Universal Auth. If you wish, you can edit the Universal Auth configuration
details by pressing to edit the **Authentication** section.
Here's some guidance on each field:
**Configuration Tab**
* 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 infinite number of uses.
* Access Token Period (optional, default is `0`): If set, the access token becomes a renewable, non-expiring token for the specified period (in seconds). TTL and Max TTL are ignored when this is set. This is ideal for "secret zero" scenarios, where a workload needs to bootstrap itself securely without hard-coded static secrets.
**Lockout Tab**
* Lockout (enabled by default): The lockout feature will temporarily block login attempts after X consecutive login failures.
* Lockout Threshold (default is `3`): The amount of times login must fail before locking the identity auth method.
* Lockout Duration (default is `5 minutes`): How long an identity auth method lockout lasts.
* Lockout Counter Reset (default is `30 seconds`): How long to wait from the most recent failed login until resetting the lockout counter.
**Advanced Tab**
* Client Secret Trusted IPs: The IPs or CIDR ranges that the **Client Secret** can be used from together with the **Client ID** to get back an access token. By default, **Client Secrets** are given the `0.0.0.0/0`, allowing usage from any network address.
* 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.
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.
## Authentication methods
To interact with various resources in Infisical, users are able to utilize a number of authentication methods:
* **Email & Password**: the most common authentication method that is used for authentication into Web Dashboard and Infisical CLI. It is recommended to utilize [Multi-factor Authentication](/documentation/platform/mfa) in addition to it.
* **SSO**: Infisical natively integrates with a number of SSO identity providers like [Google](/documentation/platform/sso/google), [GitHub](/documentation/platform/sso/github), and [GitLab](/documentation/platform/sso/gitlab).
* **SAML SSO**: It is also possible to set up SAML SSO integration with identity providers like [Okta](/documentation/platform/sso/okta), [Microsoft Entra ID](/documentation/platform/sso/azure) (formerly known as Azure AD), [JumpCloud](/documentation/platform/sso/jumpcloud), [Google](/documentation/platform/sso/google-saml), and more.
* **LDAP**: For organizations with more advanced needs, Infisical also provides user authentication with [LDAP](/documentation/platform/ldap/overview) that includes a number of LDAP providers.
# AWS CloudHSM
Source: https://infisical.com/docs/documentation/platform/kms-configuration/aws-hsm
Learn how to manage encryption using AWS CloudHSM
This guide provides instructions on securing Infisical project secrets using AWS CloudHSM.
Integration with AWS CloudHSM is achieved by configuring it as a custom key store for AWS KMS.
Follow the steps below to set up AWS KMS with AWS CloudHSM as the custom key store.
## Prepare AWS CloudHSM Cluster
Before you get started, you'll need to configure a AWS CloudHSM cluster which meets the following criteria:
* The cluster must be active.
* The cluster must not be associated with any other AWS KMS custom key store.
* The cluster must be configured with private subnets in at least two Availability Zones in the Region.
* The security group for the cluster must include inbound and outbound rules that allow TCP traffic on ports 2223-2225.
* The cluster must contain at least two active HSMs in different Availability Zones.
For more details on setting up your cluster, refer to the following [AWS documentation](https://docs.aws.amazon.com/kms/latest/developerguide/create-keystore.html#before-keystore).
## Set Up AWS KMS Custom Key Store
To set up an AWS KMS custom key store with AWS CloudHSM, you will need the following:
* The trust anchor certificate of your AWS CloudHSM cluster.
* A `kmsuser` user in the AWS CloudHSM cluster with the crypto-user role.
Before you begin, you'll first need to choose a method of authentication with AWS from below.
2. Select **AWS Account** as the **Trusted Entity Type**.
3. Select **Another AWS Account** and provide the appropriate Infisical AWS Account ID: use **381492033652** for the **US region**, and **345594589636** for the **EU region**. This restricts the role to be assumed only by Infisical. If you are self-hosting, provide the AWS account number where Infisical is hosted.
Click the 'Add' button to begin adding a new external KMS.
Choose 'AWS KMS' from the list of encryption providers.
Choose the AWS KMS key you configured earlier.
2. Give the service account a suitable **name** and **description**. Then click **Create and Continue**.
3. Under **Grant this service account access to project**, click **Select a role** and select the
**Cloud KMS Viewer** and **Cloud KMS CryptoKey Encrypter/Decrypter**\* roles, then click **Continue**.
4. You can skip the **Grant users access to this service account** options.
5. Click Done.
6. You should see the service account in the list of service accounts. Click it to view the service account details.
7. Select the **Keys** tab, click **Add Key**, select **Create new key**, select **JSON** as the key type, then click **Create**.
8. You will be prompted to download a JSON file that we will need later on.
3. Give the key ring a **Name** and select a **Region**, then click **Create**.
Click the 'Add' button to begin adding a new external KMS.
Choose 'GCP KMS' from the list of encryption providers.
Selecting GCP as the provider will require you input the following fields.
Choose the GCP KMS key you configured earlier.
For existing projects, you can configure the KMS from the Project Settings page.
## External KMS
Infisical supports the use of external KMS solutions to enhance security and compliance. You can configure your project to use services like [AWS Key Management Service](./aws-kms) or [GCP Key Management Service](./gcp-kms) for managing encryption.
# HSM Integration
Source: https://infisical.com/docs/documentation/platform/kms/hsm-integration
Learn more about integrating an HSM with Infisical KMS.
Using a hardware security module comes with the added benefit of having a secure and tamper-proof device to store your encryption keys. This ensures that your data is protected from unauthorized access.
Once you press the 'Save' button, your Infisical instance will immediately switch to the HSM encryption strategy. This will re-encrypt your KMS key with keys from the HSM device.
2. Take note of the domain (e.g., apac.smartkey.io). You will need this to set up the configuration file for the Fortanix client.
2. Take note of the domain (e.g., apac.smartkey.io). You will need this when setting up the configuration file.
At a high level, the KMIP integration works as follows:
1. KMIP clients (your applications or tools) communicate with the KMIP server
2. The KMIP server acts as a proxy and forwards requests to Infisical KMS
3. The KMIP server authenticates to Infisical using a machine identity
The KMIP server itself is deployed using the Infisical CLI (`infisical kmip start` command) and serves as an intermediary between your KMIP clients and Infisical's key management system.
### Supported Operations
The Infisical KMIP server supports the following operations for symmetric keys:
* **Create** - Generate symmetric keys
* **Register** - Register externally created keys
* **Locate** - Find keys using attributes
* **Get** - Retrieve keys securely
* **Activate** - Enable keys for usage
* **Revoke** - Revoke existing keys
* **Destroy** - Permanently remove keys
* **Get Attributes** - Retrieve metadata associated with keys
* **Query** - Query server capabilities and supported operations
### Compatibility
Infisical KMIP supports KMIP versions 1.0 to 1.4, ensuring compatibility with a wide range of clients and security tools.
### Network Requirements
Ensure the following network connectivity is in place:
* **KMIP Client → KMIP Server**: KMIP clients must be able to reach the KMIP server on port 5696 (or your configured port). Ensure firewalls allow this traffic and DNS resolution works if using hostnames.
* **KMIP Server → Infisical Platform**: The KMIP server needs outbound HTTP access to Infisical. For self-hosted instances, ensure connectivity to your custom domain.
## Configure and Deploy the KMIP Server
Follow these steps in order to set up KMIP integration with Infisical:
In the modal, select the desired key algorithm to use for the KMIP PKI of your organization, then click **Continue**.
This generates the KMIP PKI for your organization, creating the cryptographic foundation that will be used for secure KMIP communications.
This machine identity will be used by the KMIP server to authenticate and forward client requests to Infisical KMS.
This permission allows the KMIP server to act as an intermediary between KMIP clients and Infisical.
This grants the machine identity the ability to serve KMIP client requests and forward them from your KMIP server to Infisical.
This creates a KMIP client entity in Infisical that will be authenticated via mTLS certificates.
Provide the desired TTL (time-to-live) and key algorithm, then click **Generate Client Certificate**.
Download the generated client certificate, certificate chain, and private key.
Configure your KMIP-compatible applications or tools to use these credentials when connecting to the KMIP server. The client will now authenticate via mTLS and perform authorized key management operations through the KMIP server, which proxies requests to Infisical KMS.
Specify your key details. Here's some guidance on each field:
* Name: A slug-friendly name for the key.
* Key Usage: The type of key to create (e.g `Encrypt/Decrypt` for encryption, and `Sign/Verify` for signing).
* Algorithm: The encryption algorithm associated with the key (e.g. `AES-GCM-256`).
* Description: An optional description of what the intended usage is for the key.
Populate the text area with your data and tap on the Encrypt button.
Your decrypted data will be displayed and can be copied for use.
Specify your key details. Here's some guidance on each field:
* Name: A slug-friendly name for the key.
* Key Usage: The type of key to create (e.g `Encrypt/Decrypt` for encryption, and `Sign/Verify` for signing).
* Algorithm: The signing algorithm associated with the key (e.g. `RSA_4096`).
* Description: An optional description of what the intended usage is for the key.
Populate the text area with your data and tap on the Sign button.
Make sure to select the appropriate signing algorithm that will be used to sign the data.
Supported signing algorithms are:
**For RSA keys:**
* `RSASSA PSS SHA 512`: Not deterministic, and includes random salt.
* `RSASSA PSS SHA 384`: Not deterministic, and includes random salt.
* `RSASSA PSS SHA 256`: Not deterministic, and includes random salt.
* `RSASSA PKCS1 V1.5 SHA 512`: Deterministic, and does not include randomness.
* `RSASSA PKCS1 V1.5 SHA 384`: Deterministic, and does not include randomness.
* `RSASSA PKCS1 V1.5 SHA 256`: Deterministic, and does not include randomness.
**For ECC keys:**
* `ECDSA SHA 512`: Not deterministic, and includes randomness.
* `ECDSA SHA 384`: Not deterministic, and includes randomness.
* `ECDSA SHA 256`: Not deterministic, and includes randomness.
In this example, we'll use the `RSASSA PSS SHA 512` signing algorithm.
Your verification result will be displayed and can be copied for use.
If the signature is invalid, you'll see an error message indicating that the signature is invalid, and the "Signature Status" field will be `Invalid`.
Next, input your LDAP server settings.
Here's some guidance for each field:
* URL: The LDAP server to connect to such as `ldap://ldap.your-org.com`, `ldaps://ldap.myorg.com:636` (for connection over SSL/TLS), etc.
* Bind DN: The distinguished name of object to bind when performing the user search such as `cn=infisical,ou=Users,dc=acme,dc=com`.
* Bind Pass: The password to use along with `Bind DN` when performing the user search.
* User Search Base / User DN: Base DN under which to perform user search such as `ou=Users,dc=acme,dc=com`.
* Unique User Attribute: The attribute to use as the unique identifier of LDAP users such as `sAMAccountName`, `cn`, `uid`, `objectGUID` ... If left blank, defaults to `uidNumber`
* User Search Filter (optional): Template used to construct the LDAP user search filter such as `(uid={{username}})`; use literal `{{username}}` to have the given username used in the search. The default is `(uid={{username}})` which is compatible with several common directory schemas.
* Group Search Base / Group DN (optional): LDAP search base to use for group membership search such as `ou=Groups,dc=acme,dc=com`.
* Group Filter (optional): Template used when constructing the group membership query such as `(&(objectClass=posixGroup)(memberUid={{.Username}}))`. The template can access the following context variables: \[`UserDN`, `UserName`]. The default is `(|(memberUid={{.Username}})(member={{.UserDN}})(uniqueMember={{.UserDN}}))` which is compatible with several common directory schemas.
* CA Certificate: The CA certificate to use when verifying the LDAP server certificate.
Group mappings ensure that users who log into Infisical via LDAP are added to or removed from the Infisical group(s) that corresponds to the LDAP group(s) they are a member of.
Each group mapping consists of two parts:
* LDAP Group CN: The common name of the LDAP group to map.
* Infisical Group: The Infisical group to map the LDAP group to.
For example, suppose you want to automatically add a user who is part of the LDAP group with CN `Engineers` to the Infisical group `Engineers` when the user sets up their account with Infisical.
In this case, you would specify a mapping from the LDAP group with CN `Engineers` to the Infisical group `Engineers`.
Now when the user logs into Infisical via LDAP, Infisical will check the LDAP groups that the user is a part of whilst referencing the group mappings you created earlier. Since the user is a member of the LDAP group with CN `Engineers`, they will be added to the Infisical group `Engineers`.
In the future, if the user is no longer part of the LDAP group with CN `Engineers`, they will be removed from the Infisical group `Engineers` upon their next login.
Next, input your JumpCloud LDAP server settings.
Here's some guidance for each field:
* URL: The LDAP server to connect to (`ldaps://ldap.jumpcloud.com:636`).
* Bind DN: The distinguished name of object to bind when performing the user search (`uid=
Group mappings ensure that users who log into Infisical via LDAP are added to or removed from the Infisical group(s) that corresponds to the LDAP group(s) they are a member of.
Each group mapping consists of two parts:
* LDAP Group CN: The common name of the LDAP group to map.
* Infisical Group: The Infisical group to map the LDAP group to.
For example, suppose you want to automatically add a user who is part of the LDAP group with CN `Engineers` to the Infisical group `Engineers` when the user sets up their account with Infisical.
In this case, you would specify a mapping from the LDAP group with CN `Engineers` to the Infisical group `Engineers`.
Now when the user logs into Infisical via LDAP, Infisical will check the LDAP groups that the user is a part of whilst referencing the group mappings you created earlier. Since the user is a member of the LDAP group with CN `Engineers`, they will be added to the Infisical group `Engineers`.
In the future, if the user is no longer part of the LDAP group with CN `Engineers`, they will be removed from the Infisical group `Engineers` upon their next login.
## Mobile Authenticator 2FA
You can use any mobile authenticator app (Authy, Google Authenticator, Duo, etc.) to secure your account. After registration with an authenticator, select **Mobile Authenticator** as your 2FA method.
## Entra ID / Azure AD MFA
## Projects
The *Projects* tab shows a list of projects that you have access to.
If you're an organization admin, you also have the option to view *All Projects*—a complete view of every project within the organization, including those you are not currently a member of— and gain access to any project.
Admins can gain access to any project in the organization by opening the options menu (⋮) next to a project and selecting Access. This will add you to the project as an admin and allow full visibility and control.
## Roles and Access Control
The *Access Control* tab lets you view and manage roles and permissions for users, machine identities, and groups across your organization.
Users are invited to an organization and assigned organization-level roles such as `Admin` or `Member`. You can also define [custom roles](/documentation/platform/access-controls/role-based-access-controls#creating-custom-roles) at the organization level to fit your permission model.
Infisical supports [user identities](/documentation/platform/identities/user-identities) (representing people) and [machine identities](/documentation/platform/identities/machine-identities) (representing services, CI/CD pipelines, or agents). The same roles and permissions can be applied to either type of identity.
To manage access at scale, Infisical also supports [user groups](/documentation/platform/groups) — roles assigned to a group apply to all of its members automatically.
Note that Infisical distinguishes between organization-level and project-level access control:
* [Organization-level access control](/documentation/platform/access-controls/role-based-access-controls#organization-level-access-controls): Roles and permissions governing access to organization-level resources and controls such as billing, member management, and identity provider configuration.
* [Project-level access control](/documentation/platform/access-controls/role-based-access-controls#project-level-access-controls): Roles and permissions governing access to resources and workflows within a specific project (e.g., secrets, certificates, SSH hosts).
To learn more about how permissions work in detail, refer to the [access control documentation](/documentation/platform/access-controls/overview).
## Audit Logs
Infisical provides a unified view of [audit logs](/documentation/platform/audit-logs) at the organization level. All platform activity—including secret access, certificate issuance, platform logins across the organization —is recorded and searchable in a central log view.
Audit logs are also viewable at the project level, where they are scoped to show only events relevant to that specific project. This allows project administrators to monitor activity and investigate changes without requiring organization-wide access.
## App Connections
Infisical supports [app connections](/integrations/app-connections/overview) — integrations configured at the organization level with third-party platforms such as AWS, GCP, GitHub, and many others.
Once configured, these connections can be reused across multiple projects as part of any feature that requires third-party integrations—such as [secret syncing](/integrations/secret-syncs/overview) or [dynamic credential generation](/documentation/platform/dynamic-secrets/overview).
To learn more, refer to the [app connections documentation](/integrations/app-connections/overview).
## Organization Settings
The *Organization Settings* tab lets you configure global behavior and security controls for the organization.
Key configuration areas include:
* General: Manage the organization’s name, slug, and default role for newly invited members.
* Single Sign-On (SSO): Enable [SAML](/documentation/platform/sso/overview), [LDAP](/documentation/platform/ldap/overview), or [OIDC-based](/documentation/platform/sso/general-oidc/overview) authentication for user login.
* Provisioning: Enable [SCIM](/documentation/platform/scim/overview) to automatically provision and deprovision users and groups from an identity provider.
* Security Policies: Enforce MFA and configure session duration limits.
* Encryption: Integrate with external KMS systems or bring your own encryption keys (BYOK).
* [Audit Log Streaming](/documentation/platform/audit-log-streams/audit-log-streams): Forward audit events to third-party logging tools like SIEMs or cloud storage.
* Workflow Integrations: Trigger [Slack](/documentation/platform/workflow-integrations/slack-integration) or [Microsoft Teams](/documentation/platform/workflow-integrations/microsoft-teams-integration) notifications for events like access requests.
* [Project Templates](/documentation/platform/project-templates): Define default environments, roles, and settings to standardize project creation.
* KMIP (Enterprise): Connect to KMIP-compatible HSMs for hardware-backed key storage and operations.
# Architecture
Source: https://infisical.com/docs/documentation/platform/pam/architecture
Learn about the architecture, components, and security model of Infisical PAM.
Infisical PAM utilizes a secure, proxy-based architecture designed to provide access to private resources without exposing them directly to the internet. This system relies on a combination of the Infisical CLI, a Relay server, and a self-hosted Gateway. For more information on Gateways, refer to the [Gateway Overview](/documentation/platform/gateways/overview).
## Core Components
The architecture consists of three main components working in unison:
A key feature of the Gateway is its ability to act as a "middleman" for all session traffic.
* **Interception**: Because the Gateway sits between the secure tunnel and the target resource, it intercepts all data flowing through the connection.
* **Logging**: This traffic is logged as part of [Session Recording](/documentation/platform/pam/product-reference/session-recording). The Gateway temporarily stores encrypted session logs locally.
* **Upload**: Once the session concludes, the logs are securely uploaded to the Infisical platform for storage and review.
## Security Architecture
The PAM security model allows you to maintain a zero-trust environment while enabling convenient access.
### End-to-End Encryption
The connection between the Infisical CLI (client) and the Gateway is end-to-end encrypted. The Relay server acts solely as a router for encrypted packets and **cannot decrypt or inspect** the traffic passing through it.
### Network Security
The Gateway uses **SSH reverse tunnels** to connect to the Relay. This design offers significant security benefits:
* **No Inbound Ports**: You do not need to open any inbound firewall ports (like 22 or 5432) to the internet.
* **Outbound-Only**: The Gateway only requires outbound connectivity to the Relay server and Infisical API.
For a deep dive into the underlying cryptography, certificate management, and isolation guarantees, refer to the [Gateway Security Architecture](/documentation/platform/gateways/security).
### Deployment
For instructions on setting up the necessary infrastructure, see the [Gateway Deployment Guide](/documentation/platform/gateways/gateway-deployment).
# PAM Account
Source: https://infisical.com/docs/documentation/platform/pam/getting-started/accounts
Learn how to create and manage accounts in PAM to control access to resources like databases and servers.
An **Account** contains the credentials (such as a username and password) used to connect to a [Resource](/documentation/platform/pam/getting-started/resources).
## Relationship to Resources
Accounts belong to Resources. A single Resource can have multiple Accounts associated with it, each with different permission levels.
For example, your database would normally have multiple accounts. You might have a superuser account for admins, a standard read/write account for applications, and a read-only account for reporting.
In PAM, these are represented as:
* **Resource**: `Production Database` (PostgreSQL)
* **Account 1**: `postgres` (Superuser)
* **Account 2**: `app_user` (Read/Write)
* **Account 3**: `analytics` (Read-only)
When a user requests access in PAM, they request access to a specific **Account** on a **Resource**.
## Creating an Account
Next, select the **Resource** that this account belongs to.
After selecting a resource, provide the credentials (username, password, etc.) for this account. The required fields vary depending on the resource type. For example, for a Linux server, you would enter the username and the corresponding password or SSH key.
Clicking **Create Account** will trigger a validation check. Infisical will attempt to connect to the resource using the provided credentials to verify they are valid.
## Automated Credential Rotation
Infisical supports automated credential rotation for some accounts on select resources, allowing you to automatically change passwords at set intervals to enhance security.
To learn more about how to configure this, please refer to the [Credential Rotation guide](/documentation/platform/pam/product-reference/credential-rotation).
# PAM Resource
Source: https://infisical.com/docs/documentation/platform/pam/getting-started/resources
Learn how to add and configure resources like databases and servers, and set up automated credential rotation.
A resource represents a target system, such as a database, server, or application, that you want to manage access to. Some examples of resources are:
* PostgreSQL Database
* MCP Server
* Linux Server
* Web Application
## Prerequisites
Before you can create a resource, you must have an **Infisical Gateway** deployed that is able to reach the target resource over the network.
The Gateway acts as a secure bridge, allowing Infisical to reach your private infrastructure without exposing it to the public internet. When creating a resource, you will be asked to specify which Gateway should be used to connect to it.
[Read the Gateway Deployment Guide](/documentation/platform/gateways/gateway-deployment)
## Creating a Resource
To add a resource, navigate to the **Resources** tab in your PAM project and click **Add Resource**.
Next, select the type of resource you want to add.
After selecting a resource type, provide the necessary connection details. The required fields vary depending on the resource type.
**Important**: You must select the **Gateway** that has network access to this resource.
In this PostgreSQL example, you provide details such as host, port, gateway, and database name.
Clicking **Create Resource** will trigger a connection test from the selected Gateway to your target resource. If the connection fails, an error message will be displayed to help you troubleshoot (usually indicating a network firewall issue between the Gateway and the Resource).
## Automated Credential Rotation
Some resources, such as PostgreSQL, support automated credential rotation to enhance your security posture. This feature requires configuring a privileged "Rotation Account" on the resource.
To learn more about how to configure this, please refer to the [Credential Rotation guide](/documentation/platform/pam/product-reference/credential-rotation).
# Setup
Source: https://infisical.com/docs/documentation/platform/pam/getting-started/setup
This guide provides a step-by-step walkthrough for configuring Infisical's Privileged Access Management (PAM). Learn how to deploy a gateway, define resources, and grant your team secure, audited access to critical infrastructure.
Infisical's Privileged Access Management (PAM) solution enables you to provide developers with secure, just-in-time access to your critical infrastructure, such as databases, servers, and web applications. Instead of sharing static credentials, your team can request temporary access through Infisical, which is then brokered through a secure gateway with full auditing and session recording.
Getting started involves a few key components:
* **Gateways:** A lightweight service you deploy in your own infrastructure to act as a secure entry point to your private resources.
* **Resources:** The specific systems you want to manage access to (e.g., a PostgreSQL database or an SSH server).
* **Accounts:** The privileged credentials (e.g., a database user or an SSH user) that Infisical uses to connect to a resource on behalf of a user.
The following steps will guide you through the entire setup process, from deploying your first gateway to establishing a secure connection.
# Credential Rotation
Source: https://infisical.com/docs/documentation/platform/pam/product-reference/credential-rotation
Learn how to automate credential rotation for your PAM resources.
Automated Credential Rotation enhances your security posture by automatically changing the passwords of your accounts at set intervals. This minimizes the risk of compromised credentials by ensuring that even if a password is leaked, it remains valid only for a short period.
## How it Works
When rotation is enabled, Infisical's Gateway connects to the target resource using a privileged "Rotation Account". It then executes the necessary commands to change the password for the target user account to a new, cryptographically secure random value.
## Configuration
Setting up automated rotation requires a two-step configuration: first at the Resource level, and then at the individual Account level.
The session details page provides key information, including the complete session logs, connection status, the user who initiated it, and more.
### Searching Logs
You can use the search bar to quickly find relevant information:
**Sessions page:** Search across all session logs to locate specific queries or outputs.
**Individual session page:** Search within that specific session's logs to pinpoint activity.
## FAQ
### Commits List View
The commits page displays a comprehensive chronological history of all changes made to your environment and folders:
* **Chronological Sorting**: Commits are grouped by date
* **Commit Information**: Each commit shows:
* Commit message
* Author information
* Relative timestamp
* Unique commit hash identifier
* **Search Functionality**: Use the search bar to quickly find specific commits
* **Sorting Options**: Sort commits by various criteria using the sort controls
### Detailed Commit Inspection
Clicking on any commit from the list opens a detailed view showing the list of changes made in that commit.
#### Change Categories
The commit changes details can be grouped into the following categories:
**Folder Changes**
* Shows folder additions, modifications, or deletions
* Displays the folder properties changes in JSON format, including:
* Folder name
* Folder description
**Secret Changes**
* Lists all secrets that were added, updated, or removed
* Shows the complete secret configuration including:
* Secret key and value
* Comments, tags and metadata
* Encoding settings (e.g., skipMultilineEncoding)
* Values are displayed with appropriate masking for security
**Visual Indicators**
* Green "+" indicators show additions
* Red "-" indicators show deletions
* Modified content shows both old and new states
### Restoration Options
Each commit provides two distinct restoration methods accessible via the **Restore Options** dropdown:
#### Revert changes
This option provides surgical precision for undoing specific modifications:
* **Granular Control**: Reverts only the specific changes introduced in that individual commit
* **Selective Restoration**: Preserves all other changes made after the commit
* **Targeted Undo**: Perfect for reversing a specific problematic change without affecting other work
* **Minimal Impact**: Only affects the resources that were modified in that particular commit
* **Use Case**: Ideal when you want to undo a specific change while keeping all other modifications intact
#### Roll back to this commit
This option performs a complete restoration to the selected point in time:
* **Complete State Restoration**: Returns the entire folder to its exact state at the time of this commit
* **Restore All Child Folders**: If enabled, it'll also restore all nested folders to their exact state at the time of this commit.
* **Destructive Operation**: Discards ALL changes made after the selected commit
* **New Commit Creation**: Creates a new commit representing this rollback operation
* **Use Case**: Ideal when you want to completely undo a series of changes and return to a known good state
**Warning**: This operation will undo all modifications made after the selected commit, which may include multiple secrets and configuration changes.
This opens up a sidebar from which you can select to view a particular snapshot:
## Rolling back
After pressing on a snapshot from the sidebar, you can view it and roll back the state
of the folder to that point in time by pressing the **Rollback** button.
Rolling back secrets to a past snapshot creates a snapshot at the top of the stack and updates secret versions.
Here's some guidance for each field in the alert configuration sequence:
* Alert Type: The type of alert to create such as **Certificate Expiration**.
* Alert Name: A slug-friendly name for the alert such as `tls-expiry-alert`.
* Description: An optional description for the alert.
* Alert Before: The time before certificate expiration to trigger the alert such as 30 days denoted by `30d`.
* Filters: A list of filters that determine which certificates the alert applies to. Each row includes a **Field**, **Operator**, and **Value** to match against. For example, you can filter for certificates with a common name containing `example.com` by setting the field to **Common Name**, the operator to **Contains**, and the value to `example.com`.
* Channels / Email Recipients: A list of email addresses to notify when the alert triggers.
# ACME-compatible CA
Source: https://infisical.com/docs/documentation/platform/pki/ca/acme-ca
Learn how to connect Infisical to an ACME-compatible CA to issue certificates.
## Concept
Infisical can connect to any upstream ACME-compatible CA (e.g. Lets's Encrypt, DigiCert, etc.) supporting the [ACME protocol](https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment) to issue certificates back to your end-entities. This integration uses the [DNS-01 challenge](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge) method as part of the ACME domain validation challenge workflow for a requested certificate.
The upstream ACME-compatible CA integration lets you connect Infisical to providers by specifying
their **ACME Directory URL** such as:
* [Let's Encrypt](/documentation/platform/pki/ca/lets-encrypt): `https://acme-v02.api.letsencrypt.org/directory`.
* [DigiCert](/documentation/platform/pki/ca/digicert): `https://acme.digicert.com/v2/acme/directory`.
* Google GTS: `https://dv.acme-v02.api.pki.goog/directory`.
* Buypass: `https://api.buypass.com/acme/directory`.
* ZeroSSL: `https://acme.zerossl.com/v2/DV90`.
* SSL.com: `https://acme.ssl.com/sslcom-dv-rsa`.
When Infisical requests a certificate from an ACME-compatible CA, it creates a TXT record at `_acme-challenge.{your-domain}` in your configured DNS provider (e.g. Route53, Cloudflare, DNS Made Easy, etc.); this TXT record contains the challenge token issued by the ACME-compatible CA to validate domain control for the requested certificate.
The ACME provider checks for the existence of this TXT record to verify domain control before issuing the certificate back to Infisical.
After validation completes successfully, Infisical automatically removes the TXT record from your DNS provider.
```mermaid theme={"dark"}
graph TD
A[ACME-compatible CA] <-->|ACME v2 Protocol| B[Infisical]
B -->|Creates TXT Records
via DNS Provider| C[DNS Validation] B -->|Manages Certificates| D[End-Entities] ```
We recommend reading about [ACME protocol](https://tools.ietf.org/html/rfc8555) and [DNS-01 challenges](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge) for a fuller understanding of the underlying workflow.
## Workflow
A typical workflow for using Infisical with an external ACME-compatible CA consists of the following steps:
1. Setting up your DNS provider (e.g. Route53, Cloudflare, etc.) with appropriate DNS permissions.
2. Creating an [App Connection](/integrations/app-connections/overview) in Infisical to store credentials for Infisical to connect to your DNS provider and create/remove DNS records as part of the DNS-01 challenge.
3. Registering an [External CA](/documentation/platform/pki/ca/external-ca) in Infisical with the ACME type and inputting required configuration including the **ACME Directory URL** of the upstream ACME-compatible CA and the **App Connection** for your DNS provider.
Once this is complete, you can create a [certificate profile](/documentation/platform/pki/certificates/profiles) linked to the External CA proceed to request a certificate against it.
## Guide to Connecting Infisical to an ACME-compatible CA
In the following steps, we explore how to connect Infisical to an ACME-compatible CA.
via DNS Provider| C[DNS Validation] B -->|Manages Certificates| D[End-Entities] ```
Here, set the **CA Type** to **ACME** and fill out details for it.
Here's some guidance for each field:
* Name: A slug-friendly name for the ACME-compatible CA such as `lets-encrypt-production`.
* DNS App Connection: The App Connection from Step 1 used for Infisical to connect to your DNS provider and create/remove DNS records as part of the DNS-01 challenge in ACME.
* Zone / Zone ID: Enter the Zone / Zone ID for the domain(s) you'll be requesting certificates for.
* Directory URL: Enter the **ACME Directory URL** for your desired upstream ACME-compatible CA such as `https://acme-v02.api.letsencrypt.org/directory` for Let's Encrypt.
* Account Email: The email address to associate with your ACME account. This email will receive important notifications about your certificates.
* EAB Key Identifier (KID): (Optional) The Key Identifier (KID) provided by your ACME CA for External Account Binding (EAB). This is required by some ACME providers (e.g., ZeroSSL, DigiCert) to link your ACME account to an external account you've pre-registered with them.
* EAB HMAC Key: (Optional) The HMAC Key provided by your ACME CA for External Account Binding (EAB). This key is used in conjunction with the KID to prove ownership of the external account during ACME account registration.
Finally, press **Create** to register the ACME-compatible CA with Infisical.
Great! You’ve successfully registered an external ACME-compatible CA with Infisical. Now check out the [Certificates](/documentation/platform/pki/certificates/overview) section to learn more about how to issue X.509 certificates using the ACME-compatible CA.
```mermaid theme={"dark"}
graph TD
A1[External Public CA
e.g. Let's Encrypt, ZeroSSL, ...] --> Infisical A2[External Private CA
e.g. AWS Private CA, HashiCorp Vault PKI, ...] --> Infisical ```
As shown above, these CAs commonly fall under two categories:
* External Private CAs: CAs like AWS Private CA, HashiCorp Vault PKI, Azure ADCS, etc. that are privately owned and are used to issue certificates for internal services; these are often either cloud-hosted private CAs or on-prem / enterprise CAs.
* External Public CAs: CAs like Let's Encrypt, DigiCert, GlobalSign, etc. that are publicly trusted and are used to issue certificates for public-facing services.
Note that Infisical can act as an *ACME client*, allowing you to integrate upstream with any [ACME-compatible CA](/documentation/platform/pki/ca/acme-ca) to automate certificate issuance and renewal.
## Workflow
A typical workflow for integrating an External CA with Infisical consists of choosing the desired External CA type
and specifying the configuration or connection details necessary to connect to the CA.
The specific steps and requirements vary depending on the External CA type you choose to integrate.
## Supported External CA Types
Infisical currently supports the following External CA types out of the box:
* [ACME CA](/documentation/platform/pki/ca/acme-ca): An ACME-compatible CA that supports the ACME protocol, such as Let's Encrypt, ZeroSSL, Buypass, Digicert, etc.
* [Azure ADCS](/documentation/platform/pki/ca/azure-adcs): A Microsoft Active Directory Certificate Services (ADCS) that supports the ADCS protocol, such as AWS Private CA, Azure ADCS, etc.
If you don’t see a specific external CA listed here or need a dedicated integration guide, please reach out to [sales@infisical.com](mailto:sales@infisical.com) and we’ll help you set up the integration for your external CA.
## FAQ
e.g. Let's Encrypt, ZeroSSL, ...] --> Infisical A2[External Private CA
e.g. AWS Private CA, HashiCorp Vault PKI, ...] --> Infisical ```
```mermaid theme={"dark"}
graph TD
A[Root CA]
A --> B[Intermediate CA]
A --> C[Intermediate CA]
```
## Workflow
A typical workflow for setting up a Private CA hierarchy consists of the following steps:
1. Configuring an Infisical root CA with details like name, validity period, and path length — This step is optional if you wish to use an external root CA with Infisical only serving the intermediate CAs.
2. Configuring and chaining intermediate CA(s) with details like name, validity period, path length, and imported certificate to your Root CA.
3. Managing the CA lifecycle events such as CA succession.
Here, set the **CA Type** to **Root** and fill out details for the root CA.
Here's some guidance for each field:
* Valid Until: The date until which the CA is valid in the date time string format specified [here](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date#date_time_string_format). For example, the following formats would be valid: `YYYY`, `YYYY-MM`, `YYYY-MM-DD`, `YYYY-MM-DDTHH:mm:ss.sssZ`.
* Path Length: The maximum number of intermediate CAs that can be chained to this CA. A path of `-1` implies no limit; a path of `0` implies no intermediate CAs can be chained.
* Key Algorithm: The type of public key algorithm and size, in bits, of the key pair that the CA creates when it issues a certificate. Supported key algorithms are `RSA 2048`, `RSA 4096`, `ECDSA P-256`, and `ECDSA P-384` with the default being `RSA 2048`.
* Name: A slug-friendly name for the CA.
* Organization (O): The organization name.
* Country (C): The country code.
* State or Province Name: The state or province.
* Locality Name: The city or locality.
* Common Name: The name of the CA.
2.2. Next, press the **Install Certificate** option on the intermediate CA from step 1.1.
2.3a. If you created a root CA in step 1, select **Infisical CA** for the **Parent CA Type** field.
Next, set the **Parent CA** to the root CA created in step 1 and configure the intended **Valid Until** and **Path Length** fields on the intermediate CA; feel free to use the prefilled values.
Here's some guidance on each field:
* Parent CA: The parent CA to which this intermediate CA will be chained. In this case, it should be the root CA created in step 1.
* Valid Until: The date until which the CA is valid in the date time string format specified [here](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date#date_time_string_format). The date must be within the validity period of the parent CA.
* Path Length: The maximum number of intermediate CAs that can be chained to this CA. The path length must be less than the path length of the parent CA.
Finally, press **Install** to chain the intermediate CA to the root CA; this creates a Certificate Signing Request (CSR) for the intermediate CA, creates an intermediate certificate using the root CA private key and CSR, and imports the signed certificate back to the intermediate CA.
Great! You've successfully created a Private CA hierarchy with a root CA and an intermediate CA. Now check out the [Certificates section](/documentation/platform/pki/certificates/overview) to learn more about how to issue X.509 certificates using the intermediate CA.
2.3b. If you have an external root CA, select **External CA** for the **Parent CA Type** field.
Next, use the provided intermediate CSR to generate a certificate from your external root CA and paste the PEM-encoded certificate back into the **Certificate Body** field; the PEM-encoded external root CA certificate should be pasted under the **Certificate Chain** field.
Finally, press **Install** to import the certificate and certificate chain as part of the installation step for the intermediate CA
Great! You've successfully created a Private CA hierarchy with an intermediate CA chained to an external root CA.
Now check out the [Certificates section](/documentation/platform/pki/certificates/overview) to learn more about how to issue X.509 certificates using the intermediate CA.
Input a new **Valid Until**
date to be used for the renewed CA certificate and press **Renew** to renew
the CA. 
2. Select the **AWS Certificate Manager** option.
3. Configure the **Destination** to where certificates should be deployed, then click **Next**.
* **AWS Connection**: The AWS Connection to authenticate with.
* **AWS Region**: The AWS region where certificates should be stored.
4. Configure the **Sync Options** to specify how certificates should be synced, then click **Next**.
* **Enable Removal of Expired/Revoked Certificates**: If enabled, Infisical will remove certificates from the destination if they are no longer active in Infisical.
* **Preserve ARN on Renewal**: If enabled, Infisical will sync renewed certificates to the destination under the same ARN as the original synced certificate instead of creating a new certificate with a new ARN.
* **Include Root CA**: If enabled, the Root CA certificate will be included in the certificate chain when syncing to AWS Certificate Manager. If disabled, only intermediate certificates will be included.
* **Certificate Name Schema** (Optional): Customize how certificate tags are generated in AWS Certificate Manager. Must include `{{certificateId}}` as a placeholder for the certificate ID to ensure proper certificate identification and management. If not specified, defaults to `Infisical-{{certificateId}}`.
* **Auto-Sync Enabled**: If enabled, certificates will automatically be synced when changes occur. Disable to enforce manual syncing only.
5. Configure the **Details** of your AWS Certificate Manager Certificate Sync, then click **Next**.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
6. Select which certificates should be synced to AWS Certificate Manager.
7. Review your AWS Certificate Manager Certificate Sync configuration, then click **Create Sync**.
8. If enabled, your AWS Certificate Manager Certificate Sync will begin syncing your certificates to the destination endpoint.
2. Select the **AWS Secrets Manager** option.
3. Configure the **Destination** to where certificates should be deployed, then click **Next**.
* **AWS Connection**: The AWS Connection to authenticate with.
* **Region**: The AWS region where secrets will be stored.
4. Configure the **Sync Options** to specify how certificates should be synced, then click **Next**.
* **Enable Removal of Expired/Revoked Certificates**: If enabled, Infisical will remove certificates from the destination if they are no longer active in Infisical.
* **Preserve Secret on Renewal**: Only applies to certificate renewals. When a certificate is renewed in Infisical, this option controls how the renewed certificate is handled. If enabled, the renewed certificate will update the existing secret, preserving the same secret name. If disabled, the renewed certificate will be created as a new secret with a new name.
* **Include Root CA**: If enabled, the Root CA certificate will be included in the certificate chain when syncing to AWS Secrets Manager. If disabled, only intermediate certificates will be included.
* **Certificate Name Schema** (Optional): Customize how secret names are generated in AWS Secrets Manager. Use `{{certificateId}}` as a placeholder for the certificate ID.
* **Auto-Sync Enabled**: If enabled, certificates will automatically be synced when changes occur. Disable to enforce manual syncing only.
5. Configure the **Field Mappings** to customize how certificate data is stored in AWS Secrets Manager secrets, then click **Next**.
* **Certificate Field**: The field name where the certificate will be stored in the secret value (default: `certificate`)
* **Private Key Field**: The field name where the private key will be stored in the secret value (default: `private_key`)
* **Certificate Chain Field**: The field name where the full certificate chain excluding the root CA certificate will be stored (default: `certificate_chain`)
* **CA Certificate Field**: The field name where the root CA certificate will be stored (default: `ca_certificate`)
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
7. Select which certificates should be synced to AWS Secrets Manager.
8. Review your AWS Secrets Manager Certificate Sync configuration, then click **Create Sync**.
9. If enabled, your AWS Secrets Manager Certificate Sync will begin syncing your certificates to the destination endpoint.
2. Select the **Azure Key Vault** option.
3. Configure the **Destination** to where certificates should be deployed, then click **Next**.
* **Azure Connection**: The Azure Connection to authenticate with.
* **Vault Base URL**: The URL of your Azure Key Vault.
4. Configure the **Sync Options** to specify how certificates should be synced, then click **Next**.
* **Enable Removal of Expired/Revoked Certificates**: If enabled, Infisical will remove certificates from the destination if they are no longer active in Infisical.
* **Enable Versioning on Renewal**: If enabled, Infisical will sync renewed certificates to the destination under a new version of the original synced certificate instead of creating a new certificate.
* **Include Root CA**: If enabled, the Root CA certificate will be included in the certificate chain when syncing to Azure Key Vault. If disabled, only intermediate certificates will be included.
* **Certificate Name Schema** (Optional): Customize how certificate names are generated in Azure Key Vault. Use `{{certificateId}}` as a placeholder for the certificate ID. If not specified, defaults to `Infisical-{{certificateId}}`.
* **Auto-Sync Enabled**: If enabled, certificates will automatically be synced when changes occur. Disable to enforce manual syncing only.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
6. Select which certificates should be synced to Azure Key Vault.
7. Review your Azure Key Vault Certificate Sync configuration, then click **Create Sync**.
8. If enabled, your Azure Key Vault Certificate Sync will begin syncing your certificates to the destination endpoint.
2. Select the **Chef** option.
3. Configure the **Destination** to where certificates should be deployed, then click **Next**.
* **Chef Connection**: The Chef Connection to authenticate with.
* **Data Bag Name**: The name of the Chef data bag where certificates will be stored.
4. Configure the **Sync Options** to specify how certificates should be synced, then click **Next**.
* **Enable Removal of Expired/Revoked Certificates**: If enabled, Infisical will remove certificates from the destination if they are no longer active in Infisical.
* **Preserve Data Bag Item on Renewal**: Only applies to certificate renewals. When a certificate is renewed in Infisical, this option controls how the renewed certificate is handled. If enabled, the renewed certificate will update the existing data bag item, preserving the same item name. If disabled, the renewed certificate will be created as a new data bag item with a new name.
* **Include Root CA**: If enabled, the Root CA certificate will be included in the certificate chain when syncing to Chef data bags. If disabled, only intermediate certificates will be included.
* **Certificate Name Schema** (Optional): Customize how certificate item names are generated in Chef data bags. Use `{{certificateId}}` as a placeholder for the certificate ID.
* **Auto-Sync Enabled**: If enabled, certificates will automatically be synced when changes occur. Disable to enforce manual syncing only.
5. Configure the **Field Mappings** to customize how certificate data is stored in Chef data bag items, then click **Next**.
* **Certificate Field**: The field name where the certificate will be stored in the data bag item (default: `certificate`)
* **Private Key Field**: The field name where the private key will be stored in the data bag item (default: `private_key`)
* **Certificate Chain Field**: The field name where the full certificate chain excluding the root CA certificate will be stored (default: `certificate_chain`)
* **CA Certificate Field**: The field name where the root CA certificate will be stored (default: `ca_certificate`)
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
7. Select which certificates should be synced to Chef.
8. Review your Chef Certificate Sync configuration, then click **Create Sync**.
9. If enabled, your Chef Certificate Sync will begin syncing your certificates to the destination endpoint.
```mermaid theme={"dark"}
%%{init: {'flowchart': {'curve': 'linear'} } }%%
graph LR
A[App Connection]
B[Certificate Sync]
C[Certificate 1]
D[Certificate 2]
E[Certificate 3]
F[Third-Party Service]
G[Certificate 1]
H[Certificate 2]
I[Certificate 3]
B --> A
C --> B
D --> B
E --> B
A --> F
F --> G
F --> H
F --> I
classDef default fill:#ffffff,stroke:#666,stroke-width:2px,rx:10px,color:black
classDef connection fill:#FFF2B2,stroke:#E6C34A,stroke-width:2px,color:black,rx:15px
classDef certificate fill:#E6F4FF,stroke:#0096D6,stroke-width:2px,color:black,rx:15px
classDef sync fill:#F4FFE6,stroke:#96D600,stroke-width:2px,color:black,rx:15px
classDef service fill:#E6E6FF,stroke:#6B4E96,stroke-width:2px,color:black,rx:15px
classDef subscriber fill:#FFE6E6,stroke:#D63F3F,stroke-width:2px,color:black,rx:15px
class A connection
class B sync
class C,D,E,G,H,I certificate
class F service
class J subscriber
```
## Workflow
Configuring a Certificate Sync requires three components: The certificates that you'd like to push,
a destination endpoint to deploy certificates to, and configuration options to determine how your certificates
should be synced. Follow these steps to start syncing:
The PEM export modal will display the certificate details including:
* **Serial Number**: The unique identifier for the certificate
* **Certificate Body**: The X.509 certificate in PEM format
* **Certificate Chain**: The intermediate and root CA certificates
* **Private Key**: The private key associated with the certificate (if available)
You can copy each component individually or use the **Copy All** button to copy the complete certificate bundle.
* **Password**: A secure password to protect the PKCS12 keystore
* **Alias**: A friendly name for the certificate within the keystore
Click **Export** to generate and download the `.p12` file containing the certificate, certificate chain, and private key.
To verify a certificate against the
downloaded CRL with OpenSSL, you can use the following command:
```bash theme={"dark"}
openssl verify -crl_check -CAfile chain.pem -CRLfile crl.pem cert.pem
```
Note that you can also obtain the CRL from the certificate itself by
referencing the CRL distribution point extension on the certificate.
To check a certificate against the CRL distribution point specified within it with OpenSSL, you can use the following command:
```bash theme={"dark"}
openssl verify -verbose -crl_check -crl_download -CAfile chain.pem cert.pem
```
Here's some guidance on each field:
* Name: A slug-friendly name for the profile such as `web-servers`.
* Description: An optional description for the profile.
* Issuer Type: The type of issuer that should be used to issue certificates for the profile; this can be either `Certificate Authority` or `Self-Signed`. If `Self-Signed` is selected, then the profile will only support the API enrollment method and be used to issue self-signed certificates over REST API.
* Issuing CA: The [issuing CA](/documentation/platform/pki/ca/overview) that should be used to issue certificates for the profile when the **Issuer Type** is set to `Certificate Authority`.
* Certificate Template: The [certificate template](/documentation/platform/pki/certificates/templates) that should be used to validate certificate requests for the profile.
* Enrollment Method: The enrollment method that should be used to enroll certificates for the profile such as ACME, EST, API, etc.
Depending on which enrollment method you choose, you may be presented with additional enrollment-specific configuration fields.
# Certificate Templates
Source: https://infisical.com/docs/documentation/platform/pki/certificates/templates
## Concept
A certificate template is a policy structure specifying permitted attributes for requested certificates. This includes constraints around subject naming conventions, SAN fields, key usages, and extended key usages.
Each certificate requested against a [certificate profile](/documentation/platform/pki/certificates/profiles) is validated against the template bound to that profile. If the request fails any criteria included in the template, the certificate is not issued. This helps administrators enforce uniformity and security standards across all issued certificates.
## Guide to Creating a Certificate Template
To create a certificate template, head to your Certificate Management Project > Certificates > Certificate Templates and press **Create Template**.
Here's some guidance on each field:
* Template Name: A slug-friendly name for the template such as `tls-server`.
* Description: An optional description for the template.
* Subject Attributes: A list of common names that can be included in the certificate subject. Each row accepts a fixed value or pattern such as `example.com` or `*.example.com` and whether it is allowed or denied.
* Subject Alternative Names (SANs): A list of SANs that can appear in the certificate. Each row accepts a SAN type (e.g. DNS, IP, Email, URI), a fixed value or pattern such as `example.com` or `*.example.com`, and an allow or deny flag.
* Allowed Signature Algorithms: The set of signature algorithms permitted to sign certificates under this template such as `SHA256-RSA`, `SHA512-RSA`, etc.
* Allowed Key Algorithms: The set of public key algorithms permitted for certificate requests such as `RSA-2048`, `RSA-4096`, etc.
* Key Usages: The cryptographic purposes of the certificate such as Digital Signature, Key Encipherment, etc.
* Extended Key Usages: The higher-level intended uses of the certificate such as Server Authentication, Client Authentication, etc.
* Certificate Validity: The maximum lifetime of certificates that can be requested for certificates validated against this template. You can specify both a duration and unit (days, months, or years).
# Certificate Lifecycle
Source: https://infisical.com/docs/documentation/platform/pki/concepts/certificate-lifecycle
Learn what is the certificate lifecycle and how it works.
## Certificate Lifecycle
Typically, a certificate goes through a series of stages during its lifetime from creation to retirement. This is called the certificate lifecycle. The exact names of these stages may vary from vendor to vendor, but they typically include [discovery](/documentation/platform/pki/concepts/certificate-lifecycle#discovery), [enrollment](/documentation/platform/pki/concepts/certificate-lifecycle#enrollment), [deployment](/documentation/platform/pki/concepts/certificate-lifecycle#deployment), [renewal](/documentation/platform/pki/concepts/certificate-lifecycle#renewal), [revocation](/documentation/platform/pki/concepts/certificate-lifecycle#revocation), and [retirement](/documentation/platform/pki/concepts/certificate-lifecycle#retirement).
Note that not every stage is needed. For instance:
* You are not required to discover certificates in order to start issuing and managing them.
* You may not need to revoke a certificate explicitly if it expires naturally and is replaced during routine renewal.
## Discovery
Certificate discovery is the process of identifying all active and inactive certificates across an environment, including those found on web servers, load balancers, services, and devices. A complete inventory prevents outages from forgotten certificates and creates the foundation for automation and monitoring.
## Enrollment (Request / Issuance)
Certificate enrollment is the process of requesting a certificate from a CA and can follow different approaches depending on the system or protocol in use.
Common approaches to certificate enrollment include:
* CSR-based enrollment: The client generates a key pair locally and submits a Certificate Signing Request (CSR) to a CA for certificate issuance.
* CSR-less enrollment: The client requests a certificate directly from a CA which may handle key generation internally and return the key pair in the response.
Enrollment can be manually completed via API or fully automated using protocols like EST or ACME. The choice of enrollment method depends on security requirements, operational constraints, and integration context.
## Deployment
Certificate deployment involves installing the issued certificate on the appropriate systems and services, such as web servers, load balancers, or internal endpoints. It can also include distributing or [synchronizing certificates](/documentation/platform/pki/certificate-syncs/overview) to external systems like cloud key stores (e.g., AWS Secrets Manager, Google Secret Manager, Azure Key Vault) so they can be securely consumed by workloads running in the cloud.
Deployment can happen manually or through automated mechanisms such as configuration pipelines, agents, or webhook integrations.
## Renewal
Certificate renewal is the process of requesting a new certificate from a CA before it expires to maintain trust and availability; this process can involve reusing the same key pair or rotating to a new one.
The renewal process can be server-driven or client-driven:
* Server-driven: Infisical automatically renews the certificate on your behalf. The renewed certificate is stored in the platform and can be synchronized to external systems such as cloud key stores.
* Client-driven: An external client, such as an agent or workload, initiates the renewal against Infisical. This is useful when key material needs to remain under client control or when rotation is tied to application-specific logic.
This flexibility allows certificates to be renewed in a way that aligns with different security, automation, and infrastructure models.
## Revocation
Certificate revocation is the process of invalidating a certificate to prevent it from being used. This is required when a certificate is compromised, misconfigured, or no longer needed. The CA signals this status to clients through CRLs or OCSP. A new certificate can be issued and deployed if needed.
## Retirement
Certificate retirement is the process of removing a certificate from the system. This is typically done when a certificate is no longer needed or has expired.
# Certificate Management
Source: https://infisical.com/docs/documentation/platform/pki/concepts/certificate-mgmt
Learn what is certificate management and why it matters for building secure systems.
## What is a Certificate?
A (digital) *certificate* is a file that is tied to a cryptographic key pair and is used to verify the identity of a website, user, device, or service. It helps establish trust and secure, encrypted communication between systems.
For example, when you visit a website over HTTPS, your browser checks the TLS certificate deployed on the web server or load balancer to make sure it’s really the site it claims to be. If the certificate is valid, your browser establishes an encrypted connection with the server.
Certificates contain information about the subject (who it identifies), the public key, and a digital signature from the CA that issued the certificate. They also include additional fields such as key usages, validity periods, and extensions that define how and where the certificate can be used. When a certificate expires, the service presenting it is no longer trusted, and clients won't be able to establish a secure connection to the service.
## What is Certificate Management?
As infrastructure scales and systems become more distributed, certificates sprawl. Without proper visibility and automation in place, certificates scatter across IT infrastructure, creating blind spots that can lead to service outages when certificates aren't renewed in time.
To solve certificate sprawl and avoid outages, organizations rely on certificate management: the practice of centralizing and automating the certificate lifecycle from issuance through renewal and revocation.
A consistent approach makes it easier to keep certificates valid and trusted, reduce operational risk, and maintain secure communication across environments.
# Certificate Enrollment via ACME
Source: https://infisical.com/docs/documentation/platform/pki/enrollment-methods/acme
## Concept
The ACME enrollment method allows Infisical to act as an ACME server. It lets you request and manage certificates against a specific [certificate profile](/documentation/platform/pki/certificates/profiles) using the [ACME protocol](https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment).
This method is suitable for web servers, load balancers, and other general-purpose servers that can run an [ACME client](https://letsencrypt.org/docs/client-options/) for automated certificate management.
Infisical's ACME enrollment method is based on [RFC 8555](https://datatracker.ietf.org/doc/html/rfc8555/).
## Prerequisites
Install an [ACME client](https://letsencrypt.org/docs/client-options/) onto your server. This client will handle [ACME challenges](https://letsencrypt.org/docs/challenge-types/) and request/renew certificates from Infisical.
## Guide to Certificate Enrollment via ACME
In the following steps, we explore how to issue a X.509 certificate using the ACME enrollment method.
From the ACME configuration, gather the following values:
* ACME Directory URL: The URL that the ACME client will use to communicate with Infisical's ACME server.
* EAB Key Identifier (KID): A unique identifier that tells Infisical which ACME account is making the request.
* EAB Secret: A secret key that authenticates your ACME client with Infisical.
Here, select the certificate profile from step 1 that will be used to issue the certificate and fill out the rest of the details for the certificate to be issued.
Here's some guidance on each EST-specific configuration field:
* Disable Bootstrap CA Validation: Enable this if your devices are not configured with a bootstrap certificate.
* EST Passphrase: This is also used to authenticate your devices with Infisical's EST server. When configuring the clients, use the value defined here as the EST password.
* CA Chain Certificate: This is the certificate chain used to validate your devices' manufacturing/pre-installed certificates. This will be used to authenticate your devices with Infisical's EST server.
The complete URL structure of the supported EST endpoints may look like the following:
* [https://app.infisical.com:8443/.well-known/est/\{profile\_id}/cacerts](https://app.infisical.com:8443/.well-known/est/\{profile_id}/cacerts)
* [https://app.infisical.com:8443/.well-known/est/\{profile\_id}/simpleenroll](https://app.infisical.com:8443/.well-known/est/\{profile_id}/simpleenroll)
* [https://app.infisical.com:8443/.well-known/est/\{profile\_id}/simplereenroll](https://app.infisical.com:8443/.well-known/est/\{profile_id}/simplereenroll)
Click the **Reveal ACME EAB** option to view the ACME configuration details.
From the ACME configuration, gather the following values:
* ACME Directory URL: The URL that Certbot will use to communicate with Infisical's ACME server. This takes the form `https://your-infisical-instance.com/api/v1/cert-manager/certificate-profiles/{profile-id}/acme/directory`.
* EAB Key Identifier (KID): A unique identifier that tells Infisical which ACME account is making the request.
* EAB Secret: A secret key that authenticates your ACME client with Infisical.
Click the **Reveal ACME EAB** option to view the ACME configuration details.
From the ACME configuration, gather the following values:
* ACME Directory URL: The URL that Certbot will use to communicate with Infisical's ACME server. This takes the form `https://your-infisical-instance.com/api/v1/cert-manager/certificate-profiles/{profile-id}/acme/directory`.
* EAB Key Identifier (KID): A unique identifier that tells Infisical which ACME account is making the request.
* EAB Secret: A secret key that authenticates your ACME client with Infisical.
Click the **Reveal ACME EAB** option to view the ACME configuration details.
From the ACME configuration, gather the following values:
* ACME Directory URL: The URL that Certbot will use to communicate with Infisical's ACME server. This takes the form `https://your-infisical-instance.com/api/v1/cert-manager/certificate-profiles/{profile-id}/acme/directory`.
* EAB Key Identifier (KID): A unique identifier that tells Infisical which ACME account is making the request.
* EAB Secret: A secret key that authenticates your ACME client with Infisical.
Click the **Reveal ACME EAB** option to view the ACME configuration details.
From the ACME configuration, gather the following values:
* ACME Directory URL: The URL that Certbot will use to communicate with Infisical's ACME server. This takes the form `https://your-infisical-instance.com/api/v1/cert-manager/certificate-profiles/{profile-id}/acme/directory`.
* EAB Key Identifier (KID): A unique identifier that tells Infisical which ACME account is making the request.
* EAB Secret: A secret key that authenticates your ACME client with Infisical.
Click the **Reveal ACME EAB** option to view the ACME configuration details.
From the ACME configuration, gather the following values:
* ACME Directory URL: The URL that win-acme will use to communicate with Infisical's ACME server. This takes the form `https://your-infisical-instance.com/api/v1/cert-manager/certificate-profiles/{profile-id}/acme/directory`.
* EAB Key Identifier (KID): A unique identifier that tells Infisical which ACME account is making the request.
* EAB Secret: A secret key that authenticates your ACME client with Infisical.
### Policy enforcement levels
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.
### Example of updating secrets with Approval workflows
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
The supported project types are:
* [Secrets Management](/documentation/platform/secrets-mgmt/overview): Securely store, access, and distribute secrets across environments with fine-grained controls, automatic rotation, and audit logging.
* [Secrets Scanning](/documentation/platform/secret-scanning/overview): Detect hardcoded secrets in code, CI pipelines, and infrastructure—integrated with GitHub, GitLab, Bitbucket, and more.
* [Infisical PKI](/documentation/platform/pki/overview): Issue and manage X.509 certificates using protocols like EST, with support for internal and external CAs.
* [Infisical SSH](/documentation/platform/ssh/overview): Provide short-lived SSH access to servers using certificate-based authentication, replacing static keys with policy-driven, time-bound control.
* [Infisical KMS](/documentation/platform/kms/overview): Encrypt and decrypt data using centrally managed keys with enforced access policies and full audit visibility.
* [Infisical PAM](/documentation/platform/pam/overview): Manage access to resources like databases, servers, and accounts with policy-based controls and approvals.
## Roles and Access Control
[Users](/documentation/platform/identities/user-identities) and [machine identities](/documentation/platform/identities/machine-identities) must be added to a project to access its resources. Each identity is assigned a [project-level role](/documentation/platform/access-controls/role-based-access-controls#project-level-access-controls) that defines what they can manage—such as secrets, certificates, or SSH access. These roles apply to both individuals and [user groups](/documentation/platform/groups), enabling scalable access across teams and environments.
Project access is strictly scoped: only members of a project can view or manage its resources. If someone needs access but isn’t part of the project, they can submit an access request.
Each project in Infisical has its own [access control model](/documentation/platform/access-controls/role-based-access-controls#project-level-access-controls), distinct from [organization-level access control](/documentation/platform/access-controls/role-based-access-controls#organization-level-access-controls). While organization roles govern broader administrative access, project-level roles control what users, groups, and machine identities can do within the boundaries of a specific project—such as managing secrets, issuing certificates, or configuring SSH access.
Depending on the project type (e.g. Secrets Management, PKI, SSH), project-level access control supports advanced features like [temporary access](/documentation/platform/access-controls/temporary-access), [access requests](/documentation/platform/access-controls/access-requests), and [additional privileges](/documentation/platform/access-controls/additional-privileges).
To learn more about how permissions work in detail, refer to the [access control documentation](/documentation/platform/access-controls/overview).
## Audit Logs
Infisical provides [audit logging](/documentation/platform/audit-logs) at the project level to help teams monitor activity and maintain accountability within a specific project. These logs capture all relevant events—such as secret access, certificate issuance, and SSH activity—that occur within the boundaries of that project.
Unlike the organization-level audit view, which aggregates logs across all projects in one centralized interface, the project-level audit view is scoped to a single project. This enables relevant project admins and contributors to review activity relevant to their work without having broader access to audit logs in other projects that they are not part of.
## Project Settings
Each project has its own settings panel, with options that vary depending on the selected product type. These may include
setup and configuration for environments, tags, behaviors, encryption strategies, and other options.
Project settings are fully independent and reflect the capabilities of the associated product.
# Project Templates
Source: https://infisical.com/docs/documentation/platform/project-templates
Learn how to manage and apply project templates
## Concept
Project Templates streamline your ability to set up projects by providing customizable templates to configure projects quickly with a predefined set of environments and roles.
Specify your template details. Here's some guidance on each field:
* Name: A slug-friendly name for the template.
* Description: An optional description of the intended usage of this template.
Customize the environments and roles to your needs.
Your project will be provisioned with the configured template roles and environments.
Next, press **Manage SCIM Tokens** and then **Create** to generate a SCIM token for Azure.
Next, copy the **SCIM URL** and **New SCIM Token** to use when configuring SCIM in Azure.
Next, set the following fields:
* Provisioning Mode: Select **Automatic**.
* Tenant URL: Input **SCIM URL** from Step 1.
* Secret Token: Input the **New SCIM Token** from Step 1.
Afterwards, click **Enable SCIM** and press the **Test Connection** button to check that SCIM is configured properly.
After you hit **Save**, select **Provision Microsoft Entra ID Users** under the **Mappings** subsection.
Next, adjust the mappings so you have them configured as below:
Finally, head to your Enterprise Application > Provisioning and set the **Provisioning Status** to **On**.
Alternatively, you can go to **Overview** and press **Start provisioning** to have Azure start provisioning/deprovisioning users to Infisical.
Now Azure can provision/deprovision users to/from your organization in Infisical.
To configure a mapping, simply enter the SCIM group's name and select the role you would like users to be assigned from this group. Be sure
to tap **Update Mappings** once complete.
Next, press **Manage SCIM Tokens** and then **Create** to generate a SCIM token for JumpCloud.
Next, copy the **SCIM URL** and **New SCIM Token** to use when configuring SCIM in JumpCloud.
Next, set the following SCIM connection fields:
* Base URL: Input the **SCIM URL** from Step 1.
* Token Key: Input the **New SCIM Token** from Step 1.
* Test User Email: Input a test user email to be used by JumpCloud for testing the SCIM connection.
Alos, under HTTP Header > Authorization: Bearer, input the **New SCIM Token** from Step 1.
Next, press **Test Connection** to check that SCIM is configured properly. Finally, press **Activate**
to have JumpCloud start provisioning/deprovisioning users to Infisical.
Now JumpCloud can provision/deprovision users and user groups to/from your organization in Infisical.
Next, press **Manage SCIM Tokens** and then **Create** to generate a SCIM token for Okta.
Next, copy the **SCIM URL** and **New SCIM Token** to use when configuring SCIM in Okta.
Next, head to Provisioning > Integration and set the following SCIM connection fields:
* SCIM connector base URL: Input the **SCIM URL** from Step 1.
* Unique identifier field for users: Input `email`.
* Supported provisioning actions: Select **Push New Users**, **Push Profile Updates**, and **Push Groups**.
* Authentication Mode: `HTTP Header`.
Under HTTP Header > Authorization: Bearer, input the **New SCIM Token** from Step 1.
Next, press **Test Connector Configuration** to check that SCIM is configured properly.
Next, head to Provisioning > To App and check the boxes labeled **Enable** for **Create Users**, **Update User Attributes**, and **Deactivate Users**.
Now Okta can provision/deprovision users and user groups to/from your organization in Infisical.
Next, press **Manage SCIM Tokens** and then **Create** to generate a SCIM token for PingOne.
Next, copy the **SCIM URL** and **New SCIM Token** to use when configuring SCIM in PingOne.
Select the "Identity Store" option.
Search for the "SCIM Outbound" option to start the configuration process for SCIM. Finally, press the **Next** button. Give the connection a name and optionally add a description.
**2. Configure the connection**
Once you have selected the SCIM Outbound option, you'll be prompted to enter the authentication details that PingOne will use to authenticate with Infisical SCIM. This is the **SCIM URL** and **New SCIM Token** from the previous step.
Set the following fields:
* `SCIM BASE URL`: Input the **SCIM URL** from the previous step.
* `Users Resource`: Leave as default, `/Users`.
* `Groups Resource`: Leave as default, `/Groups`.
* `SCIM Version`: Leave as default, `2.0`.
* `Authentication Method`: Select `OAuth 2 Bearer Token`.
* `Oauth Access Token`: Input the **New SCIM Token** from step 1.
* `Auth Type Header`: Select `Bearer`.
Once this is done, you can press the **Test Connection** button to check that SCIM is configured properly. You should see a success message saying "Connection Successful".
If the connection is successful, press the "Next" button.
In the final step, you'll be prompted to configure the mappings for the connection.
Set the following fields:
* `User Filter Expression`: `email.value Eq "%s"`.
* `User Identifier`: `workEmail`.
* `Deprovision on Rule Deletion:` Enabled.
Once this is configured, press the "Save" button.
**3. Enable the connection**
Finally, remember to enable the connection by pressing the enable toggle.
Select the "New Rule" button and choose a name for the rule, then press the "Create Rule" button.
**2. Configure the rule connection**
Once you have created a rule, you now need to configure the connection to use for the rule.
Select the connection you created in the previous step and press the "Save" button.
**3. Configure the rule user filter**
Select the Edit pencil icon to open the user filter configuration. This step dictates which users will be provisioned to Infisical.
In this case, we are provisioning all users that are enabled in PingOne. Configure your user filter to match your desired users, and then press the "Save" button.
**4. Configure Groups**
This step is optional and only relevant if you want to provision PingOne groups to Infisical.
Open the "Group Provisioning" tab and press the "Add Groups" button to select which groups will be provisioned to Infisical.
Select the groups you want to provision to Infisical and press the "Save" button.
**5. Enable the rule**
Once you have configured the rule, you can enable it by pressing the "Enable" toggle.
Since secret referencing reconstructs values on the client side, any client (user, service token, or machine identity) fetching secrets must have proper permissions to access all base and dependent secrets. Without sufficient permissions, secret references will not resolve to their appropriate values.
For example, if secret A references values from secrets B and C located in different scopes, the client must have read access to all three scopes containing secrets A, B, and C. If permission to any referenced secret is missing, the reference will remain unresolved, potentially causing application errors or unexpected behavior.
This is an important security consideration when planning your secret access strategy, especially when working with cross-environment or cross-folder references.
Once added, a secret import will show up with a green import icon on the secrets dashboard.
In the example below, you can see that the items in the path `/some-folder` are being imported into
the current folder context.
To delete a secret import, hover over it and press the **X** button that appears on the right side.
Lastly, note that the order of secret imports matters. If two secret imports contain secrets with the same name, then the secret value from the bottom-most secret import is taken — "the last one wins."
To reorder a secret import, hover over it and drag the arrows handle to the position you want.
# Auth0 Client Secret Rotation
Source: https://infisical.com/docs/documentation/platform/secret-rotation/auth0-client-secret
Learn how to automatically rotate Auth0 Client Secrets.
2. Select the **Auth0 Client Secret** option.
3. Select the **Auth0 Connection** to use and configure the rotation behavior. Then click **Next**.
* **Auth0 Connection** - the connection that will perform the rotation of the specified application's Client Secret.
* **Rotation Interval** - the interval, in days, that once elapsed will trigger a rotation.
* **Rotate At** - the local time of day when rotation should occur once the interval has elapsed.
* **Auto-Rotation Enabled** - whether secrets should automatically be rotated once the rotation interval has elapsed. Disable this option to manually rotate secrets or pause secret rotation.
5. Specify the secret names that the client credentials should be mapped to. Then click **Next**.
* **Client ID** - the name of the secret that the application Client ID will be mapped to.
* **Client Secret** - the name of the secret that the rotated Client Secret will be mapped to.
6. Give your rotation a name and description (optional). Then click **Next**.
* **Name** - the name of the secret rotation configuration. Must be slug-friendly.
* **Description** (optional) - a description of this rotation configuration.
7. Review your configuration, then click **Create Secret Rotation**.
8. Your **Auth0 Client Secret** credentials are now available for use via the mapped secrets.
### Sample request
```bash Request theme={"dark"}
curl --request POST \
--url https://us.infisical.com/api/v2/secret-rotations/auth0-client-secret \
--header 'Content-Type: application/json' \
--data '{
"name": "my-auth0-rotation",
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"description": "my client secret rotation",
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"environment": "dev",
"secretPath": "/",
"isAutoRotationEnabled": true,
"rotationInterval": 30,
"rotateAtUtc": {
"hours": 0,
"minutes": 0
},
"parameters": {
"clientId": "...",
},
"secretsMapping": {
"clientId": "AUTH0_CLIENT_ID",
"clientSecret": "AUTH0_CLIENT_SECRET"
}
}'
```
2. Select the **AWS IAM User Secret** option.
3. Select the **AWS Connection** to use and configure the rotation behavior. Then click **Next**.
* **AWS Connection** - the connection that will perform the rotation of the specified application's Client Secret.
* **Rotation Interval** - the interval, in days, that once elapsed will trigger a rotation.
* **Rotate At** - the local time of day when rotation should occur once the interval has elapsed.
* **Auto-Rotation Enabled** - whether secrets should automatically be rotated once the rotation interval has elapsed. Disable this option to manually rotate secrets or pause secret rotation.
4. Select the AWS IAM user and the region of the user whose credentials you want to rotate. Then click **Next**.
5. Specify the secret names that the AWS IAM access key credentials should be mapped to. Then click **Next**.
* **Access Key ID** - the name of the secret that the AWS access key ID will be mapped to.
* **Secret Access Key** - the name of the secret that the rotated secret access key will be mapped to.
6. Give your rotation a name and description (optional). Then click **Next**.
* **Name** - the name of the secret rotation configuration. Must be slug-friendly.
* **Description** (optional) - a description of this rotation configuration.
7. Review your configuration, then click **Create Secret Rotation**.
8. Your **AWS IAM User** credentials are now available for use via the mapped secrets.
### Sample request
```bash Request theme={"dark"}
curl --request POST \
--url https://us.infisical.com/api/v2/secret-rotations/aws-iam-user-secret \
--header 'Content-Type: application/json' \
--data '{
"name": "my-aws-rotation",
"projectId": "9602cfc5-20b9-4c35-a056-dd7372db0f25",
"description": "My rotation strategy description",
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"environment": "dev",
"secretPath": "/",
"isAutoRotationEnabled": true,
"rotationInterval": 2,
"rotateAtUtc": {
"hours": 11.5,
"minutes": 29.5
},
"parameters": {
"userName": "testUser",
"region": "us-east-1"
},
"secretsMapping": {
"accessKeyId": "AWS_ACCESS_KEY_ID",
"secretAccessKey": "AWS_SECRET_ACCESS_KEY"
}
}'
```
### Sample response
```bash Response theme={"dark"}
{
"secretRotation": {
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"name": "my-aws-rotation",
"description": "My rotation strategy description",
"secretsMapping": {
"accessKeyId": "AWS_ACCESS_KEY_ID",
"secretAccessKey": "AWS_SECRET_ACCESS_KEY"
},
"isAutoRotationEnabled": true,
"activeIndex": 0,
"folderId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"createdAt": "2023-11-07T05:31:56Z",
"updatedAt": "2023-11-07T05:31:56Z",
"rotationInterval": 123,
"rotationStatus": "success",
"lastRotationAttemptedAt": "2023-11-07T05:31:56Z",
"lastRotatedAt": "2023-11-07T05:31:56Z",
"lastRotationJobId": null,
"nextRotationAt": "2023-11-07T05:31:56Z",
"isLastRotationManual": true,
"connection": {
"app": "aws",
"name": "my-aws-connection",
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a"
},
"environment": {
"slug": "dev",
"name": "Development",
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a"
},
"projectId": "9602cfc5-20b9-4c35-a056-dd7372db0f25",
"folder": {
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"path": "/"
},
"rotateAtUtc": {
"hours": 11.5,
"minutes": 29.5
},
"lastRotationMessage": null,
"type": "aws-iam-user-secret",
"parameters": {
"userName": "testUser",
"region": "us-east-1"
}
}
}
```
2. Select the **Azure Client Secret** option.
3. Select the **Azure Connection** to use and configure the rotation behavior. Then click **Next**.
* **Azure Connection** - the connection that will perform the rotation of the specified application's Client Secret.
* **Rotation Interval** - the interval, in days, that once elapsed will trigger a rotation.
* **Rotate At** - the local time of day when rotation should occur once the interval has elapsed.
* **Auto-Rotation Enabled** - whether secrets should automatically be rotated once the rotation interval has elapsed. Disable this option to manually rotate secrets or pause secret rotation.
4. Select the Azure application whose Client Secret you want to rotate. Then click **Next**.
5. Specify the secret names that the client credentials should be mapped to. Then click **Next**.
* **Client ID** - the name of the secret that the application Client ID will be mapped to.
* **Client Secret** - the name of the secret that the rotated Client Secret will be mapped to.
6. Give your rotation a name and description (optional). Then click **Next**.
* **Name** - the name of the secret rotation configuration. Must be slug-friendly.
* **Description** (optional) - a description of this rotation configuration.
7. Review your configuration, then click **Create Secret Rotation**.
8. Your **Azure Client Secret** credentials are now available for use via the mapped secrets.
### Sample request
```bash Request theme={"dark"}
curl --request POST \
--url https://us.infisical.com/api/v2/secret-rotations/azure-client-secret \
--header 'Content-Type: application/json' \
--data '{
"name": "my-azure-rotation",
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"description": "my client secret rotation",
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"environment": "dev",
"secretPath": "/",
"isAutoRotationEnabled": true,
"rotationInterval": 30,
"rotateAtUtc": {
"hours": 0,
"minutes": 0
},
"parameters": {
"objectId": "...",
"clientId": "...",
"appName": "..."
},
"secretsMapping": {
"clientId": "AZURE_CLIENT_ID",
"clientSecret": "AZURE_CLIENT_SECRET"
}
}'
```
### Sample response
```bash Response theme={"dark"}
{
"secretRotation": {
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"name": "my-azure-rotation",
"description": "my client secret rotation",
"secretsMapping": {
"clientId": "AZURE_CLIENT_ID",
"clientSecret": "AZURE_CLIENT_SECRET"
},
"isAutoRotationEnabled": true,
"activeIndex": 0,
"folderId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"createdAt": "2023-11-07T05:31:56Z",
"updatedAt": "2023-11-07T05:31:56Z",
"rotationInterval": 30,
"rotationStatus": "success",
"lastRotationAttemptedAt": "2023-11-07T05:31:56Z",
"lastRotatedAt": "2023-11-07T05:31:56Z",
"lastRotationJobId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"nextRotationAt": "2023-11-07T05:31:56Z",
"connection": {
"app": "azure",
"name": "my-azure-connection",
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a"
},
"environment": {
"slug": "dev",
"name": "Development",
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a"
},
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"folder": {
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"path": "/"
},
"rotateAtUtc": {
"hours": 0,
"minutes": 0
},
"lastRotationMessage": null,
"type": "azure-client-secret",
"parameters": {
"objectId": "...",
"appName": "...",
"clientId": "..."
}
}
}
```
2. Select the **LDAP Password** option.
3. Select the **LDAP Connection** to use and configure the rotation behavior. Then click **Next**.
* **LDAP Connection** - the connection that will perform the rotation of the configured principal's password.
* **Rotation Method** - The method to use when rotating the target principal's password.
* **Connection Principal** - Infisical will use the LDAP Connection's binding principal to rotate the target principal's password.
* **Target Principal** - Infisical will bind with the target Principal to rotate their own password.
* **DN/UPN** - The Distinguished Name (DN), or User Principal Name (UPN) if supported, of the principal whose password you want to rotate.
* **Password** - The target principal's password (if **Rotation Method** is set to **Target Principal**).
* **Password Requirements** - The constraints to apply when generating new passwords.
5. Specify the secret names that the client credentials should be mapped to. Then click **Next**.
* **DN/UPN** - the name of the secret that the principal's Distinguished Name (DN) or User Principal Name (UPN) will be mapped to.
* **Password** - the name of the secret that the rotated password will be mapped to.
6. Give your rotation a name and description (optional). Then click **Next**.
* **Name** - the name of the secret rotation configuration. Must be slug-friendly.
* **Description** (optional) - a description of this rotation configuration.
7. Review your configuration, then click **Create Secret Rotation**.
8. Your **LDAP Password** credentials are now available for use via the mapped secrets.
2. Select the **Microsoft SQL Server Credentials** option.
3. Select the **Microsoft SQL Server Connection** to use and configure the rotation behavior. Then click **Next**.
* **Microsoft SQL Server Connection** - the connection that will perform the rotation of the configured database user credentials.
* **Rotation Interval** - the interval, in days, that once elapsed will trigger a rotation.
* **Rotate At** - the local time of day when rotation should occur once the interval has elapsed.
* **Auto-Rotation Enabled** - whether secrets should automatically be rotated once the rotation interval has elapsed. Disable this option to manually rotate secrets or pause secret rotation.
4. Input the usernames of the database users created above that will be used for rotation. Then click **Next**.
* **Database Username 1** - the username of the first user that will be used for rotation.
* **Database Username 2** - the username of the second user that will be used for rotation.
5. Specify the secret names that the active credentials should be mapped to. Then click **Next**.
* **Username** - the name of the secret that the active username will be mapped to.
* **Password** - the name of the secret that the active password will be mapped to.
6. Give your rotation a name and description (optional). Then click **Next**.
* **Name** - the name of the secret rotation configuration. Must be slug-friendly.
* **Description** (optional) - a description of this rotation configuration.
7. Review your configuration, then click **Create Secret Rotation**.
8. Your **Microsoft SQL Server Credentials** are now available for use via the mapped secrets.
2. Select the **MySQL Credentials** option.
3. Select the **MySQL Connection** to use and configure the rotation behavior. Then click **Next**.
* **MySQL Connection** - the connection that will perform the rotation of the configured database user credentials.
* **Rotation Interval** - the interval, in days, that once elapsed will trigger a rotation.
* **Rotate At** - the local time of day when rotation should occur once the interval has elapsed.
* **Auto-Rotation Enabled** - whether secrets should automatically be rotated once the rotation interval has elapsed. Disable this option to manually rotate secrets or pause secret rotation.
4. Input the usernames of the database users created above that will be used for rotation. Then click **Next**.
* **Database Username 1** - the username of the first user that will be used for rotation.
* **Database Username 2** - the username of the second user that will be used for rotation.
5. Specify the secret names that the active credentials should be mapped to. Then click **Next**.
* **Username** - the name of the secret that the active username will be mapped to.
* **Password** - the name of the secret that the active password will be mapped to.
6. Give your rotation a name and description (optional). Then click **Next**.
* **Name** - the name of the secret rotation configuration. Must be slug-friendly.
* **Description** (optional) - a description of this rotation configuration.
7. Review your configuration, then click **Create Secret Rotation**.
8. Your **MySQL Credentials** are now available for use via the mapped secrets.
2. Select the **Okta Client Secret** option.
3. Configure the rotation behavior, then click **Next**.
* **Okta Connection** - the connection that will perform the rotation of the specified application's Client Secret.
* **Rotation Interval** - the interval, in days, that once elapsed will trigger a rotation.
* **Rotate At** - the local time of day when rotation should occur once the interval has elapsed.
* **Auto-Rotation Enabled** - whether secrets should automatically be rotated once the rotation interval has elapsed. Disable this option to manually rotate secrets or pause secret rotation.
4. Select the Okta application whose Client Secret you want to rotate. Then click **Next**.
5. Specify the secret names that the client credentials should be mapped to. Then click **Next**.
* **Client ID** - the name of the secret that the application Client ID will be mapped to.
* **Client Secret** - the name of the secret that the rotated Client Secret will be mapped to.
6. Give your rotation a name and description (optional). Then click **Next**.
* **Name** - the name of the secret rotation configuration. Must be slug-friendly.
* **Description** (optional) - a description of this rotation configuration.
7. Review your configuration, then click **Create Secret Rotation**.
8. Your **Okta Client Secret** credentials are now available for use via the mapped secrets.
### Sample request
```bash Request theme={"dark"}
curl --request POST \
--url https://us.infisical.com/api/v2/secret-rotations/okta-client-secret \
--header 'Content-Type: application/json' \
--data '{
"name": "my-okta-rotation",
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"description": "my client secret rotation",
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"environment": "dev",
"secretPath": "/",
"isAutoRotationEnabled": true,
"rotationInterval": 30,
"rotateAtUtc": {
"hours": 0,
"minutes": 0
},
"parameters": {
"clientId": "...",
},
"secretsMapping": {
"clientId": "OKTA_CLIENT_ID",
"clientSecret": "OKTA_CLIENT_SECRET"
}
}'
```
### Sample response
```bash Response theme={"dark"}
{
"secretRotation": {
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"name": "my-okta-rotation",
"description": "my client secret rotation",
"secretsMapping": {
"clientId": "OKTA_CLIENT_ID",
"clientSecret": "OKTA_CLIENT_SECRET"
},
"isAutoRotationEnabled": true,
"activeIndex": 0,
"folderId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"createdAt": "2023-11-07T05:31:56Z",
"updatedAt": "2023-11-07T05:31:56Z",
"rotationInterval": 30,
"rotationStatus": "success",
"lastRotationAttemptedAt": "2023-11-07T05:31:56Z",
"lastRotatedAt": "2023-11-07T05:31:56Z",
"lastRotationJobId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"nextRotationAt": "2023-11-07T05:31:56Z",
"connection": {
"app": "okta",
"name": "my-okta-connection",
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a"
},
"environment": {
"slug": "dev",
"name": "Development",
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a"
},
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"folder": {
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"path": "/"
},
"rotateAtUtc": {
"hours": 0,
"minutes": 0
},
"lastRotationMessage": null,
"type": "okta-client-secret",
"parameters": {
"clientId": "..."
}
}
}
```
2. Select the **OracleDB Credentials** option.
3. Select the **OracleDB Connection** to use and configure the rotation behavior. Then click **Next**.
* **OracleDB Connection** - the connection that will perform the rotation of the configured database user credentials.
* **Rotation Interval** - the interval, in days, that once elapsed will trigger a rotation.
* **Rotate At** - the local time of day when rotation should occur once the interval has elapsed.
* **Auto-Rotation Enabled** - whether secrets should automatically be rotated once the rotation interval has elapsed. Disable this option to manually rotate secrets or pause secret rotation.
4. Input the usernames of the database users created above that will be used for rotation. Then click **Next**.
* **Database Username 1** - the username of the first user that will be used for rotation.
* **Database Username 2** - the username of the second user that will be used for rotation.
* **Username** - the name of the secret that the active username will be mapped to.
* **Password** - the name of the secret that the active password will be mapped to.
6. Give your rotation a name and description (optional). Then click **Next**.
* **Name** - the name of the secret rotation configuration. Must be slug-friendly.
* **Description** (optional) - a description of this rotation configuration.
7. Review your configuration, then click **Create Secret Rotation**.
8. Your **OracleDB Credentials** are now available for use via the mapped secrets.
2. Select the **PostgreSQL Credentials** option.
3. Select the **PostgreSQL Connection** to use and configure the rotation behavior. Then click **Next**.
* **PostgreSQL Connection** - the connection that will perform the rotation of the configured database user credentials.
* **Rotation Interval** - the interval, in days, that once elapsed will trigger a rotation.
* **Rotate At** - the local time of day when rotation should occur once the interval has elapsed.
* **Auto-Rotation Enabled** - whether secrets should automatically be rotated once the rotation interval has elapsed. Disable this option to manually rotate secrets or pause secret rotation.
4. Input the usernames of the database users created above that will be used for rotation. Then click **Next**.
* **Database Username 1** - the username of the first user that will be used for rotation.
* **Database Username 2** - the username of the second user that will be used for rotation.
5. Specify the secret names that the active credentials should be mapped to. Then click **Next**.
* **Username** - the name of the secret that the active username will be mapped to.
* **Password** - the name of the secret that the active password will be mapped to.
6. Give your rotation a name and description (optional). Then click **Next**.
* **Name** - the name of the secret rotation configuration. Must be slug-friendly.
* **Description** (optional) - a description of this rotation configuration.
7. Review your configuration, then click **Create Secret Rotation**.
8. Your **PostgreSQL Credentials** are now available for use via the mapped secrets.
2. Select the **Redis Credentials** option.
3. Select the **Redis Connection** to use and configure the rotation behavior. Then click **Next**.
* **Redis Connection** - the connection that will perform the rotation of the configured database user credentials.
* **Rotation Interval** - the interval, in days, that once elapsed will trigger a rotation.
* **Rotate At** - the local time of day when rotation should occur once the interval has elapsed.
* **Auto-Rotation Enabled** - whether secrets should automatically be rotated once the rotation interval has elapsed. Disable this option to manually rotate secrets or pause secret rotation.
4. Input the password requirements and permission scope for the Redis users that will be created for the rotation. Then click **Next**.
* **Permission Scope** - The scope of the Redis users that will be created for the rotation. This will default to `~* +@all` if not specified.
* **Password Requirements** - The requirements for the password of the Redis users that will be created for the rotation.
5. Specify the secret names that the active credentials should be mapped to. Then click **Next**.
* **Username** - the name of the secret that the active username will be mapped to.
* **Password** - the name of the secret that the active password will be mapped to.
6. Give your rotation a name and description (optional). Then click **Next**.
* **Name** - the name of the secret rotation configuration. Must be slug-friendly.
* **Description** (optional) - a description of this rotation configuration.
7. Review your configuration, then click **Create Secret Rotation**.
8. Your **Redis Credentials** are now available for use via the mapped secrets.
2. Select the **Bitbucket** option.
3. Configure which workspace and repositories you would like to scan. Then click **Next**.
* **Bitbucket Connection** - the connection that has access to the repositories you want to scan.
* **Workspace** - the Bitbucket workspace to scan secrets in.
* **Scan Repositories** - select which repositories you would like to scan.
* **All Repositories** - Infisical will scan all repositories associated with your connection.
* **Select Repositories** - Infisical will scan the selected repositories.
* **Auto-Scan Enabled** - whether Infisical should automatically perform a scan when a push is made to configured repositories.
4. Give your data source a name and description (optional). Then click **Next**.
* **Name** - the name of the data source. Must be slug-friendly.
* **Description** (optional) - a description of this data source.
5. Review your data source, then click **Create Data Source**.
6. Your **Bitbucket Data Source** is now available and will begin a full scan if **Auto-Scan** is enabled.
7. You can view repositories and scan results by clicking on your data source.
8. In addition, you can review any findings from the **Findings Page**.
2. Select the **GitHub** option.
3. Select the **GitHub Radar Connection** to use and configure which repositories you would like to scan. Then click **Next**.
* **GitHub Radar Connection** - the connection that has access to the repositories you want to scan.
* **Scan Repositories** - select which repositories you would like to scan.
* **All Repositories** - Infisical will scan all repositories associated with your connection.
* **Select Repositories** - Infisical will scan the selected repositories.
* **Auto-Scan Enabled** - whether Infisical should automatically perform a scan when a push is made to configured repositories.
4. Give your data source a name and description (optional). Then click **Next**.
* **Name** - the name of the data source. Must be slug-friendly.
* **Description** (optional) - a description of this data source.
5. Review your data source, then click **Create Data Source**.
6. Your **GitHub Data Source** is now available and will begin a full scan if **Auto-Scan** is enabled.
7. You can view repositories and scan results by clicking on your data source.
8. In addition, you can review any findings from the **Findings Page**.
2. Select the **GitLab** option.
3. Configure which workspace and repositories you would like to scan. Then click **Next**.
* **GitLab Connection** - the connection that has access to the repositories you want to scan.
* **Scope** - the GitLab scope to scan secrets in.
* **Project** - scan an individual GitLab project.
* **Group** - scan one or more projects belonging to a GitLab group.
* **Scan Repositories** - when using **Group Scope**, select which repositories you would like to scan.
* **All Repositories** - Infisical will scan all repositories associated with your connection.
* **Select Repositories** - Infisical will scan the selected repositories.
* **Auto-Scan Enabled** - whether Infisical should automatically perform a scan when a push is made to configured repositories.
4. Give your data source a name and description (optional). Then click **Next**.
* **Name** - the name of the data source. Must be slug-friendly.
* **Description** (optional) - a description of this data source.
5. Review your data source, then click **Create Data Source**.
6. Your **GitLab Data Source** is now available and will begin a full scan if **Auto-Scan** is enabled.
7. You can view repositories and scan results by clicking on your data source.
8. In addition, you can review any findings from the **Findings Page**.
### Resources
Resources are the atomic, scannable units, such as a repository, that can be monitored for secret exposure. Resources are added automatically when a data source is scanned and updated when scanning events are triggered, such as when a user pushes changes to GitHub.
Each resource maintains its own scanning history and status, allowing for granular monitoring and management of secret scanning across your organization.
### Scans
Scans can be initiated in two ways:
1. **Full Scan** - Manually triggered scan that comprehensively checks either all resources associated with a data source or a single selected resource.
2. **Diff Scan** - Automatically executed when **Auto-Scan** is enabled on a data source. This scan type specifically focuses on updates to existing resources.
All scan activities can be monitored in real-time through the Infisical UI, which displays:
* Current scan status
* Timestamp of the scan
* Resource(s) being scanned
* Detection results (whether any secrets were found)
### Findings
Findings are automatically generated when secret leaks are detected during scanning operations. Each finding contains comprehensive information including:
* The specific scanning rule that identified the leak
* File location and line number where the secret was found
* Resource-specific details (e.g., commit hash and author for Git repositories)
Findings are initially marked as **Unresolved** and can be updated to one of the following statuses with additional remarks:
* **Resolved** - The issue has been addressed
* **False Positive** - The detection was incorrect
* **Ignore** - The finding can be safely disregarded
These status options help teams effectively track and manage the lifecycle of detected secret leaks.
### Configuration
You can configure custom scanning rules and exceptions by updating your project's scanning configuration via the UI or API.
The configuration options allow you to:
* Define custom scanning patterns and rules
* Set up ignore patterns to reduce false positives
* Specify file path exclusions
* Configure entropy thresholds for secret detection
* Add allowlists for known safe patterns
For detailed configuration options, expand the example configuration below.
## Ignoring Known Secrets
If you're intentionally committing a test secret that the secret scanner might flag, you can instruct Infisical to overlook that secret with the methods listed below.
### infisical-scan:ignore
To ignore a secret contained in line of code, simply add `infisical-scan:ignore ` at the end of the line as comment in the given programming.
```js example.js theme={"dark"}
function helloWorld() {
console.log("8dyfuiRyq=vVc3RRr_edRk-fK__JItpZ"); // infisical-scan:ignore
}
```
### .infisicalignore
An alternative method to exclude specific findings involves creating a .infisicalignore file at your repository's root.
You can then add the fingerprints of the findings you wish to exclude. The [Infisical scan](/cli/scanning-overview) report provides a unique Fingerprint for each secret found.
By incorporating these Fingerprints into the .infisicalignore file, Infisical will skip the corresponding secret findings in subsequent scans.
```.ignore .infisicalignore theme={"dark"}
bea0ff6e05a4de73a5db625d4ae181a015b50855:frontend/components/utilities/attemptLogin.js:stripe-access-token:147
bea0ff6e05a4de73a5db625d4ae181a015b50855:backend/src/json/integrations.json:generic-api-key:5
1961b92340e5d2613acae528b886c842427ce5d0:frontend/components/utilities/attemptLogin.js:stripe-access-token:148
```
# Secret Sharing
Source: https://infisical.com/docs/documentation/platform/secret-sharing
Learn how to share time & view-count bound secrets securely with anyone on the internet.
Developers frequently need to share secrets with team members, contractors, or other third parties, which can be risky due to potential leaks or misuse.
Infisical offers a secure solution for sharing secrets over the internet in a time and view-count bound manner. It is possible to share secrets without signing up via [share.infisical.com](https://share.infisical.com) or via Infisical Dashboard (which has more advanced functionality).
## Sharing a Secret
* **Name (optional):** A friendly name for the shared secret.
* **Your Secret:** The secret content.
* **Password (optional):** A password which will be required when viewing the secret.
* **Limit access to people within organization:** Only lets people within your organization view the secret. Enabling this feature requires secret viewers to log into Infisical.
* **Expires In:** The time it'll take for the secret to expire.
* **Max Views:** How many times the secret can be viewed before it's destroyed.
* **Authorized Emails (optional):** Emails which are authorized to view this secret. Enabling this feature requires secret viewers to log into Infisical. Each email will receive the shared secret link in their inbox after creation.
## FAQ
The secret versioning functionality is heavily connected to [Point-in-time Recovery](/documentation/platform/pit-recovery) of secrets in Infisical.
## Secrets Overview
The **Secrets Overview** page captures a birds-eye-view of secrets and [folders](/documentation/platform/folder) across environments.
This is useful for comparing secrets, identifying if anything is missing, and making quick changes.
## Secrets Dashboard
The **Secrets Dashboard** page appears when you press to manage the secrets of a specific environment.
### Secrets
To add a secret, press **Add Secret** button at the top of the dashboard.
For a new project, it can be convenient to populate the dashboard by dropping a `.env` file into the provided pane as shown below:
To delete a secret, hover over it and press the **X** button that appears on the right side.
To delete multiple secrets at once, hover over and select the secrets you'd like to delete
and press the **Delete** button that appears at the top.
### Search
To search for specific secrets by their key name, you can use the search bar.
To assist you with finding secrets, you can also group them by similar prefixes and filter them by tags (if applicable).
### Hide/Un-hide
To view/hide all secrets at once, toggle the hide or un-hide button.
### Download as .env
To download/export secrets back into a `.env` file, press the download button.
### Tags
To better organize similar secrets, hover over them and label them with a tag.
### Comments
To provide more context about a given secret, especially for your team, hover over it and press the comment button.
### Personal overrides
Infisical employs the concept of **shared** and **personal** secrets to address the need
for common and custom secret values, or branching, amongst members of a team during software development.
To provide a helpful analogy: A shared value is to a `main` branch as a personal value is to a custom branch.
Consider:
* A team with users A, B, user C.
* A project with an environment containing a shared secret called D with the value E.
Suppose user A overrides the value of secret D with the value F.
Then:
* If user A fetches the secret D back, they get the value F.
* If users B and C fetch the secret D back, they both get the value E.
### Drawer
To view the full details of each secret, you can hover over it and press on the ellipses button.
This opens up a side-drawer:
# SSH Certificates
Source: https://infisical.com/docs/documentation/platform/ssh/concepts/ssh-certificates
Learn what SSH certificates are, why they're useful, and how they enable secure, scalable infrastructure access.
SSH access is ubiquitous — It's how engineers, scripts, and platforms across the world remotely administer Linux systems. That said, as teams and systems grow, managing access with static SSH keys becomes brittle and issues like key sprawl, unclear boundaries, and poor revocation hygiene start to emerge.
*SSH certificates* offer an alternative approach to securing and managing access at scale.
## What is an SSH Certificate?
An *SSH certificate* is a short-lived, signed credential that proves a user or host’s identity. Unlike static SSH keys, which are distributed and managed manually, SSH certificates rely on a centralized certificate authority (CA) to vouch for identities.
There are two types of SSH certificates:
* User certificates: Issued to users to authenticate with remote hosts
* Host certificates: Issued to hosts so clients can verify they're trusted
Because certificates are time-bound and centrally managed, they’re easier to audit, revoke, and scale across infrastructure.
## SSH with Infisical
Infisical SSH gives you a secure, scalable way to manage infrastructure access using SSH certificates — without the overhead of running your own certificate authority, wiring trust across hosts, or building issuance workflows from scratch.
It replaces long-lived SSH keys with short-lived, identity-bound certificates and handles all the moving parts for you: operating CAs, configuring trust between users and hosts, and issuing certificates on demand. With Infisical SSH, you can register a host with [`infisical ssh add-host`](/cli/commands/ssh#infisical-ssh-add-host), then connect with [`infisical ssh connect`](/cli/commands/ssh#infisical-ssh-connect) — that’s all it takes.
The result is centralized, auditable SSH access that’s easy to use and built to scale with your infrastructure.
# Host Groups
Source: https://infisical.com/docs/documentation/platform/ssh/host-groups
Learn how to organize SSH hosts into groups and manage access policies at scale.
## Concept
Infisical SSH lets you configure host groups to organize and manage multiple SSH hosts with shared access configuration.
These host groups can be created based on environments (`development`, `staging`, `production`), geographical regions (`us-east`, `eu-west`, `ap-northeast`), or functions (`web-servers`, `database-servers`, `worker-nodes`) to streamline access management across your infrastructure.
Using a host group, you can define login mappings at the group level and have them be applied to all hosts assigned to that group. For example, you can specify that `john@example.com` can login as `ubuntu` on all hosts assigned to the `production` host group.
## Workflow
The typical workflow for using Infisical SSH with host groups consists of the following steps:
1. The administrator creates host groups based on logical groupings (environments, regions, functions, etc.).
2. The administrator configures login mappings at the host group level to define access policies.
3. The administrator registers remote hosts with Infisical using the Infisical CLI via the `infisical ssh add-host` command and assigns them to appropriate host groups either using the `--host-group` flag or by adding them to the host group via UI.
4. User(s) access the remote hosts using the Infisical CLI via the `infisical ssh connect` command, with access determined by the login mappings defined at both host and host group levels.
## Admin Guide for Configuring Host Groups
In the following steps, we'll walk through how to create and configure Host Groups in Infisical SSH, and how to add hosts to these groups.
1.3. Click **Add** to create the host group.
4.2. On the registered host in the **Hosts** tab, click **Edit SSH Host** and add a login mapping for the user(s) you added in step 4.1.
The login mapping dictates what user(s) will be allowed access to the remote host and under a specific login user; in the allowed principals,
you should select user(s) part of the Infisical SSH project that will be allowed to login to the remote host as the login user.
For instance, if you add a mapping with the login user `ec2-user` to some users John and Alice in Infisical, then they will be allowed to login to the remote host as `ec2-user` which is a system user that
exists on the remote host.
1.2. In the Application URIs section, set the **Application Login URI** and **Allowed Web Origins** fields to `https://app.infisical.com` and the **Allowed Callback URL** field to `https://app.infisical.com/api/v1/sso/oidc/callback`.
2.2. In the advanced settings (bottom-most section), retrieve the **OpenID Configuration URL** from the Endpoints tab.
Keep these values handy as we will need them in the next steps.
3.2. For configuration type, select **Discovery URL**. Then, set **Discovery Document URL**, **JWT Signature Algorithm**, **Client ID**, and **Client Secret** from step 2.1 and 2.2.
Next, note the **Application Callback URL** and **Audience** to use when configuring the Auth0 SAML application.
Select **Regular Web Application** and press **Create**.
2.2. In the Application head to Settings > Application URIs and add the **Application Callback URL** from step 1 into the **Allowed Callback URLs** field.
2.3. In the Application head to Addons > SAML2 Web App and copy the **Issuer**, **Identity Provider Login URL**, and **Identity Provider Certificate** from the **Usage** tab.
2.4. Back in Infisical, set **Issuer**, **Identity Provider Login URL**, and **Certificate** to the corresponding items from step 2.3.
2.5. Back in Auth0, in the **Settings** tab, set the **Application Callback URL** to the **Application Callback URL** from step 1
and update the **Settings** field with the JSON under the picture below (replacing `
```json theme={"dark"}
{
"audience": "
Next, copy the **Reply URL (Assertion Consumer Service URL)** and **Identifier (Entity ID)** to use when configuring the Azure SAML application.
On the next screen, press the **+ Create your own application** button.
Give the application a unique name like Infisical; choose the "Integrate any other application you don't find in the gallery (Non-gallery)"
option and hit the **Create** button.
On the application overview screen, select **Single sign-on** from the left sidebar. From there, select the **SAML** single sign-on method.
Next, select **Edit** in the **Basic SAML Configuration** section and add/set the **Identifier (Entity ID)** to **Entity ID** and add/set the **Reply URL (Assertion Consumer Service URL)** to **ACS URL** from step 1.
Back in the **Set up Single Sign-On with SAML** screen, select **Edit** in the **SAML Certificates** section and set the **Signing Option** field to **Sign SAML response and assertion**.
In the **Properties** screen, copy the **Application ID** to use when finishing configuring Azure SAML in Infisical.
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.
2.2. You can configure OIDC either through the Discovery URL (Recommended) or by inputting custom endpoints.
To configure OIDC via Discovery URL, set the **Configuration Type** field to **Discovery URL** and fill out the **Discovery Document URL** field.
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.
2.4. Optionally, you can define a whitelist of allowed email domains.
Finally, fill out the **Client ID** and **Client Secret** fields and press **Update** to complete the required configuration.
Create the OAuth application. As part of the form, set the **Homepage URL** to your self-hosted domain `https://your-domain.com`
and the **Authorization callback URL** to `https://your-domain.com/api/v1/sso/github`.
Back in your Infisical instance, make sure to set the following environment variables:
* `CLIENT_ID_GITHUB_LOGIN`: The **Client ID** of your GitHub OAuth application.
* `CLIENT_SECRET_GITHUB_LOGIN`: The **Client Secret** of your GitHub OAuth application.
* `AUTH_SECRET`: A secret key used for signing and verifying JWT. This can be a random 32-byte base64 string generated with `openssl rand -base64 32`.
* `SITE_URL`: The URL of your self-hosted instance of Infisical - should be an absolute URL including the protocol (e.g. [https://app.infisical.com](https://app.infisical.com))
Once added, restart your Infisical instance and log in with GitHub.
Create the application. As part of the form, set the **Redirect URI** to `https://your-domain.com/api/v1/sso/gitlab`.
Note that only `read_user` is required as part of the **Scopes** configuration.
Back in your Infisical instance, make sure to set the following environment variables:
* `CLIENT_ID_GITLAB_LOGIN`: The **Client ID** of your GitLab application.
* `CLIENT_SECRET_GITLAB_LOGIN`: The **Secret** of your GitLab application.
* (optional) `URL_GITLAB_LOGIN`: The URL of your self-hosted instance of GitLab where the OAuth application is registered. If no URL is passed in, this will default to `https://gitlab.com`.
* `AUTH_SECRET`: A secret key used for signing and verifying JWT. This can be a random 32-byte base64 string generated with `openssl rand -base64 32`.
* `SITE_URL`: The URL of your self-hosted instance of Infisical - should be an absolute URL including the protocol (e.g. [https://app.infisical.com](https://app.infisical.com))
Once added, restart your Infisical instance and log in with GitLab.
Create the application. As part of the form, add to **Authorized redirect URIs**: `https://your-domain.com/api/v1/sso/google`.
Back in your Infisical instance, make sure to set the following environment variables:
* `CLIENT_ID_GOOGLE_LOGIN`: The **Client ID** of your GCP OAuth2 application.
* `CLIENT_SECRET_GOOGLE_LOGIN`: The **Client Secret** of your GCP OAuth2 application.
* `AUTH_SECRET`: A secret key used for signing and verifying JWT. This can be a random 32-byte base64 string generated with `openssl rand -base64 32`.
* `SITE_URL`: The URL of your self-hosted instance of Infisical - should be an absolute URL including the protocol (e.g. [https://app.infisical.com](https://app.infisical.com))
Once added, restart your Infisical instance and log in with Google
Next, note the **ACS URL** and **SP Entity ID** to use when configuring the Google SAML application.
2.2. In the **App details** tab, give the application a unique name like Infisical.
2.3. In the **Google Identity Provider details** tab, copy the **SSO URL**, **Entity ID** and **Certificate**.
2.4. Back in Infisical, set **SSO URL** and **Certificate** to the corresponding items from step 2.3.
2.5. Back in the Google Admin console, in the **Service provider details** tab, set the **ACS URL** and **Entity ID** to the corresponding items from step 1.
Also, check the **Signed response** checkbox.
2.6. In the **Attribute mapping** tab, configure the following map:
* **First name** -> **firstName**
* **Last name** -> **lastName**
* **Primary email** -> **email**
To assign everyone in your organization to the application, click **On for everyone** or **Off for everyone** and then click **Save**.
You can also assign an organizational unit or set of users to an application; you can learn more about that [here](https://support.google.com/a/answer/6087519?hl=en#add_custom_saml\&turn_on\&verify_sso&\&zippy=%2Cstep-add-the-custom-saml-app%2Cstep-turn-on-your-saml-app%2Cstep-verify-that-sso-is-working-with-your-custom-app).
Next, copy the **ACS URL** and **SP Entity ID** to use when configuring the JumpCloud SAML application.
2.2. Next, select **Custom SAML App** to open up the **New SSO** dialog.
2.3. In the **General Info** tab, give the application a unique name like Infisical.
2.4. In the **SSO** tab, set the **SP Entity ID** and **ACS URL** from step 1; set the **IdP Entity ID** to the same value as the **SP Entity ID**.
2.5. On the same tab, check the **Sign Assertion** checkbox and fill the **IDP URL** to something unique.
Copy the **IDP URL** to use when finishing configuring the JumpCloud SAML in Infisical.
2.6. On the same tab, in the **Attributes** section, configure the following map:
* `email -> email`
* `firstName -> firstname`
* `lastName -> lastname`
Finally press activate to create the SAML application.
2.7. Next, select the newly created SAML application and select **Download certificate** under the **IDP Certificate Valid** dropdown
1.2. Select the **Client Scopes** tab.
1.3. Next, select the dedicated scope for your Infisical client.
1.4. Click on the **Add mapper** button, and select the **By configuration** option.
1.5. Select the **Group Membership** option.
1.6. Give your mapper a name and ensure the following properties are set to the following before saving:
* **Token Claim Name** is set to `groups`
* **Full group path** is disabled
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 Keycloak groups.
1.3. Next, in the Capability Config step, ensure that **Client Authentication** is set to On and that **Standard flow** is enabled in the Authentication flow section.
1.4. In the Login Settings step, set the following values:
* Root URL: `https://app.infisical.com`.
* Home URL: `https://app.infisical.com`.
* Valid Redirect URIs: `https://app.infisical.com/api/v1/sso/oidc/callback`.
* Web origins: `https://app.infisical.com`.
1.6. Next, click **Add predefined mapper**.
1.7. Select the **email**, **given name**, **family name** attributes and click **Add**.
Once you've completed the above steps, the list of mappers should look like the following:
2.2. From the Clients page, navigate to the Credential tab and copy the **Client Secret** to be used in the next steps.
3.2. For configuration type, select Discovery URL. Then, set the appropriate values for **Discovery Document URL**, **JWT Signature Algorithm**, **Client ID**, and **Client Secret**.
Next, copy the **Valid redirect URI** and **SP Entity ID** to use when configuring the Keycloak SAML application.
2.2. Once you've created the client, under its **Settings** tab, make sure to set the following values:
* Under **SAML Capabilities**:
* Name ID format: email (or username).
* Force name ID format: On.
* Force POST binding: On.
* Include AuthnStatement: On.
* Under **Signature and Encryption**:
* Sign documents: On.
* Sign assertions: On.
* Signature algorithm: RSA\_SHA256.
2.3. Next, navigate to the **Client scopes** tab select the client's dedicated scope.
Next click **Add predefined mapper**.
Select the **X500 email**, **X500 givenName**, and **X500 surname** attributes and click **Add**.
Now click on the **X500 email** mapper and set the **SAML Attribute Name** field to **email**.
Repeat the same for **X500 givenName** and **X500 surname** mappers, setting the **SAML Attribute Name** field to **firstName** and **lastName** respectively.
Next, back in the client scope's **Mappers**, click **Add mapper** and select **by configuration**.
Select **User Property**.
Set the the **Name** field to **Username**, the **Property** field to **username**, and the **SAML Attribute Name** to **username**.
Repeat the same for the `id` attribute, setting the **Name** field to **ID**, the **Property** field to **id**, and the **SAML Attribute Name** to **id**.
Once you've completed the above steps, the list of mappers should look like this:
Also, in the **Keys** tab, locate the RS256 key and copy the certificate to use when finishing configuring Keycloak SAML in Infisical.
Next, copy the **Single sign-on URL** and **Audience URI (SP Entity ID)** to use when configuring the Okta SAML 2.0 application.
In the Create a New Application Integration dialog, select the **SAML 2.0** radio button:
On the General Settings screen, give the application a unique name like Infisical and select **Next**.
On the Configure SAML screen, set the **Single sign-on URL** and **Audience URI (SP Entity ID)** from step 1.
Once configured, select **Next** to proceed to the Feedback screen and select **Finish**.
Copy the **Identity Provider Single Sign-On URL**, the **Identity Provider Issuer**, and the **X.509 Certificate** to use when finishing configuring Okta SAML in Infisical.
At this point, you have configured everything you need within the context of the Okta Admin Portal.
1.2. Enable the application by pressing the "Enable" toggle.
1.3. In the Application "Configuration" tab, press the "Edit" pencil icon to configure the application callback URI.
1.4 Set the Redirect URL to `https://app.infisical.com/api/v1/sso/oidc/callback` and press the "Save" button.
1.6 Map the following attributes:
* `email` -> `Email Address`
* `name` -> `Username`
Once done, press the "Save" button.
2.2. Still in the "Overview" tab, scroll down to the Connection Details section and retrieve the **OIDC Discovery Endpoint**.
Keep these values handy as we will need them in the next steps.
3.2. For configuration type, select **Discovery URL**. Then, set **Discovery Document URL**, **Client ID**, and **Client Secret** from step 2.1 and 2.2.
Now input any token configuration details such as which environment(s) and path(s) you'd like to provision
the token access to. Here's some guidance for each field:
* Name: A friendly name for the token.
* Scopes: The environment(s) and path(s) the token should have access to.
* Permissions: You can indicate whether or not the token should have `read/write` access to the paths.
Also, note that Infisical supports [glob patterns](https://www.malikbrowne.com/blog/a-beginners-guide-glob-patterns/) when defining access scopes to path(s).
* Expiration: The time when this token should be rendered inactive.
In the above screenshot, you can see that we are creating a token token with `read` access to all subfolders at any depth
of the `/common` path within the development environment of the project; the token expires in 6 months and can be used from any IP address.
To create a webhook for a particular project, go to `Project Settings > Webhooks`.
Infisical supports two webhook types - General and Slack. If you need to integrate with Slack, use the Slack type with an [Incoming Webhook](https://api.slack.com/messaging/webhooks). When creating a webhook, you can specify an environment and folder path to trigger only specific integrations.
## Secret Key Verification
A secret key is a way for users to verify that a webhook request was sent by Infisical and is intended for the correct integration.
When you provide a secret key, Infisical will sign the payload of the webhook request using the key and attach a header called `x-infisical-signature` to the request with a payload.
The header will be in the format `t=
Once the app has been submitted, your Microsoft Teams tenant admin will need to approve the app in the [Microsoft Teams Admin Center](https://admin.teams.microsoft.com/policies/manage-apps).
Navigate to **Apps** > **Built for your org**, select the "Infisical" app, and press the "Add" button to select the teams and channels you wish to add the app to.
Select the Microsoft Teams integration you wish to configure, and press the "Configure" button.
Here you will be prompted to enter an alias, tenant ID, and an optional description for your workflow integration.
The tenant ID is the ID of the Microsoft 365 / Azure AD tenant that you installed the Infisical Microsoft Teams app in, in the previous steps.
Press the "Create Microsoft Teams Integration" button, and you'll be navigated to the Azure AD consent page.
Select the "Microsoft Teams" option from the list of available workflow integrations.
After clicking the "Create a new bot" button, you'll be navigated to the Teams Developer Portal for bot management. Press the "New bot" button, and enter the name of the bot.
Please keep in mind that the name of the bot can only contain alphanumeric characters, dashes, and underscores.
**Create a new client secret**
Create a new client secret within the app registration. Navigate to the "Certificates & Secrets" section of the app registration, and press the "New client secret" button.
Enter the values you saved from the earlier steps into the respective fields.
* **Application (Client) ID**: The Client ID of the App Registration from the previous steps.
* **Client Secret**: The Client Secret of the App Registration from the previous steps.
* **Microsoft Teams App ID**: The App ID of the Microsoft Teams App from the previous steps.
Once completed, press the "Save" button to save your changes.
Once the app has been submitted, your Microsoft Teams tenant admin will need to approve the app in the [Microsoft Teams Admin Center](https://admin.teams.microsoft.com/policies/manage-apps).
Navigate to **Apps** > **Built for your org**, select the "Infisical" app, and press the "Add" button to select the teams and channels you wish to add the app to.
Select the Microsoft Teams integration you wish to configure, and press the "Configure" button.
Here you will be prompted to enter an alias, tenant ID, and an optional description for your workflow integration.
The tenant ID is the ID of the Microsoft 365 / Azure AD tenant that you installed the Infisical Microsoft Teams app in, in the previous steps.
Press the "Create Microsoft Teams Integration" button, and you'll be navigated to the Azure AD consent page.
Select the "Microsoft Teams" option from the list of available workflow integrations.
Give your Slack integration a descriptive alias. You will use this to select the Slack integration for your project.
Press **Connect Slack**. This opens up the Slack app installation flow. Select the Slack workspace you want to install the custom Slack app to and press **Install Infisical**.
This completes the workflow integration creation flow. The projects in your organization can now use this Slack integration to send real-time updates to your Slack workspace.
The configuration values of your custom Slack app will be pre-filled for you. You can view or edit the app manifest by clicking **Edit Configurations**.
Once everything's confirmed, press Create.
Complete the admin setup by pressing **Save**.
Give your Slack integration a descriptive alias. You will use this to select the Slack integration for your project.
Press **Connect Slack**. This opens up the Slack app installation flow. Select the Slack workspace you want to install the custom Slack app to and press **Install Infisical**.
Your Slack bot will then be added to your selected Slack workspace. This completes the workflow integration creation flow. Your projects in the organization can now use this Slack integration to send real-time updates to your Slack workspace.
You can now view the private channels in the Slack channel selection fields!
### Access Request Updated
This event is triggered when an existing access approval request is modified or updated. This helps approvers stay informed about changes to pending requests.
**When it's triggered:**
* An access approval request is edited by the requester or another authorized user
* Changes are made to permissions, temporary range, or notes
* The notification is sent to the configured access request channels
**Notification includes:**
* Original requester's information
* Editor's full name and email (who made the update)
* Updated permissions
* Updated secret path and environment
* Editor's note explaining the changes
* Direct link to review the updated request
{}
setSearchTerm(e.target.value)} />
{}
{}
{}
{filteredConnections.length > 0 ?
}
;
};
{categories.map(category => )}
{filteredConnections.length} app connection {filteredConnections.length !== 1 ? "s" : ""} found {selectedCategory !== "All" && ` in ${selectedCategory}`} {searchTerm && ` for "${searchTerm}"`}
{filteredConnections.map((connection, index) =>
)}
: {connection.name}
{connection.category}{connection.description}
No app connections found matching your criteria
{searchTerm &&Try adjusting your search terms or filters
}
2. Select the **Auth0 Connection** option.
3. Select the **Client Credentials** method option and provide the details obtained from the previous section and press **Connect to Auth0**.
4. Your **Auth0 Connection** is now available for use.
2. Select **AWS Account** as the **Trusted Entity Type**.
3. Select **Another AWS Account** and provide the appropriate Infisical AWS Account ID: use **381492033652** for the **US region**, and **345594589636** for the **EU region**. This restricts the role to be assumed only by Infisical. If self-hosting, provide your AWS account number instead.
Depending on your use case, add one or more of the following policies to your IAM Role:
```json theme={"dark"}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSecretsManagerAccess",
"Effect": "Allow",
"Action": [
"secretsmanager:ListSecrets",
"secretsmanager:GetSecretValue",
"secretsmanager:BatchGetSecretValue",
"secretsmanager:CreateSecret",
"secretsmanager:UpdateSecret",
"secretsmanager:DeleteSecret",
"secretsmanager:DescribeSecret",
"secretsmanager:TagResource",
"secretsmanager:UntagResource",
"kms:ListAliases", // if you need to specify the KMS key
"kms:Encrypt", // if you need to specify the KMS key
"kms:Decrypt", // if you need to specify the KMS key
"kms:DescribeKey" // if you need to specify the KMS key
],
"Resource": "*"
}
]
}
```
```json theme={"dark"}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSSMAccess",
"Effect": "Allow",
"Action": [
"ssm:PutParameter",
"ssm:GetParameters",
"ssm:GetParametersByPath",
"ssm:DescribeParameters",
"ssm:DeleteParameters",
"ssm:ListTagsForResource", // if you need to add tags to secrets
"ssm:AddTagsToResource", // if you need to add tags to secrets
"ssm:RemoveTagsFromResource", // if you need to add tags to secrets
"kms:ListAliases", // if you need to specify the KMS key
"kms:Encrypt", // if you need to specify the KMS key
"kms:Decrypt", // if you need to specify the KMS key
"kms:DescribeKey" // if you need to specify the KMS key
],
"Resource": "*"
}
]
}
```
```json theme={"dark"}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:ListAccessKeys",
"iam:CreateAccessKey",
"iam:UpdateAccessKey",
"iam:DeleteAccessKey",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
2. Select the **AWS Connection** option.
3. Select the **Assume Role** method option and provide the **AWS IAM Role ARN** obtained from the previous step and press **Connect to AWS**.
4. Your **AWS Connection** is now available for use.
Depending on your use case, add one or more of the following policies to your user:
```json theme={"dark"}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSecretsManagerAccess",
"Effect": "Allow",
"Action": [
"secretsmanager:ListSecrets",
"secretsmanager:GetSecretValue",
"secretsmanager:BatchGetSecretValue",
"secretsmanager:CreateSecret",
"secretsmanager:UpdateSecret",
"secretsmanager:DeleteSecret",
"secretsmanager:DescribeSecret",
"secretsmanager:TagResource",
"secretsmanager:UntagResource",
"kms:ListAliases", // if you need to specify the KMS key
"kms:Encrypt", // if you need to specify the KMS key
"kms:Decrypt", // if you need to specify the KMS key
"kms:DescribeKey" // if you need to specify the KMS key
],
"Resource": "*"
}
]
}
```
```json theme={"dark"}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSSMAccess",
"Effect": "Allow",
"Action": [
"ssm:PutParameter",
"ssm:GetParameters",
"ssm:GetParametersByPath",
"ssm:DescribeParameters",
"ssm:DeleteParameters",
"ssm:ListTagsForResource", // if you need to add tags to secrets
"ssm:AddTagsToResource", // if you need to add tags to secrets
"ssm:RemoveTagsFromResource", // if you need to add tags to secrets
"kms:ListAliases", // if you need to specify the KMS key
"kms:Encrypt", // if you need to specify the KMS key
"kms:Decrypt", // if you need to specify the KMS key
"kms:DescribeKey" // if you need to specify the KMS key
],
"Resource": "*"
}
]
}
```
```json theme={"dark"}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:ListAccessKeys",
"iam:CreateAccessKey",
"iam:UpdateAccessKey",
"iam:DeleteAccessKey",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
2. Select the **AWS Connection** option.
3. Select the **Access Key** method option and provide the **Access Key ID** and **Secret Key** obtained from the previous step and press **Connect to AWS**.
4. Your **AWS Connection** is now available for use.
Create the application. As part of the form, set the **Redirect URI** to `https://your-domain.com/organization/app-connections/azure/oauth/callback`.
Back in your Infisical instance, add two new environment variables for the credentials of your Azure application.
* `INF_APP_CONNECTION_AZURE_APP_CONFIGURATION_CLIENT_ID`: The **Application (Client) ID** of your Azure application.
* `INF_APP_CONNECTION_AZURE_APP_CONFIGURATION_CLIENT_SECRET`: The **Client Secret** of your Azure application.
Once added, restart your Infisical instance and use the Azure App Configuration connection.
Create the application. As part of the form, set the **Redirect URI** to `https://your-domain.com/organization/app-connections/azure/oauth/callback`.
Back in your Infisical instance, add two new environment variables for the credentials of your Azure application.
* `INF_APP_CONNECTION_AZURE_CLIENT_SECRETS_CLIENT_ID`: The **Application (Client) ID** of your Azure application.
* `INF_APP_CONNECTION_AZURE_CLIENT_SECRETS_CLIENT_SECRET`: The **Client Secret** of your Azure application.
Once added, restart your Infisical instance and use the Azure Client Secrets connection.
Create the application. As part of the form, set the **Redirect URI** to `https://your-domain.com/organization/app-connections/azure/oauth/callback`.
Back in your Infisical instance, add two new environment variables for the credentials of your Azure application.
* `INF_APP_CONNECTION_AZURE_DEVOPS_CLIENT_ID`: The **Application (Client) ID** of your Azure application.
* `INF_APP_CONNECTION_AZURE_DEVOPS_CLIENT_SECRET`: The **Client Secret** of your Azure application.
Once added, restart your Infisical instance and use the Azure Client Secrets connection.
Create the application. As part of the form, set the **Redirect URI** to `https://your-domain.com/organization/app-connections/azure/oauth/callback`.
Back in your Infisical instance, add two new environment variables for the credentials of your Azure application.
* `INF_APP_CONNECTION_AZURE_KEY_VAULT_CLIENT_ID`: The **Application (Client) ID** of your Azure application.
* `INF_APP_CONNECTION_AZURE_KEY_VAULT_CLIENT_SECRET`: The **Client Secret** of your Azure application.
Once added, restart your Infisical instance and use the Azure Key Vault connection.
**Private Key:** Copy the content of the private key file.
**User Name(1):** The user name of the chef user.
**Server URL(2):** The server url of the chef server.
**Organization Name(3):** The organization name of the chef server.
Click **API Tokens > Create Token** to generate a new API token.
**Required Permissions:**
* **Account** - **Cloudflare Pages** - **Edit**
* **Account** - **Account Settings** - **Read**
Add these permissions to your API token and click **Continue to summary**, then **Create Token** to generate your API token.
**Required Permissions:**
* **Account** - **Workers Scripts** - **Edit**
* **Account** - **Account Settings** - **Read**
Add these permissions to your API token and click **Continue to summary**, then **Create Token** to generate your API token.
**Required Permissions:**
* **Account** - **Account Settings** - **Read**
* **Zone** - **DNS** - **Edit**
Add these permissions to your API token and click **Continue to summary**, then **Create Token** to generate your API token.
Save your Account ID for use in the next step.
If your **API Key** and **Secret Key** are already available, proceed to step 2.
Otherwise, check the **Generate New API Credentials** then click the **Save** button to generate the new API credentials.
Press "DONE" after creating the service account.
Give the application a name, a homepage URL (your self-hosted domain i.e. `https://your-domain.com`), and a callback URL (i.e. `https://your-domain.com/organization/app-connections/github/oauth/callback`).
Enable request user authorization during app installation.
Disable webhook by unchecking the Active checkbox.
Set the repository permissions as follows: Metadata: Read-only, Secrets: Read and write, Environments: Read and write, Actions: Read.
Similarly, set the organization permissions as follows: Secrets: Read and write.
Create the Github application.
Generate a new **Private Key** for your Github application.
Obtain the necessary Github application credentials. This would be the application slug, client ID, app ID, client secret, and private key.
Back in your Infisical instance, you can configure the GitHub App credentials in one of two ways:
**Option 1: Server Admin Panel (Recommended)**
Navigate to the server admin panel > **Integrations** > **GitHub App** and enter the GitHub application credentials:
* **Client ID**: The Client ID of your GitHub application
* **Client Secret**: The Client Secret of your GitHub application
* **App Slug**: The Slug of your GitHub application (found in the URL)
* **App ID**: The App ID of your GitHub application
* **Private Key**: The Private Key of your GitHub application
**Option 2: Environment Variables**
Alternatively, you can add the new environment variables for the credentials of your GitHub application:
* `INF_APP_CONNECTION_GITHUB_APP_CLIENT_ID`: The **Client ID** of your GitHub application.
* `INF_APP_CONNECTION_GITHUB_APP_CLIENT_SECRET`: The **Client Secret** of your GitHub application.
* `INF_APP_CONNECTION_GITHUB_APP_SLUG`: The **Slug** of your GitHub application. This is the one found in the URL.
* `INF_APP_CONNECTION_GITHUB_APP_ID`: The **App ID** of your GitHub application.
* `INF_APP_CONNECTION_GITHUB_APP_PRIVATE_KEY`: The **Private Key** of your GitHub application.
Once configured, you can use the GitHub integration via app authentication. If you configured the credentials using environment variables, restart your Infisical instance for the changes to take effect. If you configured them through the server admin panel, allow approximately 5 minutes for the changes to propagate.
Create the OAuth application. As part of the form, set the **Homepage URL** to your self-hosted domain `https://your-domain.com`
and the **Authorization callback URL** to `https://your-domain.com/organization/app-connections/github/oauth/callback`.
Back in your Infisical instance, add two new environment variables for the credentials of your GitHub OAuth application:
* `INF_APP_CONNECTION_GITHUB_OAUTH_CLIENT_ID`: The **Client ID** of your GitHub OAuth application.
* `INF_APP_CONNECTION_GITHUB_OAUTH_CLIENT_SECRET`: The **Client Secret** of your GitHub OAuth application.
Once added, restart your Infisical instance and use the GitHub integration.
Click **Generate new token** to create the token.
Click **Generate token** to create the token.
Configure the following fields:
1. **Name** - give your app a name
2. **Homepage URL** - your self-hosted domain (i.e. `https://your-domain.com`)
3. **Callback URL** - the callback URL for your domain (i.e. `https://your-domain.com/organization/app-connections/github-radar/oauth/callback`)
4. **User Authorization** - enable request user authorization on app installation
Enable and configure the Webhook fields:
* **Webhook URL** - the webhook URL for your domain (i.e. `https://your-domain.com/secret-scanning/webhooks/github`)
* **Webhook Secret** - a strong, generated secret to verify webhook payloads
* **SSL Verification** - enable SSL verification
Set the following repository permissions:
* **Contents**: `Read-only`
* **Metadata**: `Read-only`
Subscribe to the following events:
* **Push**
Create the Github application.
Generate a new **Private Key** for your Github application.
Obtain the following credentials:
1. **Slug** - the slug of your application found in the URL
2. **App ID** - the ID of your application
3. **Client ID** - the client ID of your application
4. **Client Secret** - the client secret generated above
5. **Private Key** - the contents of the private key .pem file generated above
6. **Webhook Secret** - the secret generated in the previous step when configuring the webhook
Back in your Infisical instance, add the six new environment variables for the credentials of your GitHub Radar application:
* `INF_APP_CONNECTION_GITHUB_RADAR_APP_CLIENT_ID`: The **Client ID** of your GitHub application.
* `INF_APP_CONNECTION_GITHUB_RADAR_APP_CLIENT_SECRET`: The **Client Secret** of your GitHub application.
* `INF_APP_CONNECTION_GITHUB_RADAR_APP_SLUG`: The **Slug** of your GitHub application. This is the one found in the URL.
* `INF_APP_CONNECTION_GITHUB_RADAR_APP_ID`: The **App ID** of your GitHub application.
* `INF_APP_CONNECTION_GITHUB_RADAR_APP_PRIVATE_KEY`: The **Private Key** of your GitHub application.
* `INF_APP_CONNECTION_GITHUB_RADAR_APP_WEBHOOK_SECRET`: The **Webhook Secret** of your GitHub application.
Once added, restart your Infisical instance and use the GitHub integration via app authentication.
Create the application. As part of the form, set the **Redirect URI** to `https://your-domain.com/organization/app-connections/gitlab/oauth/callback`.
Depending on your use case, add one or more of the following scopes to your application:
Back in your Infisical instance, add two new environment variables for the credentials of your GitLab OAuth application:
* `INF_APP_CONNECTION_GITLAB_OAUTH_CLIENT_ID`: The **Application ID** of your GitLab OAuth application.
* `INF_APP_CONNECTION_GITLAB_OAUTH_CLIENT_SECRET`: The **Secret** of your GitLab OAuth application.
Once added, restart your Infisical instance and use the GitLab Connection.
Click **Create group access token** to create the token.
Click **Create group access token** to create the token.
Click **Connect** to establish the connection.
Create the API client. As part of the form, set the **OAuth callback URL** to `https://your-domain.com/organization/app-connections/heroku/oauth/callback`.
Back in your Infisical instance, add two new environment variables for the credentials of your Heroku API client:
* `INF_APP_CONNECTION_HEROKU_OAUTH_CLIENT_ID`: The **Client ID** of your Heroku API client.
* `INF_APP_CONNECTION_HEROKU_OAUTH_CLIENT_SECRET`: The **Client Secret** of your Heroku API client.
Once added, restart your Infisical instance and use the Heroku Connection.
Click **Connect** to establish the connection.
2. Select the **LDAP Connection** option.
3. Select the **Simple Bind** method option and provide the details obtained from the previous section and press **Connect to Provider**.
4. Your **LDAP Connection** is now available for use.
2. Select the **Microsoft SQL Server Connection** option.
3. Select the **Username & Password** method option and provide the details obtained from the previous section and press **Connect to Microsoft SQL Server**.
4. Your **Microsoft SQL Server Connection** is now available for use.
2. Select the **MySQL Connection** option.
3. Select the **Username & Password** method option and provide the details obtained from the previous section and press **Connect to MySQL**.
4. Your **MySQL Connection** is now available for use.
Click on **Create API role**.
Select all the projects you want this role to have access to, or leave this unchecked if you want to give access to all projects.
Add the **Projects** -> **Manage** -> **Read** permission.
Add the **Config & Secrets** -> **Secret Groups** -> **List**, **Update** and **Read Values** permissions.
Scroll to the bottom and save the API role.
Give a name to the API token and click the **Use role** button for the new API role you just created.
Click the **View API token** icon to view and copy your token.
2. Select the **OracleDB Connection** option.
3. Select the **Username & Password** method option and provide the details obtained from the previous section and press **Connect to OracleDB**.
4. Your **OracleDB Connection** is now available for use.
```mermaid theme={"dark"}
%%{init: {'flowchart': {'curve': 'linear'} } }%%
graph TD
A[AWS]
B[AWS Connection]
C[Project 1 Secret Sync]
D[Project 2 Secret Sync]
E[Project 3 Generate Dynamic Secret]
B --> A
C --> B
D --> B
E --> B
classDef default fill:#ffffff,stroke:#666,stroke-width:2px,rx:10px,color:black
classDef aws fill:#FFF2B2,stroke:#E6C34A,stroke-width:2px,color:black,rx:15px
classDef project fill:#E6F4FF,stroke:#0096D6,stroke-width:2px,color:black,rx:15px
classDef connection fill:#F4FFE6,stroke:#96D600,stroke-width:2px,color:black,rx:15px
class A aws
class B connection
class C,D,E project
```
## Workflow
App Connections require initial setup in both your third-party application and Infisical. Follow these steps to establish a secure connection:
2. Select the **PostgreSQL Connection** option.
3. Select the **Username & Password** method option and provide the details obtained from the previous section and press **Connect to PostgreSQL**.
4. Your **PostgreSQL Connection** is now available for use.
2. Add Connection
Click the **+ Add Connection** button and select the **TeamCity Connection** option from the available integrations.
3. Fill the TeamCity Connection Modal
Complete the TeamCity Connection form by entering:
* A descriptive name for the connection
* The Access Token you generated in steps 3-4
* The URL of your TeamCity instance
* An optional description for future reference
4. Connection Created
After clicking Create, your **TeamCity Connection** is established and ready to use with your Infisical project.
2. Select the **Terraform Cloud Connection** option from the connection options modal.
3. Fill out the Terraform Cloud Connection modal, here you will need to provide the API Token generated in the previous step.
4. Your **Terraform Cloud Connection** is now available for use.
2. Add Connection
Click the **+ Add Connection** button and select the **Vercel Connection** option from the available integrations.
3. Fill the Vercel Connection Modal
Complete the Vercel Connection form by entering:
* A descriptive name for the connection
* The API Token you generated in steps 3-4
* An optional description for future reference
4. Connection Created
After clicking Create, your **Vercel Connection** is established and ready to use with your Infisical project.
* **Name**: The name of the connection to be created. Must be slug-friendly.
* **Description**: An optional description to provide details about this connection.
* **Instance URL**: The URL of your Windmill instance. If you are not self-hosting Windmill you can leave this field blank.
* **Access Token**: The access token generated in the steps above.
1. In the Amplify console, choose App Settings, and then select Environment variables.
2. In the Environment variables section, select Manage variables.
3. Under the first Variable enter `INFISICAL_MACHINE_IDENTITY_CLIENT_ID`, and for the value, enter the client ID of the machine identity you created in the previous step.
4. Under the second Variable enter `INFISICAL_MACHINE_IDENTITY_CLIENT_SECRET`, and for the value, enter the client secret of the machine identity you created in the previous step.
5. Click save.
1. In the Amplify console, choose App Settings, and then select Environment variables.
2. In the Environment variables section, select Manage variables.
3. Under Variable, enter the key **INFISICAL\_TOKEN**. For the value, enter the generated service token from the previous step.
4. Click save.
1. Open your AWS Amplify App console.
2. Go to **Actions >> View App Settings**
3. The App ID will be the last part of the App ARN field after the slash.
## Infisical Authentication
Authenticating with Infisical is done through the use of [Machine Identities](https://infisical.com/docs/documentation/platform/identities/machine-identities).
Currently the Jenkins plugin only supports [Universal Auth](https://infisical.com/docs/documentation/platform/identities/universal-auth) for authentication. More methods will be added soon.
### How does Universal Auth work?
To use Universal Auth, you'll need to create a new Credential *(Infisical Universal Auth Credential)*. The credential should contain your Universal Auth client ID, and your Universal Auth client secret.
Please [read more here](https://infisical.com/docs/documentation/platform/identities/universal-auth) on how to setup a Machine Identity to use universal auth.
### Creating a Universal Auth credential
Creating a universal auth credential inside Jenkins is very straight forward.
Simply navigate to`Dashboard -> Manage Jenkins -> Credentials -> System -> Global credentials (unrestricted)`. Press the `Add Credentials` button and select `Infisical Universal Auth Credential` in the `Kind` field. The `ID` and `Description` field doesn't matter much in this case, as they won't be read anywhere. The description field will be displayed as the credential name during the plugin configuration.
## Plugin Usage
### Configuration
Configuration takes place on a job-level basis.
Inside your job, you simply tick the `Infisical Plugin` checkbox under "Build Environment". After enabling the plugin, you'll see a new section appear where you'll have to configure the plugin.
You'll be prompted with 4 options to fill:
* Infisical URL
* This defaults to [https://app.infisical.com](https://app.infisical.com). This field is only relevant if you're running a managed or self-hosted instance. If you are using Infisical Cloud, leave this as-is, otherwise enter the URL of your Infisical instance.
* Infisical Credential
* This is where you select your Infisical credential to use for authentication. In the step above [Creating a Universal Auth credential](#creating-a-universal-auth-credential), you can read on how to configure the credential. Simply select the credential you have created for this field.
* Infisical Project Slug
* This is the slug of the project you wish to fetch secrets from. You can find this in your project settings on Infisical by clicking "Copy project slug".
* Environment Slug
* This is the slug of the environment to fetch secrets from. In most cases it's either `dev`, `staging`, or `prod`. You can however create custom environments in Infisical. If you are using custom environments, you need to enter the slug of the custom environment you wish to fetch secrets from.
That's it! Now you're ready to select which secrets you want to fetch into Jenkins.
By clicking the `Add an Infisical secret` in the Jenkins UI like seen in the screenshot below.
You need to select which secrets that should be pulled into Jenkins.
You start by specifying a [folder path from Infisical](https://infisical.com/docs/documentation/platform/folder#comparing-folders). The root path is simply `/`. You also need to select wether or not you want to [include imports](https://infisical.com/docs/documentation/platform/secret-reference#secret-imports). Now you can add secrets the secret keys that you want to pull from Infisical into Jenkins. If you want to add multiple secrets, press the "Add key/value pair".
If you wish to pull secrets from multiple paths, you can press the "Add an Infisical secret" button at the bottom, and configure a new set of secrets to pull.
## Pipeline usage
### Generating pipeline block
Using the Infisical Plugin in a Jenkins pipeline is very straight forward. To generate a block to use the Infisical Plugin in a Pipeline, simply to go `{JENKINS_URL}/jenkins/job/{JOB_ID}/pipeline-syntax/`.
You can find a direct link on the Pipeline configuration page in the very bottom of the page, see image below.
On the Snippet Generator page, simply configure the Infisical Plugin like it's documented in the [Configuration documentation](#configuration) step.
Once you have filled out the configuration, press `Generate Pipeline Script`, and it will generate a block you can use in your pipeline.
### Using Infisical in a Pipeline
Using the generated block in a pipeline is very straight forward. There's a few approaches on how to implement the block in a Pipeline script.
Here's an example of using the generated block in a pipeline script. Make sure to replace the placeholder values with your own values.
The script is formatted for clarity. All these fields will be pre-filled for you if you use the `Snippet Generator` like described in the [step above](#generating-pipeline-block).
```groovy theme={"dark"}
node {
withInfisical(
configuration: [
infisicalCredentialId: 'YOUR_CREDENTIAL_ID',
infisicalEnvironmentSlug: 'PROJECT_ENV_SLUG',
infisicalProjectSlug: 'PROJECT_SLUG',
infisicalUrl: 'https://app.infisical.com' // Change this to your Infisical instance URL if you aren't using Infisical Cloud.
],
infisicalSecrets: [
infisicalSecret(
includeImports: true,
path: '/',
secretValues: [
[infisicalKey: 'DATABASE_URL'],
[infisicalKey: "API_URL"],
[infisicalKey: 'THIS_KEY_MIGHT_NOT_EXIST', isRequired: false],
]
)
]
) {
// Code runs here
sh "printenv"
}
}
```
Click on the credential store you want to store the Infisical Service Token in. In this case, we're using the default Jenkins global store.
Now, click Add Credentials.
Choose **Secret text** for the **Kind** option from the dropdown list and enter the Infisical Service Token in the **Secret** field.
Although the **ID** can be any value, we'll set it to `infisical-service-token` for the sake of this guide.
The description is optional and can be any text you prefer.
When you're done, you should see a credential similar to the one below:
## Use Infisical in a Freestyle Project
To fetch secrets with Infisical in a Freestyle Project job, you'll need to expose the credential you created above as an environment variable to the Infisical CLI.
To do so, first click **New Item** from the dashboard navigation sidebar:
Enter the name of the job, choose the **Freestyle Project** option, and click **OK**.
Scroll down to the **Build Environment** section and enable the **Use secret text(s) or file(s)** option. Then click **Add** under the **Bindings** section and choose **Secret text** from the dropdown menu.
Enter `INFISICAL_TOKEN` in the **Variable** field then click the **Specific credentials** option from the Credentials section and select the credential you created earlier.
In this case, we saved it as `Infisical service token` so we'll choose that from the dropdown menu.
Scroll down to the **Build** section and choose **Execute shell** from the **Add build step** menu.
In the command field, you can now use the Infisical CLI to fetch secrets.
The example command below will print the secrets using the service token passed as a credential. When done, click **Save**.
```
infisical secrets --env=dev --path=/
```
Finally, click **Build Now** from the navigation sidebar to run your new job.
Enter the name of the job, choose the **Pipeline** option, and click OK.
Scroll down to the **Pipeline** section, paste the following into the **Script** field, and click **Save**.
```
pipeline {
agent any
environment {
INFISICAL_TOKEN = credentials('infisical-service-token')
}
stages {
stage('Run Infisical') {
steps {
sh("infisical secrets --env=dev --path=/")
// doesn't work
// sh("docker run --rm test-container infisical secrets")
// works
// sh("docker run -e INFISICAL_TOKEN=${INFISICAL_TOKEN} --rm test-container infisical secrets --env=dev --path=/")
// doesn't work
// sh("docker-compose up -d")
// works
// sh("INFISICAL_TOKEN=${INFISICAL_TOKEN} docker-compose up -d")
}
}
}
}
```
{}
setSearchTerm(e.target.value)} />
{}
{}
{}
{filteredDynamicSecrets.length > 0 ?
}
;
};
{categories.map(category => )}
{filteredDynamicSecrets.length} dynamic secret{filteredDynamicSecrets.length !== 1 ? 's' : ''} found {selectedCategory !== 'All' && ` in ${selectedCategory}`} {searchTerm && ` for "${searchTerm}"`}
{filteredDynamicSecrets.map((secret, index) =>
)}
: {secret.name}
{secret.category}{secret.description}
No dynamic secrets found matching your criteria
{searchTerm &&Try adjusting your search terms or filters
}
# Framework Integrations
Source: https://infisical.com/docs/integrations/framework-integrations
Browse and search through all available framework integrations for Infisical.
export const FrameworkIntegrationsBrowser = () => {
const [searchTerm, setSearchTerm] = useState('');
const integrations = [{
"name": "React",
"slug": "react",
"path": "/integrations/frameworks/react",
"description": "Learn how to integrate Infisical with React applications for secure secret management.",
"category": "Web Frameworks"
}, {
"name": "Next.js",
"slug": "nextjs",
"path": "/integrations/frameworks/nextjs",
"description": "Learn how to integrate Infisical with Next.js applications.",
"category": "Web Frameworks"
}, {
"name": "Vue",
"slug": "vuejs",
"path": "/integrations/frameworks/vue",
"description": "Learn how to integrate Infisical with Vue.js applications.",
"category": "Web Frameworks"
}, {
"name": "Nuxt",
"slug": "nuxtjs",
"path": "/integrations/frameworks/nuxt",
"description": "Learn how to integrate Infisical with Nuxt.js applications.",
"category": "Web Frameworks"
}, {
"name": "SvelteKit",
"slug": "sveltekit",
"path": "/integrations/frameworks/sveltekit",
"description": "Learn how to integrate Infisical with SvelteKit applications.",
"category": "Web Frameworks"
}, {
"name": "Express, Fastify, Koa",
"slug": "express",
"path": "/integrations/frameworks/express",
"description": "Learn how to integrate Infisical with Express.js backend applications.",
"category": "Web Frameworks"
}, {
"name": "NestJS",
"slug": "nestjs",
"path": "/integrations/frameworks/nestjs",
"description": "Learn how to integrate Infisical with NestJS applications.",
"category": "Web Frameworks"
}, {
"name": "Django",
"slug": "django",
"path": "/integrations/frameworks/django",
"description": "Learn how to integrate Infisical with Django applications.",
"category": "Web Frameworks"
}, {
"name": "Flask",
"slug": "flask",
"path": "/integrations/frameworks/flask",
"description": "Learn how to integrate Infisical with Flask applications.",
"category": "Web Frameworks"
}, {
"name": "Ruby on Rails",
"slug": "rails",
"path": "/integrations/frameworks/rails",
"description": "Learn how to integrate Infisical with Ruby on Rails applications.",
"category": "Web Frameworks"
}, {
"name": "Spring Boot",
"slug": "spring-boot-maven",
"path": "/integrations/frameworks/spring-boot-maven",
"description": "Learn how to integrate Infisical with Spring Boot applications.",
"category": "Web Frameworks"
}, {
"name": "Laravel",
"slug": "laravel",
"path": "/integrations/frameworks/laravel",
"description": "Learn how to integrate Infisical with Laravel applications.",
"category": "Web Frameworks"
}, {
"name": ".NET",
"slug": "dotnet",
"path": "/integrations/frameworks/dotnet",
"description": "Learn how to integrate Infisical with .NET applications.",
"category": "Web Frameworks"
}, {
"name": "Fiber",
"slug": "fiber",
"path": "/integrations/frameworks/fiber",
"description": "Learn how to integrate Infisical with Fiber (Go) framework.",
"category": "Web Frameworks"
}, {
"name": "Gatsby",
"slug": "gatsby",
"path": "/integrations/frameworks/gatsby",
"description": "Learn how to integrate Infisical with Gatsby applications.",
"category": "Web Frameworks"
}, {
"name": "Remix",
"slug": "remix",
"path": "/integrations/frameworks/remix",
"description": "Learn how to integrate Infisical with Remix applications.",
"category": "Web Frameworks"
}, {
"name": "Vite",
"slug": "vite",
"path": "/integrations/frameworks/vite",
"description": "Learn how to integrate Infisical with Vite applications.",
"category": "Web Frameworks"
}, {
"name": "AB Initio",
"slug": "ab-initio",
"path": "/integrations/frameworks/ab-initio",
"description": "Learn how to integrate Infisical with AB Initio applications.",
"category": "Web Frameworks"
}].sort(function (a, b) {
return a.name.toLowerCase().localeCompare(b.name.toLowerCase());
});
const filteredIntegrations = useMemo(() => {
if (searchTerm) {
return integrations.filter(integration => integration.name.toLowerCase().includes(searchTerm.toLowerCase()) || integration.description.toLowerCase().includes(searchTerm.toLowerCase()));
}
return integrations;
}, [searchTerm]);
return
{}
setSearchTerm(e.target.value)} />
{}
{}
{filteredIntegrations.length > 0 ?
}
;
};
{filteredIntegrations.length} framework integration{filteredIntegrations.length !== 1 ? 's' : ''} found {searchTerm && ` for "${searchTerm}"`}
{filteredIntegrations.map((integration, index) =>
)}
: {integration.name}
{integration.description}
No framework integrations found matching your criteria
{searchTerm &&Try adjusting your search terms or filters
}
**Step 2:** Click the plus icon
**Step 3:** Select Shell Script
**Step 4:** Choose Script Text and then paste in the command below.
```
infisical run -- ./mvnw spring-boot:run -Dspring-boot.run.jvmArguments="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=*:5005"
```
**Step 5:** When you need to run a block of code in debug mode, select the Infisical script
# SvelteKit
Source: https://infisical.com/docs/integrations/frameworks/sveltekit
How to use Infisical to inject environment variables and secrets into a SvelteKit app.
Prerequisites:
* Set up and add envars to [Infisical Cloud](https://app.infisical.com)
* [Install the CLI](/cli/overview)
## Initialize Infisical for your [SvelteKit](https://kit.svelte.dev) app
```bash theme={"dark"}
# navigate to the root of your of your project
cd /path/to/project
# then initialize infisical
infisical init
```
## Start your application as usual but with Infisical
```bash theme={"dark"}
infisical run --
{}
setSearchTerm(e.target.value)} />
{}
{}
{}
{filteredAuthMethods.length > 0 ?
}
;
};
{categories.map(category => )}
{filteredAuthMethods.length} authentication method{filteredAuthMethods.length !== 1 ? 's' : ''} found {selectedCategory !== 'All' && ` in ${selectedCategory}`} {searchTerm && ` for "${searchTerm}"`}
{filteredAuthMethods.map((method, index) =>
)}
: {method.name}
{method.category}{method.description}
No authentication methods found matching your criteria
{searchTerm &&Try adjusting your search terms or filters
}This file is rendered by Infisical agent template engine
Here are the secrets that have been fetched from Infisical and stored in your volume mount
-
{{- with secret "7df67a5f-d26a-4988-a375-7153c08149da" "dev" "/" }}
{{- range . }}
- {{ .Key }}={{ .Value }} {{- end }} {{- end }}
This guide will go over the steps needed to access secrets stored in Infisical from Amazon Elastic Container Service (ECS).
At a high level, the steps involve setting up an ECS task with an [Infisical Agent](/integrations/platforms/infisical-agent) as a sidecar container. This sidecar container uses [AWS Auth](/documentation/platform/identities/aws-auth) to authenticate with Infisical to fetch secrets/access tokens.
Once the secrets/access tokens are retrieved, they are then stored in a shared [Amazon Elastic File System](https://aws.amazon.com/efs/) (EFS) volume. This volume is then made accessible to your application and all of its replicas.
This guide primarily focuses on integrating Infisical Cloud with Amazon ECS on AWS Fargate and Amazon EFS.
However, the principles and steps can be adapted for use with any instance of Infisical (on premise or cloud) and different ECS launch configurations.
## Prerequisites
This guide requires the following prerequisites:
* Infisical account
* Git installed
* Terraform v1.0 or later installed
* Access to AWS credentials
* Understanding of [Infisical Agent](/integrations/platforms/infisical-agent)
## What we will deploy
For this demonstration, we'll deploy the [File Browser](https://github.com/filebrowser/filebrowser) application on our ECS cluster.
Although this guide focuses on File Browser, the principles outlined here can be applied to any application of your choice.
File Browser plays a key role in this context because it enables us to view all files attached to a specific volume.
This feature is important for our demonstration, as it allows us to verify whether the Infisical agent is depositing the expected files into the designated file volume and if those files are accessible to the application.
Since our EFS volume is mounted to the path of the file browser application, we should see the access token and rendered secret file we defined via the agent config file.
As expected, two files are present: `access-token` and `secrets`.
The `access-token` file should hold a valid `Bearer` token, which can be used to make HTTP requests to Infisical.
The `secrets` file should contain secrets, formatted according to the specifications in our secret template file (presented in key=value format).
# Infisical Agent
Source: https://infisical.com/docs/integrations/platforms/infisical-agent
This page describes how to manage secrets using Infisical Agent.
Infisical Agent is a client daemon that simplifies the adoption of Infisical by providing a more scalable and user-friendly approach for applications to interact with Infisical.
It eliminates the need to modify application logic by enabling clients to decide how they want their secrets rendered through the use of templates.
## Key Features
* **Token lifecycle management**: Automatically authenticates with Infisical and deposits renewed access tokens at specified path for applications to consume
* **Templating**: Renders secrets and dynamic secret leases via user provided templates to desired formats for applications to consume
## Token Renewal
The Infisical agent can help manage the life cycle of access tokens. The token renewal process is split into two main components: a `Method`, which is the authentication process suitable for your current setup, and `Sinks`, which are the places where the agent deposits the new access token whenever it receives updates.
When the Infisical Agent is started, it will attempt to obtain a valid access token using the authentication method you have configured. If the agent is unable to fetch a valid token, the agent will keep trying, increasing the time between each attempt.
Once a access token is successfully fetched, the agent will make sure the access token stays valid, continuing to renew it before it expires.
Every time the agent successfully retrieves a new access token, it writes the new token to the Sinks you've configured.
This field is required when using any of the following auth types: `kubernetes`, `azure`, `gcp-id-token`, `gcp-iam`, or `aws-iam`. | | `auth.config.service-account-token` | Path to the Kubernetes service account token to use (optional)
Default: `/var/run/secrets/kubernetes.io/serviceaccount/token` | | `auth.config.service-account-key` | Path to your GCP service account key file. This field is required when using `gcp-iam` auth type.
Please note that the file should be in JSON format. | | `auth.config.client-id` | The file path where the universal-auth client id is stored. | | `auth.config.client-secret` | The file path where the universal-auth client secret is stored. | | `auth.config.remove_client_secret_on_read` | This will instruct the agent to remove the client secret from disk. | | `sinks[].type` | The type of sink in a list of sinks. Each item specifies a sink type. Currently, only `"file"` type is available. | | `sinks[].config.path` | The file path where the access token should be stored for each sink in the list. | | `cache.persistent.type` | The type of persistent caching to use. Currently only `kubernetes` is available, and will only work within Kubernetes environments. | | `cache.persistent.path` | The path to where your persistent cache will be stored. | | `cache.persistent.service-account-token-path` | The path to the Kubernetes service account token to use for encrypting the persistent cache. Required when using `kubernetes` cache type. Defaults to `/var/run/secrets/kubernetes.io/serviceaccount/token` | | `templates[].source-path` | The path to the template file that should be used to render secrets. | | `templates[].template-content` | The inline secret template to be used for rendering the secrets. | | `templates[].destination-path` | The path where the rendered secrets from the source template will be saved to. | | `templates[].config.polling-interval` | How frequently to check for secret changes. Default: `5m` (5 minutes) (optional) | | `templates[].config.execute.command` | The command to execute when secret change is detected (optional) | | `templates[].config.execute.timeout` | How long in seconds to wait for command to execute before timing out (optional) | ## Authentication The Infisical agent supports multiple authentication methods. Below are the available authentication methods, with their respective configurations.
When creating an identity, you specify an organization level [role](/documentation/platform/access-controls/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
Now input a few details for your new identity. Here's some guidance for each field:
* Name (required): A friendly name for the identity.
* Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.
Once you've created an identity, you'll be prompted to configure the authentication method for it. Here, select **Kubernetes Auth**.
When creating an identity, you specify an organization level [role](/documentation/platform/access-controls/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
Now input a few details for your new identity. Here's some guidance for each field:
* Name (required): A friendly name for the identity.
* Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.
Once you've created an identity, you'll be prompted to configure the authentication method for it. Here, select **Kubernetes Auth**.
{}
setSearchTerm(e.target.value)} />
{}
{}
{}
{filteredRotations.length > 0 ?
}
;
};
{categories.map(category => )}
{filteredRotations.length} secret rotation{filteredRotations.length !== 1 ? 's' : ''} found {selectedCategory !== 'All' && ` in ${selectedCategory}`} {searchTerm && ` for "${searchTerm}"`}
{filteredRotations.map((rotation, index) =>
)}
: {rotation.name}
{rotation.category}{rotation.description}
No secret rotations found matching your criteria
{searchTerm &&Try adjusting your search terms or filters
}
{}
setSearchTerm(e.target.value)} />
{}
{}
{}
{filteredSyncs.length > 0 ?
}
;
};
{categories.map(category => )}
{filteredSyncs.length} secret sync{filteredSyncs.length !== 1 ? 's' : ''} found {selectedCategory !== 'All' && ` in ${selectedCategory}`} {searchTerm && ` for "${searchTerm}"`}
{filteredSyncs.map((sync, index) =>
)}
: {sync.name}
{sync.category}{sync.description}
No secret syncs found matching your criteria
{searchTerm &&Try adjusting your search terms or filters
}
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **1Password Connection**: The 1Password Connection to authenticate with.
* **Vault**: The 1Password vault to sync secrets to.
* **Value Label**: The label of the 1Password item field that will hold your secret value.
* **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 1Password when keys conflict.
* **Import Secrets (Prioritize 1Password)**: Imports secrets from the destination endpoint before syncing, prioritizing values from 1Password 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 and `{{environment}}` for the environment.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
2. Select the **AWS Parameter Store** option.
3. Configure the **Source** from where secrets should be retrieved, then click **Next**.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **AWS Connection**: The AWS Connection to authenticate with.
* **Region**: The AWS region to deploy secrets to.
* **Path**: The AWS Parameter Store path to deploy secrets to.
5. Configure the **Sync Options** to specify how secrets should be synced, then click **Next**.
* **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 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 and `{{environment}}` for the environment.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
7. Review your Parameter Store Sync configuration, then click **Create Sync**.
8. If enabled, your Parameter Store Sync will begin syncing your secrets to the destination endpoint.
2. Select the **AWS Secrets Manager** option.
3. Configure the **Source** from where secrets should be retrieved, then click **Next**.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **AWS Connection**: The AWS Connection to authenticate with.
* **Region**: The AWS region to deploy secrets to.
* **Mapping Behavior**: Specify how Infisical should map secrets to AWS Secrets Manager:
* **One-To-One**: Each Infisical secret will be mapped to a separate AWS Secrets Manager secret.
* **Many-To-One**: All Infisical secrets will be mapped to a single AWS Secrets Manager secret.
* **Secret Name**: Specifies the name of the AWS Secret to map secrets to if **Many-To-One** mapping behavior is selected.
5. Configure the **Sync Options** to specify how secrets should be synced, then click **Next**.
* **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 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 and `{{environment}}` for the environment.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
7. Review your Secrets Manager Sync configuration, then click **Create Sync**.
8. If enabled, your Secrets Manager Sync will begin syncing your secrets to the destination endpoint.
2. Select the **Azure App Configuration** option.
3. Configure the **Source** from where secrets should be retrieved, then click **Next**.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Azure Connection**: The Azure Connection to authenticate with.
* **Configuration URL**: The URL of your Azure App Configuration.
* **Label**: An optional label to attach to all secrets created by Infisical inside your Azure App Configuration.
5. Configure the **Sync Options** to specify how secrets should be synced, then click **Next**.
* **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 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 and `{{environment}}` for the environment.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
7. Review your Azure App Configuration Sync configuration, then click **Create Sync**.
8. If enabled, your Azure App Configuration Sync will begin syncing your secrets to the destination endpoint.
2. Select the **Azure DevOps** option.
3. Configure the **Source** from where secrets should be retrieved, then click **Next**.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Azure DevOps Connection**: The Azure DevOps Connection to authenticate with.
* **Project**: The Azure DevOps project to deploy secrets to.
5. Configure the **Sync Options** to specify how secrets should be synced, then click **Next**.
* **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.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
7. Review your Azure DevOps Sync configuration, then click **Create Sync**.
8. If enabled, your Azure DevOps Sync will begin syncing your secrets to the destination endpoint.
2. Select the **Azure Key Vault** option.
3. Configure the **Source** from where secrets should be retrieved, then click **Next**.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Azure Connection**: The Azure Connection to authenticate with.
* **Vault Base URL**: The URL of your Azure Key Vault.
5. Configure the **Sync Options** to specify how secrets should be synced, then click **Next**.
* **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 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 and `{{environment}}` for the environment.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
7. Review your Azure Key Vault Sync configuration, then click **Create Sync**.
8. If enabled, your Azure Key Vault Sync will begin syncing your secrets to the destination endpoint.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Bitbucket Connection**: The Bitbucket Connection to authenticate with.
* **Workspace**: The Bitbucket workspace to sync secrets to.
* **Repository**: The Bitbucket repository to sync secrets to.
* **Deployment Environment (Optional)**: The Bitbucket deployment environment to sync secrets to.
* **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.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
2. Select the **Camunda** option.
3. Configure the **Source** from where secrets should be retrieved, then click **Next**.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Camunda Connection**: The Camunda Connection to authenticate with.
* **Cluster**: The Camunda cluster to sync connector secrets to.
5. Configure the **Sync Options** to specify how secrets should be synced, then click **Next**.
* **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 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 and `{{environment}}` for the environment.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
7. Review your Camunda Sync configuration, then click **Create Sync**.
8. If enabled, your Camunda Sync will begin syncing your secrets to the destination endpoint.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Checkly Connection**: The Checkly Connection to authenticate with.
* **Account**: The Checkly account to sync secrets to.
* **Group**: The Checkly check group to sync secrets to (Optional).
* **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.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Chef Connection**: The Chef Connection to authenticate with.
* **Data Bag**: The Data Bag to sync secrets to.
* **Data Bag Item**: The Data Bag Item to sync secrets to.
* **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 Chef when keys conflict.
* **Import Secrets (Prioritize Chef)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Chef 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 and `{{environment}}` for the environment.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
2. Select the **Cloudflare Pages** option.
3. Configure the **Source** from where secrets should be retrieved, then click **Next**.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Cloudflare Connection**: The Cloudflare Connection to authenticate with.
* **Cloudflare Pages Project**: Choose the Cloudflare Pages project you want to sync secrets to.
* **Environment**: Select the deployment environment (preview or production).
5. Configure the **Sync Options** to specify how secrets should be synced, then click **Next**.
* **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.
* **Key Schema**: Template that determines how secret names are transformed when syncing, using `{{secretKey}}` as a placeholder for the original secret name and `{{environment}}` for the environment.
* **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.
6. Configure the **Details** of your Cloudflare Pages Sync, then click **Next**.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
7. Review your Cloudflare Pages Sync configuration, then click **Create Sync**.
8. If enabled, your Cloudflare Pages Sync will begin syncing your secrets to the destination endpoint.
2. Select the **Cloudflare Workers** option.
3. Configure the **Source** from where secrets should be retrieved, then click **Next**.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Cloudflare Connection**: The Cloudflare Connection to authenticate with.
* **Cloudflare Workers Script**: Choose the Cloudflare Workers script you want to sync secrets to.
5. Configure the **Sync Options** to specify how secrets should be synced, then click **Next**.
* **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.
* **Key Schema**: Template that determines how secret names are transformed when syncing, using `{{secretKey}}` as a placeholder for the original secret name and `{{environment}}` for the environment.
* **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.
6. Configure the **Details** of your Cloudflare Workers Sync, then click **Next**.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
7. Review your Cloudflare Workers Sync configuration, then click **Create Sync**.
8. If enabled, your Cloudflare Workers Sync will begin syncing your secrets to the destination endpoint.
2. Select the **Databricks** option.
3. Configure the **Source** from where secrets should be retrieved, then click **Next**.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Databricks Connection**: The Databricks Connection to authenticate with.
* **Scope**: The Databricks secret scope to sync secrets to.
* **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.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
7. Review your Databricks Sync configuration, then click **Create Sync**.
8. If enabled, your Databricks Sync will begin syncing your secrets to the destination endpoint.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **DigitalOcean Connection**: The DigitalOcean Connection to authenticate with.
* **App**: The App Platform app to sync secrets to.
* **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.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Fly.io Connection**: The Fly.io Connection to authenticate with.
* **App**: The Fly.io app to sync secrets to.
* **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.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
* Ensure your network security policies allow incoming requests from Infisical to this secret sync provider, if network restrictions apply.
2. Select the **GCP Secret Manager** option.
3. Configure the **Source** from where secrets should be retrieved, then click **Next**.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **GCP Connection**: The GCP Connection to authenticate with.
* **Project**: The GCP project to sync with.
* **Scope**: The GCP project scope that secrets should be synced to:
* **Global**: Secrets will be synced globally; available to all project regions.
* **Region**: Secrets will be synced to the specified region.
5. Configure the **Sync Options** to specify how secrets should be synced, then click **Next**.
* **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 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 and `{{environment}}` for the environment.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
7. Review your Secret Manager Sync configuration, then click **Create Sync**.
8. If enabled, your GCP Secret Manager Sync will begin syncing your secrets to the destination endpoint.
2. Select the **GitHub** option.
3. Configure the **Source** from where secrets should be retrieved, then click **Next**.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **GitHub Connection**: The GitHub Connection to authenticate with.
* **Scope**: The GitHub secret scope to sync secrets to.
* **Organization**: Sync secrets to a specific organization.
* **Repository**: Sync secrets to a specific repository.
* **Repository Environment**: Sync secrets to a specific repository's environment.
The remaining fields are determined by the selected **Scope**:
* **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.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
7. Review your GitHub Sync configuration, then click **Create Sync**.
8. If enabled, your GitHub Sync will begin syncing your secrets to the destination endpoint.
2. Select the **GitLab** option.
3. Configure the **Source** from where secrets should be retrieved, then click **Next**.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **GitLab Connection**: The GitLab Connection to authenticate with.
* **Scope**: The GitLab scope to sync secrets to.
* **Project**: Sync secrets to a GitLab project.
* **Group**: Sync secrets to a GitLab group.
The remaining fields are determined by the selected **Scope**:
* **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.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
7. Review your GitLab Sync configuration, then click **Create Sync**.
8. If enabled, your GitLab Sync will begin syncing your secrets to the destination endpoint.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Hashicorp Vault Connection**: The Vault Connection to authenticate with.
* **Secrets Engine Mount**: The secrets engine to sync secrets with (e.g., 'secret', 'kv').
* **Path**: The specific path within the secrets engine where secrets will be stored.
After configuring these parameters, click the **Next** button to continue to the Sync Options step.
* **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 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 and `{{environment}}` for the environment.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
2. Select the **Heroku** option.
3. Configure the **Source** from where secrets should be retrieved, then click **Next**.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Heroku Connection**: The Heroku Connection to authenticate with.
* **Heroku App**: The Heroku application to sync secrets to.
5. Configure the **Sync Options** to specify how secrets should be synced, then click **Next**.
* **Initial Sync Behavior**: Determines how Infisical should resolve the initial sync.
* **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.
* **Overwrite Destination Secrets**: Removes any secrets at the destination endpoint not present in Infisical.
* **Key Schema**: Template that determines how secret names are transformed when syncing, using `{{secretKey}}` as a placeholder for the original secret name and `{{environment}}` for the environment.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
7. Review your Heroku Sync configuration, then click **Create Sync**.
8. If enabled, your Heroku Sync will begin syncing your secrets to the destination endpoint.
2. Select the **Humanitec** option.
3. Configure the **Source** from where secrets should be retrieved, then click **Next**.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Humanitec Connection**: The Humanitec Connection to authenticate with.
* **Scope**: The Humanitec secret scope to sync secrets to.
* **Application**: Sync secrets to a specific application.
* **Environment**: Sync secrets to a specific environment of an application.
The remaining fields are determined by the selected **Scope**:
* **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.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
7. Review your Humanitec Sync configuration, then click **Create Sync**.
8. If enabled, your Humanitec Sync will begin syncing your secrets to the destination endpoint.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Laravel Forge Connection**: The Laravel Forge Connection to authenticate with.
* **Organization**: The Organization in which the server and site reside.
* **Server**: The Server on which the site resides.
* **Site**: The Site for which secrets should be synced.
* **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 Laravel Forge when keys conflict.
* **Import Secrets (Prioritize Laravel Forge)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Laravel Forge 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 and `{{environment}}` for the environment.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Netlify Connection**: The Netlify Connection to authenticate with.
* **Account**: The Netlify Account to be used.
* **Site**: The Netlify site where secrets should be synced.
* **Context**: The Netlify deployment context where secrets should be created in.
* **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 Netlify when keys conflict.
* **Import Secrets (Prioritize Netlify)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Netlify over Infisical when keys conflict.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Northflank Connection**: The Northflank Connection to authenticate with.
* **Project**: The Northflank project to sync secrets to.
* **Secret Group**: The Northflank secret group to sync secrets to.
* **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 Destination Secrets - Prioritize Infisical Values**: Imports any secrets present in the Northflank destination prior to syncing, prioritizing values from Infisical over Northflank when keys conflict.
* **Import Destination Secrets - Prioritize Northflank Values**: Imports any secrets present in the Northflank destination prior to syncing, prioritizing values from Northflank 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 and `{{environment}}` for the environment.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **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.
* **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 and `{{environment}}` for the environment.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
```mermaid theme={"dark"}
%%{init: {'flowchart': {'curve': 'linear'} } }%%
graph LR
A[App Connection]
B[Secret Sync]
C[Secret 1]
D[Secret 2]
E[Secret 3]
F[Third-Party Service]
G[Secret 1]
H[Secret 2]
I[Secret 3]
J[Project Source]
B --> A
C --> J
D --> J
E --> J
A --> F
F --> G
F --> H
F --> I
J --> B
classDef default fill:#ffffff,stroke:#666,stroke-width:2px,rx:10px,color:black
classDef connection fill:#FFF2B2,stroke:#E6C34A,stroke-width:2px,color:black,rx:15px
classDef secret fill:#E6F4FF,stroke:#0096D6,stroke-width:2px,color:black,rx:15px
classDef sync fill:#F4FFE6,stroke:#96D600,stroke-width:2px,color:black,rx:15px
classDef service fill:#E6E6FF,stroke:#6B4E96,stroke-width:2px,color:black,rx:15px
classDef project fill:#FFE6E6,stroke:#D63F3F,stroke-width:2px,color:black,rx:15px
class A connection
class B sync
class C,D,E,G,H,I secret
class F project
class J service
```
## Workflow
Configuring a Secret Sync requires three components: a source location to retrieve secrets from,
a destination endpoint to deploy secrets to, and configuration options to determine how your secrets
should be synced. Follow these steps to start syncing:
```mermaid theme={"dark"}
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
```
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Railway Connection**: The Railway Connection to authenticate with.
* **Project**: The Railway project to sync secrets to.
* **Environment**: The Railway environment to sync secrets to.
* **Service**: The Service to sync secrets to.
* **If not provided**: Secrets will be synced as [shared variables](https://docs.railway.com/guides/variables#shared-variables) on Railway.
* **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 Railway when keys conflict.
* **Import Secrets (Prioritize Railway)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Railway 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 and `{{environment}}` for the environment.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
2. Select the **Render** option.
3. Configure the **Source** from where secrets should be retrieved, then click **Next**.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Render Connection**: The Render Connection to authenticate with.
* **Scope**: Select **Service** or **Environment Group**.
* **Service**: Choose the Render service you want to sync secrets to.
* **Environment Group**: Choose the Render environment group you want to sync secrets to.
5. Configure the **Sync Options** to specify how secrets should be synced, then click **Next**.
* **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 Render service before syncing, prioritizing values from Infisical over Render when keys conflict.
* **Import Secrets (Prioritize Render)**: Imports secrets from the Render service before syncing, prioritizing values from Render 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 and `{{environment}}` for the environment.
* **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.
6. Configure the **Details** of your Render Sync, then click **Next**.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
7. Review your Render Sync configuration, then click **Create Sync**.
8. If enabled, your Render Sync will begin syncing your secrets to the destination endpoint.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Supabase Connection**: The Supabase Connection to authenticate with.
* **Project**: The Supabase project to sync secrets to.
* **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.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
2. Select the **TeamCity** option.
3. Configure the **Source** from where secrets should be retrieved, then click **Next**.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **TeamCity Connection**: The TeamCity Connection to authenticate with.
* **Project**: The TeamCity project to sync secrets to.
* **Build Configuration**: The build configuration to sync secrets to.
* **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 TeamCity when keys conflict.
* **Import Secrets (Prioritize TeamCity)**: Imports secrets from the destination endpoint before syncing, prioritizing values from TeamCity over Infisical when keys conflict.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
7. Review your TeamCity Sync configuration, then click **Create Sync**.
8. If enabled, your TeamCity Sync will begin syncing your secrets to the destination endpoint.
2. Select the **Terraform Cloud** option.
3. Configure the **Source** from where secrets should be retrieved, then click **Next**.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Terraform Cloud Connection**: The Terraform Cloud Connection to authenticate with.
* **Organization**: The Terraform Cloud organization to deploy secrets to.
* **Category**: The Terraform Cloud variable category to use on secrets syncs. Choose from:
* **Environment**: Sync secrets as environment variables.
* **Terraform**: Sync secrets as Terraform variables.
* **Scope**: The Terraform Cloud secret scope to sync secrets to.
* **Variable Set**: Sync secrets to a specific variable set.
* **Workspace**: Sync secrets to a specific workspace.
The remaining fields are determined by the selected **Scope**:
* **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.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
7. Review your Terraform Cloud Sync configuration, then click **Create Sync**.
8. If enabled, your Terraform Cloud Sync will begin syncing your secrets to the destination endpoint.
2. Select the **Vercel** option.
3. Configure the **Source** from where secrets should be retrieved, then click **Next**.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Vercel Connection**: The Vercel Connection to authenticate with.
* **Vercel App**: The application to deploy secrets to.
* **Vercel App Environment**: The environment to deploy secrets to.
* **Vercel Preview Branch (Optional)**: Specify a branch for preview deployments if needed.
After configuring these parameters, click the **Next** button to continue to the Sync Options step.
5. Configure the **Sync Options** to specify how secrets should be synced, then click **Next**.
* **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 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.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
7. Review your Vercel Sync configuration, then click **Create Sync**.
8. If enabled, your Vercel Sync will begin syncing your secrets to the destination endpoint.
2. Select the **Windmill** option.
3. Configure the **Source** from where secrets should be retrieved, then click **Next**.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Windmill Connection**: The Windmill Connection to authenticate with.
* **Workspace**: The Windmill workspace to sync secrets to.
* **Path**: The workspace path to sync secrets to.
* **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 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 and `{{environment}}` for the environment.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
7. Review your Windmill Sync configuration, then click **Create Sync**.
8. If enabled, your Windmill Sync will begin syncing your secrets to the destination endpoint.
* **Environment**: The project environment to retrieve secrets from.
* **Secret Path**: The folder path to retrieve secrets from.
* **Zabbix Connection**: The Zabbix Connection to authenticate with.
* **Scope**: The Zabbix scope to sync secrets to.
* **Global**: Secrets will be synced globally.
* **Host**: Secrets will be synced to the specified host.
* **Macro Type**: The type of macro to use when syncing secrets to Zabbix. Currently only **Text** and **Secret** macros are supported.
The remaining fields are determined by the selected **Scope**:
* **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 Zabbix when keys conflict.
* **Import Secrets (Prioritize Zabbix)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Zabbix 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 and `{{environment}}` for the environment.
* **Name**: The name of your sync. Must be slug-friendly.
* **Description**: An optional description for your sync.
{}
setSearchTerm(e.target.value)} />
{}
{}
{}
{filteredAuthMethods.length > 0 ?
}
;
};
{categories.map(category => )}
{filteredAuthMethods.length} user authentication method{filteredAuthMethods.length !== 1 ? 's' : ''} found {selectedCategory !== 'All' && ` in ${selectedCategory}`} {searchTerm && ` for "${searchTerm}"`}
{filteredAuthMethods.map((method, index) =>
)}
: {method.name}
{method.category}{method.description}
No user authentication methods found matching your criteria
{searchTerm &&Try adjusting your search terms or filters
}
## Components
A typical Infisical Cloud deployment consists of the following components:
### Application Services
* **Infisical Core**: Main application server running the Infisical backend API
* **License API**: Dedicated API service for license management with separate RDS instance (shared between US/EU)
* **Application Load Balancer**: Routes incoming traffic to application containers with SSL termination and host-based routing
### Data Layer
* **Amazon RDS (PostgreSQL)**:
* **Main RDS Instance**: Primary database for secrets, users, and metadata (Multi-AZ, encryption enabled)
* **License API RDS Instance**: Dedicated database for license management services
* **Amazon ElastiCache (Redis)**:
* **Main Redis Cluster**: Multi-AZ replication group for core application caching and queuing
* **License API Redis**: Dedicated cache for license services
* Redis 7 engine with CloudWatch logging and snapshot backups
### Infrastructure
* **ECS Fargate**: Serverless container platform running application services
* **AWS Global Accelerator**: Global traffic routing and performance optimization
* **Cloudflare**: DNS management and routing
* **AWS SSM Parameter Store**: Stores application configuration and secrets
* **CloudWatch**: Centralized logging and monitoring
## System Layout
### Service Architecture
The Infisical application runs as multiple containerized services on ECS:
* **Main Server**: Auto-scaling containerized application services
* **License API**: Dedicated service with separate infrastructure (shared globally)
* **Monitoring**: AWS OTel Collector and Datadog Agent sidecars
Container images are pulled from Docker Hub and managed via GitHub Actions for deployments.
### Network Configuration
Services are deployed in private subnets with the following connectivity:
* External traffic → Application Load Balancer → ECS Services
* Main server exposes port 8080
* License API exposes port 4000 (portal.infisical.com, license.infisical.com)
* Service-to-service communication via AWS Service Connect
### Data Flow
1. **DNS resolution** via Cloudflare routes traffic to AWS Global Accelerator
2. **Global Accelerator** optimizes routing to the nearest AWS region
3. **Client requests** are routed through the Application Load Balancer to ECS containers
4. **Application logic** processes requests in the Infisical Core service
5. **Data persistence** occurs via encrypted connections to RDS
6. **Caching** utilizes ElastiCache for performance optimization
7. **Configuration** is retrieved from AWS SSM Parameter Store
## Regional Deployments
Each region operates in a separate AWS account, providing strong isolation boundaries for security, compliance, and operational independence.
### US Cloud (us.infisical.com or app.infisical.com)
* **AWS Account**: Dedicated US AWS account
* **Infrastructure**: ECS-based containerized deployment
* **Monitoring**: Integrated with Datadog for observability and security monitoring
### EU Cloud (eu.infisical.com)
* **AWS Account**: Dedicated EU AWS account
* **Infrastructure**: ECS-based containerized deployment
* **Monitoring**: Integrated with Datadog for observability and security monitoring
## Configuration Management
Application configuration and secrets are managed through AWS SSM Parameter Store, with deployment automation handled via GitHub Actions.
## Monitoring and Observability
### Logging
* **CloudWatch**: 365-day retention for application logs
* **Health Checks**: HTTP endpoint monitoring for service health
### Metrics
* **AWS OTel Collector**: Prometheus metrics collection
* **Datadog Agent**: Application performance monitoring and infrastructure metrics
## Container Management
* **Images**: `infisical/staging_infisical` and `infisical/license-api` from Docker Hub
* **Deployment**: Automated via GitHub Actions updating SSM parameter for image tags
* **Registry Access**: Docker Hub credentials stored in AWS Secrets Manager
* **Platform**: ECS Fargate serverless container platform
## Security Overview
### Data Protection
* **Encryption**: All secrets encrypted at rest and in transit
* **Network Isolation**: Services deployed in private subnets with controlled access
* **Authentication**: API tokens and service accounts for secure access
* **Audit Logging**: Comprehensive audit trails for all secret operations
### Network Architecture
* **VPC Design**: Dedicated VPC with public and private subnets across multiple Availability Zones
* **NAT Gateway**: Controlled outbound connectivity from private subnets
* **Load Balancing**: Application Load Balancer with SSL termination and health checks
* **Security Groups**: Restrictive firewall rules and controlled network access
* **High Availability**: Multi-AZ deployment with automatic failover
* **Network Monitoring**: VPC Flow Logs with 365-day retention for traffic analysis
# Components
Source: https://infisical.com/docs/internals/architecture/components
Understand Infisical's core architectural components and how they work together.
## Overview
Infisical is architected around several key components that work in concert to provide a secure and streamlined secret management experience. These components span the client, API, and storage layers, ensuring that secrets are protected at every stage of their lifecycle.
## 1. API (Backend)
Infisical exposes a well-documented [REST API](https://infisical.com/docs/api-reference/overview/introduction) that enables programmatic interaction with the platform, enabling a wide range of use cases.
## 2. Storage Backend
Infisical relies on a robust storage backend to durably store secrets, users, and other platform data. Infisical's storage backend is [PostgreSQL](https://www.postgresql.org/).
## 3. Caching Layer
Infisical uses [Redis](https://redis.com) to enable more complex workflows including a queuing system to manage long-running asynchronous tasks, cron jobs, as well as reliable cache for frequently used resources.
## 4. Clients
Clients are interfaces through which users and applications interact with the Infisical API:
* **Web UI**: A browser-based portal providing a user-friendly interface for managing secrets, configurations, and performing administrative tasks.
* [**CLI**](https://infisical.com/docs/cli): A terminal-based tool for interacting with the Infisical API, enabling automation, scripting, and integration into CI/CD pipelines.
* **SDKs (Software Development Kits)**: Platform-specific libraries with method abstractions for working with secrets. Supported languages include [Node.js](https://infisical.com/docs/sdks/languages/node), [Python](https://infisical.com/docs/sdks/languages/python), [Java](https://infisical.com/docs/sdks/languages/java), [Golang](https://infisical.com/docs/sdks/languages/go), [Ruby](https://infisical.com/docs/sdks/languages/ruby) and [.NET](https://infisical.com/docs/sdks/languages/csharp).
* [**Kubernetes Operator**](https://infisical.com/docs/integrations/platforms/kubernetes): A Kubernetes-native component that facilitates the secure retrieval and management of secrets within a Kubernetes cluster. The operator supports multiple custom resource definitions (CRDs) for syncing secrets.
* [**Infisical Agent**](https://infisical.com/docs/integrations/platforms/infisical-agent): Daemon that automatically fetches and manages access tokens and secrets to be used in various client resources.
# Overview
Source: https://infisical.com/docs/internals/overview
Read how Infisical works under the hood.
This section covers the internals of Infisical including its technical underpinnings, architecture, and security properties.