awatertrevi/infisical
1
0
Fork 0
mirror of https://github.com/awatertrevi/infisical.git synced 2026-09-22 13:39:35 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'origin' into pki-v3-docs

Browse Source
This commit is contained in:
Tuan Dang
2025-11-05 16:16:47 -08:00
parent 80329e69dd 7d8b28367e
commit 7f763dbe81
628 changed files with 19299 additions and 8522 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/api-reference/endpoints/app-connections/northflank/available.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Available"
openapi: "GET /api/v1/app-connections/northflank/available"
---

8
docs/api-reference/endpoints/app-connections/northflank/create.mdx Normal file
View File

@@ -0,0 +1,8 @@
---
title: "Create"
openapi: "POST /api/v1/app-connections/northflank"
---
<Note>
Check out the configuration docs for [Northflank Connections](/integrations/app-connections/northflank) to learn how to obtain the required credentials.
</Note>

4
docs/api-reference/endpoints/app-connections/northflank/delete.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Delete"
openapi: "DELETE /api/v1/app-connections/northflank/{connectionId}"
---

4
docs/api-reference/endpoints/app-connections/northflank/get-by-id.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Get by ID"
openapi: "GET /api/v1/app-connections/northflank/{connectionId}"
---

4
docs/api-reference/endpoints/app-connections/northflank/get-by-name.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Get by Name"
openapi: "GET /api/v1/app-connections/northflank/connection-name/{connectionName}"
---

4
docs/api-reference/endpoints/app-connections/northflank/list.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "List"
openapi: "GET /api/v1/app-connections/northflank"
---

4
docs/api-reference/endpoints/app-connections/northflank/update.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Update"
openapi: "PATCH /api/v1/app-connections/northflank/{connectionId}"
---

4
docs/api-reference/endpoints/secret-syncs/northflank/create.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Create"
openapi: "POST /api/v1/secret-syncs/northflank"
---

4
docs/api-reference/endpoints/secret-syncs/northflank/delete.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Delete"
openapi: "DELETE /api/v1/secret-syncs/northflank/{syncId}"
---

4
docs/api-reference/endpoints/secret-syncs/northflank/get-by-id.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Get by ID"
openapi: "GET /api/v1/secret-syncs/northflank/{syncId}"
---

4
docs/api-reference/endpoints/secret-syncs/northflank/get-by-name.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Get by Name"
openapi: "GET /api/v1/secret-syncs/northflank/sync-name/{syncName}"
---

4
docs/api-reference/endpoints/secret-syncs/northflank/import-secrets.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Import Secrets"
openapi: "POST /api/v1/secret-syncs/northflank/{syncId}/import-secrets"
---

4
docs/api-reference/endpoints/secret-syncs/northflank/list.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "List"
openapi: "GET /api/v1/secret-syncs/northflank"
---

4
docs/api-reference/endpoints/secret-syncs/northflank/remove-secrets.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Remove Secrets"
openapi: "POST /api/v1/secret-syncs/northflank/{syncId}/remove-secrets"
---

4
docs/api-reference/endpoints/secret-syncs/northflank/sync-secrets.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Sync Secrets"
openapi: "POST /api/v1/secret-syncs/northflank/{syncId}/sync-secrets"
---

4
docs/api-reference/endpoints/secret-syncs/northflank/update.mdx Normal file
View File

@@ -0,0 +1,4 @@
---
title: "Update"
openapi: "PATCH /api/v1/secret-syncs/northflank/{syncId}"
---

8
docs/api-reference/overview/introduction.mdx
View File

@@ -7,4 +7,10 @@ Infisical's Public (REST) API provides users an alternative way to programmatica
secrets via HTTPS requests. This can be useful for automating tasks, such as
rotating credentials, or for integrating secret management into a larger system.
With the Public API, you can create, read, update, and delete secrets, as well as manage access control, query audit logs, and more.
With the Public API, you can create, read, update, and delete secrets, as well as manage access control, query audit logs, and more.
## API Versioning
The API is versioned on a per-resource basis. A resource's version is only incremented for breaking changes, so different endpoints may have different version numbers (e.g., `/api/v4/secrets` vs. `/api/v1/secret-syncs`).
As a best practice, always use the latest available version for each endpoint to ensure access to the most recent features and improvements.

259
docs/cli/commands/login.mdx
View File

@@ -9,22 +9,97 @@ infisical login
### Description
The CLI uses authentication to verify your identity. When you enter the correct email and password for your account, a token is generated and saved in your system Keyring to allow you to make future interactions with the CLI.
The CLI uses authentication to verify your identity. You can authenticate using:
- **Browser Login** (default): Opens a browser for authentication
- **Direct Login**: Provide email and password via flags or environment variables for non-interactive workflows
- **Interactive CLI Login**: Use the `--interactive` flag to enter credentials via CLI prompts
When authenticated, a token is generated and saved in your system Keyring to allow you to make future interactions with the CLI.
To change where the login credentials are stored, visit the [vaults command](./vault).
If you have added multiple users, you can switch between the users by using the [user command](./user).
<Info>
When you authenticate with **any other method than `user`**, an access token will be printed to the console upon successful login. This token can be used to authenticate with the Infisical API and the CLI by passing it in the `--token` flag when applicable.
Use flag `--plain` along with `--silent` to print only the token in plain text when using a machine identity auth method.
**JWT Token Output:**
- For **user authentication** with the `--plain --silent` flags: outputs only the JWT access token (useful for scripting)
- For **machine identity authentication**: an access token is always printed to the console
Use the `--plain` flag to print only the token in plain text and the `--silent` flag to disable update alerts.
Both flags are ideal for capturing the token in environment variables or CI/CD pipelines.
</Info>
### Authentication Methods
The Infisical CLI supports multiple authentication methods. Below are the available authentication methods, with their respective flags.
The Infisical CLI supports two main categories of authentication: User Authentication and Machine Identity Authentication.
#### User Authentication
User authentication is designed for individual developers and supports multiple login flows.
<AccordionGroup>
<Accordion title="User">
The User authentication method allows you to log in with your email and password. This method supports three different login flows:
- **Browser Login** (default): Opens a browser for authentication
- **Direct Login**: Provide credentials via flags or environment variables for CI/CD
- **Interactive CLI Login**: Enter credentials via CLI prompts using `--interactive`
<ParamField query="Flags">
<Expandable title="properties">
<ParamField query="email" type="string" optional>
Your email address. Required for direct login along with `--password` and `--organization-id`.
</ParamField>
<ParamField query="password" type="string" optional>
Your password. Required for direct login along with `--email` and `--organization-id`.
</ParamField>
<ParamField query="organization-id" type="string" optional>
Your organization id. Required for direct login along with `--password` and `--email`.
</ParamField>
<ParamField query="interactive" type="boolean" optional>
Force interactive CLI login instead of browser-based authentication.
</ParamField>
<ParamField query="plain" type="boolean" optional>
Output only the JWT token (useful for scripting and CI/CD).
</ParamField>
</Expandable>
</ParamField>
<AccordionGroup>
<Accordion title="Browser Login (Default)">
```bash
infisical login
```
</Accordion>
<Accordion title="Direct Login (CI/CD)">
```bash
infisical login --email=user@example.com --password=your-password --organization-id=your-organization-id
# Or using environment variables
export INFISICAL_EMAIL="user@example.com"
export INFISICAL_PASSWORD="your-password"
export INFISICAL_ORGANIZATION_ID="your-organization-id"
infisical login
```
</Accordion>
<Accordion title="Interactive CLI Login">
```bash
infisical login --interactive
```
</Accordion>
<Accordion title="Plain Token Output (Useful for scripting and CI/CD)">
```bash
export INFISICAL_TOKEN=$(infisical login --email=user@example.com --password=your-password --organization-id=your-organization-id --plain --silent)
```
</Accordion>
</AccordionGroup>
</Accordion>
</AccordionGroup>
#### Machine Identity Authentication
Machine identity authentication methods are designed for automated systems, services, and CI/CD pipelines.
<AccordionGroup>
<Accordion title="Universal Auth">
@@ -237,7 +312,7 @@ The Infisical CLI supports multiple authentication methods. Below are the availa
Run the `login` command with the following flags to obtain an access token:
```bash
infisical login --method=jwt-auth --jwt=<jwt> --machine-identity-id=<machine-identity-id>
infisical login --method=jwt-auth --jwt=<jwt-token> --machine-identity-id=<machine-identity-id>
```
</Step>
</Steps>
@@ -262,7 +337,8 @@ The login command supports a number of flags that you can use for different auth
- `gcp-id-token`: Login using a GCP ID token native auth.
- `gcp-iam`: Login using a GCP IAM.
- `aws-iam`: Login using an AWS IAM native auth.
- `oidc-auth`: Login using oidc auth.
- `oidc-auth`: Login using OIDC auth.
- `jwt-auth`: Login using a plain JWT token.
</Accordion>
<Accordion title="--client-id">
@@ -330,22 +406,173 @@ The login command supports a number of flags that you can use for different auth
</Tip>
</Accordion>
</AccordionGroup>
<Accordion title="--oidc-jwt">
<Accordion title="--email">
```bash
infisical login --oidc-jwt=<oidc-jwt-token>
infisical login --email=<email> --password=<password> --organization-id=<organization-id>
```
#### Description
The JWT provided by an identity provider for OIDC authentication.
User email address. Required if you want to do a non-interactive login when the **--method** flag is set to **user**. Must be used together with the `--password` and `--organization-id` flag.
<Tip>
The `oidc-jwt` flag can be substituted with the `INFISICAL_OIDC_AUTH_JWT` environment variable.
You can omit the **--method=user** if you want as it's the default method.
</Tip>
<Tip>
The `email` flag can be substituted with the `INFISICAL_EMAIL` environment variable.
</Tip>
</Accordion>
<Accordion title="--password">
```bash
infisical login --email=<email> --password=<password> --organization-id=<organization-id>
```
#### Description
User password. Required if you want to do a non-interactive login when the **--method** flag is set to **user**. Must be used together with the `--email` and `--organization-id` flag.
<Warning>
For security in CI/CD environments, prefer using the `INFISICAL_PASSWORD` environment variable instead of passing the password as a command-line flag.
</Warning>
<Tip>
You can omit the **--method=user** if you want as it's the default method.
</Tip>
<Tip>
The `password` flag can be substituted with the `INFISICAL_PASSWORD` environment variable.
</Tip>
</Accordion>
<Accordion title="--organization-id">
```bash
infisical login --email=<email> --password=<password> --organization-id=<organization-id>
```
#### Description
User organization id. Required if you want to do a non-interactive login when the **--method** flag is set to **user**. Must be used together with the `--email` and `--password` flag.
<Tip>
You can omit the **--method=user** if you want as it's the default method.
</Tip>
<Tip>
The `organization-id` flag can be substituted with the `INFISICAL_ORGANIZATION_ID` environment variable.
</Tip>
</Accordion>
<Accordion title="--interactive">
```bash
infisical login --interactive
```
#### Description
Forces interactive CLI login where you'll be prompted to enter your email, password, and select your organization in the terminal, instead of opening a browser.
</Accordion>
<Accordion title="--plain">
```bash
infisical login --email=<email> --password=<password> --organization-id=<organization-id> --plain
```
#### Description
When used with direct user login or machine identity authentication, outputs only the JWT access token without any additional formatting. This is useful for scripting and CI/CD pipelines where you need to capture the token.
```bash
# Example: Capture token in a variable
export INFISICAL_TOKEN=$(infisical login --email=<email> --password=<password> --organization-id=<organization-id> --plain --silent)
```
<Tip>
Use it alongside the `silent` flag to disable all messages in the console except from the access token.
</Tip>
</Accordion>
<Accordion title="--jwt">
```bash
infisical login --jwt=<jwt-token> --machine-identity-id=<machine-identity-id>
```
#### Description
The JWT provided by an identity provider for OIDC or plain JWT authentication. This is required if the `--method` flag is set to `oidc-auth` or `jwt-auth`.
<Tip>
The `jwt` flag can be substituted with the `INFISICAL_JWT` environment variable.
</Tip>
</Accordion>
</AccordionGroup>
### User Authentication Examples
The following examples demonstrate different ways to authenticate as a user with the Infisical CLI.
<AccordionGroup>
<Accordion title="Browser Login (Default)">
By default, running `infisical login` without any flags opens your browser for authentication.
```bash
# Opens browser for authentication
infisical login
```
The browser will open to the Infisical login page, and upon successful authentication, the CLI will be automatically authenticated.
</Accordion>
<Accordion title="Direct Login (Non-Interactive)">
Direct login is ideal for CI/CD pipelines and automation scripts where browser-based authentication is not possible.
#### Using Command-Line Flags
```bash
# Basic direct login (defaults to US Cloud)
infisical login --email user@example.com --password "your-password" --organization-id "your-organization-id"
# EU Cloud (Custom domain)
infisical login --email user@example.com --password "your-password" --organization-id "your-organization-id" --domain https://eu.infisical.com
# Output only JWT token for scripting
export INFISICAL_TOKEN=$(infisical login --email user@example.com --password "your-password" --organization-id "your-organization-id" --plain --silent)
```
#### Using Environment Variables (Recommended for CI/CD)
```bash
# Set credentials as environment variables
export INFISICAL_EMAIL="user@example.com"
export INFISICAL_PASSWORD="your-password"
export INFISICAL_ORGANIZATION_ID="your-organization-id"
# Login without additional flags
infisical login
# Or with plain output for token capture
export INFISICAL_TOKEN=$(infisical login --plain --silent)
```
</Accordion>
<Accordion title="Interactive CLI Login">
Interactive login prompts you to enter credentials in the terminal instead of opening a browser.
```bash
# Force interactive CLI login
infisical login --interactive
```
You'll be prompted to enter:
- Email address
- Password
After the prompt, you will be shown a list of organizations to choose from.
</Accordion>
</AccordionGroup>
<Tip>
If you have SSO enabled, we recommend using the default browser login.
</Tip>
### Machine Identity Authentication Quick Start
@@ -367,9 +594,9 @@ In this example we'll be using the `universal-auth` method to login to obtain an
```
</Step>
<Step title="Fetch all secrets from an evironment">
<Step title="Fetch all secrets from an environment">
```bash
infisical secrets --projectId=<your-project-id --env=dev --recursive
infisical secrets --projectId=<your-project-id> --env=dev --recursive
```
This command will fetch all secrets from the `dev` environment in your project, including all secrets in subfolders.

30
docs/cli/usage.mdx
View File

@@ -9,11 +9,15 @@ The CLI is designed for a variety of secret management applications ranging from
<Tab title="Local development">
In the following steps, we explore how to use the Infisical CLI to fetch back environment variables from Infisical
and inject them into your local development process.
<Note>
If you prefer learning by watching, you can follow along our step-by-step video tutorial [here](https://www.youtube.com/watch?v=EzDQC7nY3YY).
</Note>
<Steps>
<Step title="Log in with the CLI">
Start by running the `infisical login` command to authenticate with Infisical.
```bash
infisical login
```
@@ -23,7 +27,7 @@ The CLI is designed for a variety of secret management applications ranging from
</Step>
<Step title="Initialize Infisical for your project">
Next, navigate to your project and initialize Infisical.
```bash
# navigate to your project
cd /path/to/project
@@ -123,23 +127,25 @@ The CLI is designed for a variety of secret management applications ranging from
<Note>
Starting with CLI version v0.4.0, you can now choose to log in via Infisical Cloud (US/EU) or your own self-hosted instance by simply running `infisical login` and following the on-screen instructions — no need to manually set the `INFISICAL_API_URL` environment variable.
For versions prior to v0.4.0, the CLI defaults to the US Cloud. To connect to the EU Cloud or a self-hosted instance, set the `INFISICAL_API_URL` environment variable to `https://eu.infisical.com` or your custom URL.
For versions prior to v0.4.0, the CLI defaults to the US Cloud. To connect to the EU Cloud or a self-hosted instance, set the `INFISICAL_API_URL` environment variable to `https://eu.infisical.com` or your custom URL.
</Note>
<Tip>
## Custom Request Headers
The Infisical CLI supports custom HTTP headers for requests to servers protected by authentication services such as Cloudflare Access. Configure these headers using the `INFISICAL_CUSTOM_HEADERS` environment variable:
The Infisical CLI supports custom HTTP headers for requests to servers protected by authentication services such as Cloudflare Access. Configure these headers using the `INFISICAL_CUSTOM_HEADERS` environment variable:
```bash
# Syntax: headername1=headervalue1 headername2=headervalue2
export INFISICAL_CUSTOM_HEADERS="Access-Client-Id=your-client-id Access-Client-Secret=your-client-secret"
```bash
# Syntax: headername1=headervalue1 headername2=headervalue2
export INFISICAL_CUSTOM_HEADERS="Access-Client-Id=your-client-id Access-Client-Secret=your-client-secret"
# Execute Infisical commands after setting the environment variable
infisical secrets
```
# Execute Infisical commands after setting the environment variable
infisical secrets
```
This functionality enables secure interaction with Infisical instances that require specific authentication headers.
This functionality enables secure interaction with Infisical instances that require specific authentication headers.
</Tip>
## History

29
docs/contributing/getting-started/overview.mdx
View File

@@ -7,20 +7,20 @@ To set a strong foundation, this section outlines how we, the community and memb
should approach the development and contribution process.
## Code-bases
Infisical has two major code-bases. One for the platform code, and one for SDKs. The contribution process has some key differences between the two, so we've split the documentation into two sections:
- The [Infisical Platform](https://github.com/Infisical/infisical), the Infisical platform itself.
- The [Infisical SDK](https://infisical.com/docs/sdks/overview), the official Infisical client SDKs.
<CardGroup cols={2}>
<Card title="Infisical Platform" href="/contributing/platform/developing" icon="layer-group" color="#A1B659">
The Infisical platform is the core of the Infisical ecosystem.
</Card>
<Card href="/contributing/sdk/developing" title="Infisical SDK" icon="code" color="#A1B659">
The SDKs are the official Infisical client libraries, used by developers to easily interact with the Infisical platform.
</Card>
</CardGroup>
- The <b>Infisical SDKs</b>, please refer to each individual SDK repositories for more information.
- [Node.js SDK](https://github.com/Infisical/node-sdk-v2)
- [Python SDK](https://github.com/Infisical/python-sdk-official)
- [Java SDK](https://github.com/Infisical/java-sdk)
- [.NET SDK](https://github.com/Infisical/infisical-dotnet-sdk)
- [Go SDK](https://github.com/Infisical/go-sdk)
- [C++ SDK](https://github.com/Infisical/infisical-cpp-sdk)
- [PHP SDK](https://github.com/Infisical/php-sdk)
- [Rust SDK](https://github.com/Infisical/rust-sdk)
- [Ruby SDK](https://github.com/infisical/sdk)
## Community
@@ -45,15 +45,12 @@ If you're ever in doubt about whether or not a proposed feature aligns with Infi
## Writing and submitting code
Anyone can contribute code to Infisical. To get started, check out the local development guides for each language.
- Local development guide for Platform is [here](/contributing/platform/developing).
- Local development guide for SDK is [here](/contributing/sdk/developing).
Anyone can contribute code to Infisical. To get started, check out the local development guide for the platform:
- Local development guide for Platform is [here](/contributing/platform/developing).
## Licensing
Most of Infisical's code is under the MIT license, though some paid feature restrictions are covered by a proprietary license.
Any third party components incorporated into our code are licensed under the original license provided by the applicable component owner.

49
docs/docs.json
View File

@@ -130,6 +130,7 @@
"integrations/app-connections/mssql",
"integrations/app-connections/mysql",
"integrations/app-connections/netlify",
"integrations/app-connections/northflank",
"integrations/app-connections/oci",
"integrations/app-connections/okta",
"integrations/app-connections/oracledb",
@@ -176,16 +177,14 @@
"pages": [
"documentation/platform/gateways/overview",
"documentation/platform/gateways/gateway-deployment",
"documentation/platform/gateways/relay-deployment",
"documentation/platform/gateways/security",
{
"group": "Gateway (Deprecated)",
"group": "Relay Deployment",
"pages": [
"documentation/platform/gateways-deprecated/overview",
"documentation/platform/gateways-deprecated/gateway-security",
"documentation/platform/gateways-deprecated/networking"
"documentation/platform/gateways/relay-deployment/overview",
"documentation/platform/gateways/relay-deployment/terraform"
]
}
},
"documentation/platform/gateways/security"
]
}
]
@@ -554,6 +553,7 @@
"integrations/secret-syncs/humanitec",
"integrations/secret-syncs/laravel-forge",
"integrations/secret-syncs/netlify",
"integrations/secret-syncs/northflank",
"integrations/secret-syncs/oci-vault",
"integrations/secret-syncs/railway",
"integrations/secret-syncs/render",
@@ -808,6 +808,15 @@
]
}
]
},
{
"item": "Infisical PAM",
"groups": [
{
"group": "Infisical PAM",
"pages": ["documentation/platform/pam/overview"]
}
]
}
]
},
@@ -1873,6 +1882,18 @@
"api-reference/endpoints/app-connections/netlify/delete"
]
},
{
"group": "Northflank",
"pages": [
"api-reference/endpoints/app-connections/northflank/list",
"api-reference/endpoints/app-connections/northflank/available",
"api-reference/endpoints/app-connections/northflank/get-by-id",
"api-reference/endpoints/app-connections/northflank/get-by-name",
"api-reference/endpoints/app-connections/northflank/create",
"api-reference/endpoints/app-connections/northflank/update",
"api-reference/endpoints/app-connections/northflank/delete"
]
},
{
"group": "OCI",
"pages": [
@@ -2331,6 +2352,20 @@
"api-reference/endpoints/secret-syncs/netlify/remove-secrets"
]
},
{
"group": "Northflank",
"pages": [
"api-reference/endpoints/secret-syncs/northflank/list",
"api-reference/endpoints/secret-syncs/northflank/get-by-id",
"api-reference/endpoints/secret-syncs/northflank/get-by-name",
"api-reference/endpoints/secret-syncs/northflank/create",
"api-reference/endpoints/secret-syncs/northflank/update",
"api-reference/endpoints/secret-syncs/northflank/delete",
"api-reference/endpoints/secret-syncs/northflank/sync-secrets",
"api-reference/endpoints/secret-syncs/northflank/import-secrets",
"api-reference/endpoints/secret-syncs/northflank/remove-secrets"
]
},
{
"group": "OCI",
"pages": [

1
docs/documentation/getting-started/introduction.mdx
View File

@@ -38,3 +38,4 @@ Infisical consists of several tightly integrated products, each designed to solv
- [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.

6
docs/documentation/getting-started/overview.mdx
View File

@@ -40,6 +40,12 @@ description: "The open source platform for managing secrets, certificates, and s
>
Replace static SSH keys with short-lived SSH certificates to simplify access and improve security.
</Card>
<Card
title="Infisical PAM"
href="/documentation/platform/pam/overview"
>
Manage access to resources like databases, servers, and accounts with policy-based controls and approvals.
</Card>
</Columns>
<Columns cols="1">

47
docs/documentation/platform/external-migrations/vault.mdx
View File

@@ -26,6 +26,12 @@ Infisical provides two approaches for migrating from HashiCorp Vault.
This migration approach lets you set up a connection to your Vault instance once, then import specific resources as needed throughout Infisical.
<Warning>
**Organization Admin Access Required:** All in-platform migration features
(importing secrets, Kubernetes configurations, and policies from Vault) are
only accessible to organization admins.
</Warning>
### Step 1: Set Up Your Vault Connection
<Steps>
@@ -84,6 +90,19 @@ This migration approach lets you set up a connection to your Vault instance once
path "auth/+/role/*" {
capabilities = ["read"]
}
# Kubernetes secrets engine - for reading secrets engine configuration and roles
path "+/config" {
capabilities = ["read"]
}
path "+/roles" {
capabilities = ["list"]
}
path "+/roles/*" {
capabilities = ["read"]
}
```
</Accordion>
@@ -160,6 +179,34 @@ The authentication settings (service accounts, TTL, policies, etc.) will be auto
must be manually provided in the form after importing the configuration.
</Note>
#### Import Kubernetes Dynamic Secret Configurations
When creating a Kubernetes dynamic secret, you can import the configuration from a Vault Kubernetes secrets engine role:
1. Navigate to your project and select an environment
2. Click **"+ Add Secret"** dropdown and choose **"Dynamic Secret"**
3. Select **Kubernetes** as the provider
4. Click **"Load from Vault"** at the top of the form
![Load Kubernetes Dynamic Secret from Vault](/images/platform/external-migrations/vault-in-platform/import-vault-kubernetes-role-modal.png)
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
<Note>
Sensitive values like cluster tokens cannot be retrieved from Vault and must
be manually provided in the form after loading the configuration.
</Note>
#### Import and Translate Access Control Policies
When configuring project role-based access control, you can import Vault HCL policies and automatically translate them to Infisical permissions.

91
docs/documentation/platform/gateways-deprecated/gateway-security.mdx
View File

@@ -1,91 +0,0 @@
---
title: "Gateway Security Architecture"
sidebarTitle: "Architecture"
description: "Understand the security model and tenant isolation of Infisical's Gateway"
---
# Gateway Security Architecture
The Infisical Gateway enables Infisical Cloud to securely interact with private resources using mutual TLS authentication and private PKI (Public Key Infrastructure) system to ensure secure, isolated communication between multiple tenants.
This document explains the internal security architecture and how tenant isolation is maintained.
## Security Model Overview
### Private PKI System
Each organization (tenant) in Infisical has its own private PKI system consisting of:
1. **Root CA**: The ultimate trust anchor for the organization
2. **Intermediate CAs**:
- Client CA: Issues certificates for cloud components
- Gateway CA: Issues certificates for gateway instances
This hierarchical structure ensures complete isolation between organizations as each has its own independent certificate chain.
### Certificate Hierarchy
```
Root CA (Organization Specific)
├── Client CA
│ └── Client Certificates (Cloud Components)
└── Gateway CA
└── Gateway Certificates (Gateway Instances)
```
## Communication Security
### 1. Gateway Registration
When a gateway is first deployed:
1. Establishes initial connection using machine identity token
2. Allocates a relay address for communication
3. Exchanges certificates through a secure handshake:
- Gateway receives a unique certificate signed by organization's Gateway CA along with certificate chain for verification
### 2. Mutual TLS Authentication
All communication between gateway and cloud uses mutual TLS (mTLS):
- **Gateway Authentication**:
- Presents certificate signed by organization's Gateway CA
- Certificate contains unique identifiers (Organization ID, Gateway ID)
- Cloud validates complete certificate chain
- **Cloud Authentication**:
- Presents certificate signed by organization's Client CA
- Certificate includes required organizational unit ("gateway-client")
- Gateway validates certificate chain back to organization's root CA
### 3. Relay Communication
The relay system provides secure tunneling:
1. **Connection Establishment**:
- Uses QUIC protocol over UDP for efficient, secure communication
- Provides built-in encryption, congestion control, and multiplexing
- Enables faster connection establishment and reduced latency
- Each organization's traffic is isolated using separate relay sessions
2. **Traffic Isolation**:
- Each gateway gets unique relay credentials
- Traffic is end-to-end encrypted using QUIC's TLS 1.3
- Organization's private keys never leave their environment
## Tenant Isolation
### Certificate-Based Isolation
- Each organization has unique root CA and intermediate CAs
- Certificates contain organization-specific identifiers
- Cross-tenant communication is cryptographically impossible
### Gateway-Project Mapping
- Gateways are explicitly mapped to specific projects
- Access controls enforce organization boundaries
- Project-level permissions determine resource accessibility
### Resource Access Control
1. **Project Verification**:
- Gateway verifies project membership
- Validates organization ownership
- Enforces project-level permissions
2. **Resource Restrictions**:
- Gateways only accept connections to approved resources
- Each connection requires explicit project authorization
- Resources remain private to their assigned organization

BIN
docs/documentation/platform/gateways-deprecated/images/gateway-highlevel-diagram.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 324 KiB

170
docs/documentation/platform/gateways-deprecated/networking.mdx
View File

@@ -1,170 +0,0 @@
---
title: "Networking"
description: "Network configuration and firewall requirements for Infisical Gateway"
---
The Infisical Gateway requires outbound network connectivity to establish secure communication with Infisical's relay infrastructure.
This page outlines the required ports, protocols, and firewall configurations needed for optimal gateway usage.
## Network Architecture
The gateway uses a relay-based architecture to establish secure connections:
1. **Gateway** connects outbound to **Relay Servers** using UDP/QUIC protocol
2. **Relay Servers** facilitate secure communication between Gateway and Infisical Cloud
3. All traffic is end-to-end encrypted using mutual TLS over QUIC
## Required Network Connectivity
### Outbound Connections (Required)
The gateway requires the following outbound connectivity:
| Protocol | Destination | Ports | Purpose |
|----------|-------------|-------|---------|
| UDP | Relay Servers | 49152-65535 | Allocated relay communication (TLS) |
| TCP | app.infisical.com / eu.infisical.com | 443 | API communication and relay allocation |
### Relay Server IP Addresses
Your firewall must allow outbound connectivity to the following Infisical relay servers on dynamically allocated ports.
<Tabs>
<Tab title="Infisical cloud (US)">
```
54.235.197.91:49152-65535
18.215.196.229:49152-65535
3.222.120.233:49152-65535
34.196.115.157:49152-65535
```
</Tab>
<Tab title="Infisical cloud (EU)">
```
3.125.237.40:49152-65535
52.28.157.98:49152-65535
3.125.176.90:49152-65535
```
</Tab>
<Tab title="Infisical dedicated">
Please contact your Infisical account manager for dedicated relay server IP addresses.
</Tab>
</Tabs>
<Warning>
These IP addresses are static and managed by Infisical. Any changes will be communicated with 60-day advance notice.
</Warning>
## Protocol Details
### QUIC over UDP
The gateway uses QUIC (Quick UDP Internet Connections) for primary communication:
- **Port 5349**: STUN/TURN over TLS (secure relay communication)
- **Built-in features**: Connection migration, multiplexing, reduced latency
- **Encryption**: TLS 1.3 with certificate pinning
## Understanding Firewall Behavior with UDP
Unlike TCP connections, UDP is a stateless protocol, and depending on your organization's firewall configuration, you may need to adjust network rules accordingly.
When the gateway sends UDP packets to a relay server, the return responses need to be allowed back through the firewall.
Modern firewalls handle this through "connection tracking" (also called "stateful inspection"), but the behavior can vary depending on your firewall configuration.
### Connection Tracking
Modern firewalls automatically track UDP connections and allow return responses. This is the preferred configuration as it:
- Automatically handles return responses
- Reduces firewall rule complexity
- Avoids the need for manual IP whitelisting
In the event that your firewall does not support connection tracking, you will need to whitelist the relay IPs to explicitly define return traffic manually.
## Common Network Scenarios
### Corporate Firewalls
For corporate environments with strict egress filtering:
1. **Whitelist relay IP addresses** (listed above)
2. **Allow UDP port 5349** outbound
3. **Configure connection tracking** for UDP return traffic
4. **Allow ephemeral port range** 49152-65535 for return traffic if connection tracking is disabled
### Cloud Environments (AWS/GCP/Azure)
Configure security groups to allow:
- **Outbound UDP** to relay IPs on port 5349
- **Outbound HTTPS** to app.infisical.com/eu.infisical.com on port 443
- **Inbound UDP** on ephemeral ports (if not using stateful rules)
## Frequently Asked Questions
<AccordionGroup>
<Accordion title="What happens if there is a network interruption?">
The gateway is designed to handle network interruptions gracefully:
- **Automatic reconnection**: The gateway will automatically attempt to reconnect to relay servers every 5 seconds if the connection is lost
- **Connection retry logic**: Built-in retry mechanisms handle temporary network outages without manual intervention
- **Multiple relay servers**: If one relay server is unavailable, the gateway can connect to alternative relay servers
- **Persistent sessions**: Existing connections are maintained where possible during brief network interruptions
- **Graceful degradation**: The gateway logs connection issues and continues attempting to restore connectivity
No manual intervention is typically required during network interruptions.
</Accordion>
<Accordion title="Why does the gateway use QUIC instead of TCP?">
QUIC (Quick UDP Internet Connections) provides several advantages over traditional TCP for gateway communication:
- **Faster connection establishment**: QUIC combines transport and security handshakes, reducing connection setup time
- **Built-in encryption**: TLS 1.3 is integrated into the protocol, ensuring all traffic is encrypted by default
- **Connection migration**: QUIC connections can survive IP address changes (useful for NAT rebinding)
- **Reduced head-of-line blocking**: Multiple data streams can be multiplexed without blocking each other
- **Better performance over unreliable networks**: Advanced congestion control and packet loss recovery
- **Lower latency**: Optimized for real-time communication between gateway and cloud services
While TCP is stateful and easier for firewalls to track, QUIC's performance benefits outweigh the additional firewall configuration requirements.
</Accordion>
<Accordion title="Do I need to open any inbound ports on my firewall?">
No inbound ports need to be opened. The gateway only makes outbound connections:
- **Outbound UDP** to relay servers on ports 49152-65535
- **Outbound HTTPS** to Infisical API endpoints
- **Return responses** are handled by connection tracking or explicit IP whitelisting
This design maintains security by avoiding the need for inbound firewall rules that could expose your network to external threats.
</Accordion>
<Accordion title="What if my firewall blocks the required UDP ports?">
If your firewall has strict UDP restrictions:
1. **Work with your network team** to allow outbound UDP to the specific relay IP addresses
2. **Use explicit IP whitelisting** if connection tracking is disabled
3. **Consider network policy exceptions** for the gateway host
4. **Monitor firewall logs** to identify which specific rules are blocking traffic
The gateway requires UDP connectivity to function - TCP-only configurations are not supported.
</Accordion>
<Accordion title="How many relay servers does the gateway connect to?">
The gateway connects to **one relay server at a time**:
- **Single active connection**: Only one relay connection is established per gateway instance
- **Automatic failover**: If the current relay becomes unavailable, the gateway will connect to an alternative relay
- **Load distribution**: Different gateway instances may connect to different relay servers for load balancing
- **No manual selection**: The Infisical API automatically assigns the optimal relay server based on availability and proximity
You should whitelist all relay IP addresses to ensure proper failover functionality.
</Accordion>
<Accordion title="Can the relay servers decrypt traffic going through them?">
No, relay servers cannot decrypt any traffic passing through them:
- **End-to-end encryption**: All traffic between the gateway and Infisical Cloud is encrypted using mutual TLS with certificate pinning
- **Relay acts as a tunnel**: The relay server only forwards encrypted packets - it has no access to encryption keys
- **No data storage**: Relay servers do not store any traffic or network-identifiable information
- **Certificate isolation**: Each organization has its own private PKI system, ensuring complete tenant isolation
The relay infrastructure is designed as a secure forwarding mechanism, similar to a VPN tunnel, where the relay provider cannot see the contents of the traffic flowing through it.
</Accordion>
</AccordionGroup>

352
docs/documentation/platform/gateways-deprecated/overview.mdx
View File

@@ -1,352 +0,0 @@
---
title: "Gateway"
sidebarTitle: "Overview"
description: "How to access private network resources from Infisical"
---
![Alt text](/documentation/platform/gateways-deprecated/images/gateway-highlevel-diagram.png)
The Infisical Gateway provides secure access to private resources within your network without needing direct inbound connections to your environment.
This method keeps your resources fully protected from external access while enabling Infisical to securely interact with resources like databases.
Common use cases include generating dynamic credentials or rotating credentials for private databases.
<Info>
Gateway is a paid feature available under the Enterprise Tier for Infisical
Cloud users. Self-hosted Infisical users can contact
[sales@infisical.com](mailto:sales@infisical.com) to purchase an enterprise
license.
</Info>
## How It Works
The Gateway serves as a secure intermediary that facilitates direct communication between the Infisical server and your private network.
It’s a lightweight daemon packaged within the Infisical CLI, making it easy to deploy and manage. Once set up, the Gateway establishes a connection with a relay server, ensuring that all communication between Infisical and your Gateway is fully end-to-end encrypted.
This setup guarantees that only the platform and your Gateway can decrypt the transmitted information, keeping communication with your resources secure, private and isolated.
## Deployment
The Infisical Gateway is seamlessly integrated into the Infisical CLI under the `gateway` command, making it simple to deploy and manage.
You can install the Gateway in all the same ways you install the Infisical CLI—whether via npm, Docker, or a binary.
For detailed installation instructions, refer to the Infisical [CLI Installation instructions](/cli/overview).
To function, the Gateway must authenticate with Infisical. This requires a machine identity configured with the appropriate permissions to create and manage a Gateway.
Once authenticated, the Gateway establishes a secure connection with Infisical to allow your private resources to be reachable.
### Get started
<Steps>
<Step title="Create a Gateway Identity">
1. Navigate to **Organization Access Control** in your Infisical dashboard.
2. Create a dedicated machine identity for your Gateway.
3. **Best Practice:** Assign a unique identity to each Gateway for better security and management.
![Create Gateway Identity](../../../images/platform/gateways/create-identity-for-gateway.png)
</Step>
<Step title="Configure Authentication Method">
You'll need to choose an authentication method to initiate communication with Infisical. View the available machine identity authentication methods [here](/documentation/platform/identities/machine-identities).
</Step>
<Step title="Deploy the Gateway">
Use the Infisical CLI to deploy the Gateway. You can run it directly or install it as a systemd service for production:
<Tabs>
<Tab title="Production (systemd)">
For production deployments on Linux, install the Gateway as a systemd service:
```bash
sudo infisical gateway install --token <your-machine-identity-token> --domain <your-infisical-domain>
sudo systemctl start infisical-gateway
```
This will install and start the Gateway as a secure systemd service that:
- Runs with restricted privileges:
- Runs as root user (required for secure token management)
- Restricted access to home directories
- Private temporary directory
- Automatically restarts on failure
- Starts on system boot
- Manages token and domain configuration securely in `/etc/infisical/gateway.conf`
<Warning>
The install command requires:
- Linux operating system
- Root/sudo privileges
- Systemd
</Warning>
</Tab>
<Tab title="Production (Helm)">
The Gateway can be installed via [Helm](https://helm.sh/). Helm is a package manager for Kubernetes that allows you to define, install, and upgrade Kubernetes applications.
For production deployments on Kubernetes, install the Gateway using the Infisical Helm chart:
### Install the latest Helm Chart repository
```bash
helm repo add infisical-helm-charts 'https://dl.cloudsmith.io/public/infisical/helm-charts/helm/charts/'
```
### Update the Helm Chart repository
```bash
helm repo update
```
### Create a Kubernetes Secret containing gateway environment variables
The gateway supports all identity authentication methods through the use of environment variables.
The environment variables must be set in the `infisical-gateway-environment` Kubernetes secret.
#### Supported authentication methods
<AccordionGroup>
<Accordion title="Universal Auth">
The Universal Auth method is a simple and secure way to authenticate with Infisical. It requires a client ID and a client secret to authenticate with Infisical.
<ParamField query="Environment Variables">
<Expandable title="properties">
<ParamField query="INFISICAL_UNIVERSAL_AUTH_CLIENT_ID" type="string" required>
Your machine identity client ID.
</ParamField>
<ParamField query="INFISICAL_UNIVERSAL_AUTH_CLIENT_SECRET" type="string" required>
Your machine identity client secret.
</ParamField>
<ParamField query="INFISICAL_AUTH_METHOD" type="string" required>
The authentication method to use. Must be `universal-auth` when using Universal Auth.
</ParamField>
</Expandable>
</ParamField>
```bash
kubectl create secret generic infisical-gateway-environment --from-literal=INFISICAL_AUTH_METHOD=universal-auth --from-literal=INFISICAL_UNIVERSAL_AUTH_CLIENT_ID=<client-id> --from-literal=INFISICAL_UNIVERSAL_AUTH_CLIENT_SECRET=<client-secret>
```
</Accordion>
<Accordion title="Native Kubernetes">
The Native Kubernetes method is used to authenticate with Infisical when running in a Kubernetes environment. It requires a service account token to authenticate with Infisical.
<ParamField query="Environment Variables">
<Expandable title="properties">
<ParamField query="INFISICAL_MACHINE_IDENTITY_ID" type="string" required>
Your machine identity ID.
</ParamField>
<ParamField query="INFISICAL_KUBERNETES_SERVICE_ACCOUNT_TOKEN_PATH" type="string" optional>
Path to the Kubernetes service account token to use. Default: `/var/run/secrets/kubernetes.io/serviceaccount/token`.
</ParamField>
<ParamField query="INFISICAL_AUTH_METHOD" type="string" required>
The authentication method to use. Must be `kubernetes` when using Native Kubernetes.
</ParamField>
</Expandable>
</ParamField>
```bash
kubectl create secret generic infisical-gateway-environment --from-literal=INFISICAL_AUTH_METHOD=kubernetes --from-literal=INFISICAL_MACHINE_IDENTITY_ID=<machine-identity-id>
```
</Accordion>
<Accordion title="Native Azure">
The Native Azure method is used to authenticate with Infisical when running in an Azure environment.
<ParamField query="Environment Variables">
<Expandable title="properties">
<ParamField query="INFISICAL_MACHINE_IDENTITY_ID" type="string" required>
Your machine identity ID.
</ParamField>
<ParamField query="INFISICAL_AUTH_METHOD" type="string" required>
The authentication method to use. Must be `azure` when using Native Azure.
</ParamField>
</Expandable>
</ParamField>
```bash
kubectl create secret generic infisical-gateway-environment --from-literal=INFISICAL_AUTH_METHOD=azure --from-literal=INFISICAL_MACHINE_IDENTITY_ID=<machine-identity-id>
```
</Accordion>
<Accordion title="Native GCP ID Token">
The Native GCP ID Token method is used to authenticate with Infisical when running in a GCP environment.
<ParamField query="Environment Variables">
<Expandable title="properties">
<ParamField query="INFISICAL_MACHINE_IDENTITY_ID" type="string" required>
Your machine identity ID.
</ParamField>
<ParamField query="INFISICAL_AUTH_METHOD" type="string" required>
The authentication method to use. Must be `gcp-id-token` when using Native GCP ID Token.
</ParamField>
</Expandable>
</ParamField>
```bash
kubectl create secret generic infisical-gateway-environment --from-literal=INFISICAL_AUTH_METHOD=gcp-id-token --from-literal=INFISICAL_MACHINE_IDENTITY_ID=<machine-identity-id>
```
</Accordion>
<Accordion title="GCP IAM">
The GCP IAM method is used to authenticate with Infisical with a GCP service account key.
<ParamField query="Environment Variables">
<Expandable title="properties">
<ParamField query="INFISICAL_MACHINE_IDENTITY_ID" type="string" required>
Your machine identity ID.
</ParamField>
<ParamField query="INFISICAL_GCP_SERVICE_ACCOUNT_KEY_FILE_PATH" type="string" required>
Path to your GCP service account key file _(Must be in JSON format!)_
</ParamField>
<ParamField query="INFISICAL_AUTH_METHOD" type="string" required>
The authentication method to use. Must be `gcp-iam` when using GCP IAM.
</ParamField>
</Expandable>
</ParamField>
```bash
kubectl create secret generic infisical-gateway-environment --from-literal=INFISICAL_AUTH_METHOD=gcp-iam --from-literal=INFISICAL_MACHINE_IDENTITY_ID=<machine-identity-id> --from-literal=INFISICAL_GCP_SERVICE_ACCOUNT_KEY_FILE_PATH=<service-account-key-file-path>
```
</Accordion>
<Accordion title="Native AWS IAM">
The AWS IAM method is used to authenticate with Infisical with an AWS IAM role while running in an AWS environment like EC2, Lambda, etc.
<ParamField query="Environment Variables">
<Expandable title="properties">
<ParamField query="INFISICAL_MACHINE_IDENTITY_ID" type="string" required>
Your machine identity ID.
</ParamField>
<ParamField query="INFISICAL_AUTH_METHOD" type="string" required>
The authentication method to use. Must be `aws-iam` when using Native AWS IAM.
</ParamField>
</Expandable>
</ParamField>
```bash
kubectl create secret generic infisical-gateway-environment --from-literal=INFISICAL_AUTH_METHOD=aws-iam --from-literal=INFISICAL_MACHINE_IDENTITY_ID=<machine-identity-id>
```
</Accordion>
<Accordion title="OIDC Auth">
The OIDC Auth method is used to authenticate with Infisical via identity tokens with OIDC.
<ParamField query="Environment Variables">
<Expandable title="properties">
<ParamField query="INFISICAL_MACHINE_IDENTITY_ID" type="string" required>
Your machine identity ID.
</ParamField>
<ParamField query="INFISICAL_JWT" type="string" required>
The OIDC JWT from the identity provider.
</ParamField>
<ParamField query="INFISICAL_AUTH_METHOD" type="string" required>
The authentication method to use. Must be `oidc-auth` when using OIDC Auth.
</ParamField>
</Expandable>
</ParamField>
```bash
kubectl create secret generic infisical-gateway-environment --from-literal=INFISICAL_AUTH_METHOD=oidc-auth --from-literal=INFISICAL_MACHINE_IDENTITY_ID=<machine-identity-id> --from-literal=INFISICAL_JWT=<oidc-jwt>
```
</Accordion>
<Accordion title="JWT Auth">
The JWT Auth method is used to authenticate with Infisical via a JWT token.
<ParamField query="Environment Variables">
<Expandable title="properties">
<ParamField query="INFISICAL_JWT" type="string" required>
The JWT token to use for authentication.
</ParamField>
<ParamField query="INFISICAL_MACHINE_IDENTITY_ID" type="string" required>
Your machine identity ID.
</ParamField>
<ParamField query="INFISICAL_AUTH_METHOD" type="string" required>
The authentication method to use. Must be `jwt-auth` when using JWT Auth.
</ParamField>
</Expandable>
</ParamField>
```bash
kubectl create secret generic infisical-gateway-environment --from-literal=INFISICAL_AUTH_METHOD=jwt-auth --from-literal=INFISICAL_JWT=<jwt> --from-literal=INFISICAL_MACHINE_IDENTITY_ID=<machine-identity-id>
```
</Accordion>
<Accordion title="Token Auth">
You can use the `INFISICAL_TOKEN` environment variable to authenticate with Infisical with a raw machine identity access token.
<ParamField query="Environment Variables">
<Expandable title="properties">
<ParamField query="INFISICAL_TOKEN" type="string" required>
The machine identity access token to use for authentication.
</ParamField>
</Expandable>
</ParamField>
```bash
kubectl create secret generic infisical-gateway-environment --from-literal=INFISICAL_TOKEN=<token>
```
</Accordion>
</AccordionGroup>
#### Other environment variables
<AccordionGroup>
<Accordion title="INFISICAL_API_URL">
The API URL to use for the gateway. By default, `INFISICAL_API_URL` is set to `https://app.infisical.com`.
</Accordion>
</AccordionGroup>
### Install the Infisical Gateway Helm Chart
```bash
helm install infisical-gateway infisical-helm-charts/infisical-gateway
```
### Check the gateway logs
After installing the gateway, you can check the logs to ensure it's running as expected.
```bash
kubectl logs deployment/infisical-gateway
```
You should see the following output which indicates the gateway is running as expected.
```bash
$ kubectl logs deployment/infisical-gateway
INF Provided relay port 5349. Using TLS
INF Connected with relay
INF 10.0.101.112:56735
INF Starting relay connection health check
INF Gateway started successfully
INF New connection from: 10.0.1.8:34051
INF Gateway is reachable by Infisical
```
</Tab>
<Tab title="Local Installation (testing)">
For development or testing, you can run the Gateway directly. Log in with your machine identity and start the Gateway in one command:
```bash
infisical gateway --token $(infisical login --method=universal-auth --client-id=<> --client-secret=<> --plain)
```
Alternatively, if you already have the token, use it directly with the `--token` flag:
```bash
infisical gateway --token <your-machine-identity-token>
```
Or set it as an environment variable:
```bash
export INFISICAL_TOKEN=<your-machine-identity-token>
infisical gateway
```
</Tab>
</Tabs>
For detailed information about the gateway command and its options, see the [gateway command documentation](/cli/commands/gateway).
<Note>
Ensure the deployed Gateway has network access to the private resources you intend to connect with Infisical.
</Note>
</Step>
<Step title="Verify Gateway Deployment">
To confirm your Gateway is working, check the deployment status by looking for the message **"Gateway started successfully"** in the Gateway logs. This indicates the Gateway is running properly. Next, verify its registration by opening your Infisical dashboard, navigating to **Organization Access Control**, and selecting the **Gateways** tab. Your newly deployed Gateway should appear in the list.
![Gateway List](../../../images/platform/gateways/gateway-list.png)
</Step>
</Steps>

13
docs/documentation/platform/gateways/relay-deployment.mdx → docs/documentation/platform/gateways/relay-deployment/overview.mdx
View File

@@ -1,5 +1,5 @@
---
title: "Relay Deployment"
title: "Overview"
description: "How to deploy Infisical Relay Servers"
---
@@ -107,13 +107,8 @@ To successfully deploy an Infisical Relay for use, follow these steps in order.
</AccordionGroup>
</Step>
<Step title="Install the Infisical CLI">
Install the Infisical CLI on the server where you plan to deploy the relay. The CLI is required for relay installation and management.
See the [CLI Installation Guide](/cli/overview) for instructions.
This server must have a static IP address or DNS name to be identifiable by the Infisical platform.
<Step title="Provision a Server">
Provision a server or virtual machine where you plan to deploy the relay. This server must have a static IP address or DNS name to be identifiable by the Infisical platform.
</Step>
<Step title="Configure Network & Firewall">
@@ -133,6 +128,8 @@ To successfully deploy an Infisical Relay for use, follow these steps in order.
</Step>
<Step title="Select a Deployment Method">
You can deploy the Infisical Relay in various ways. This guide provides a manual setup example using the Infisical CLI. For an infrastructure-as-code approach, see our [Terraform guide](/documentation/platform/gateways/relay-deployment/terraform).
The Infisical CLI is used to install and start the relay in your chosen environment. The CLI provides commands for both production and development scenarios, and supports a variety of options/flags to configure your deployment.
To view all available flags and equivalent environment variables for relay deployment, see the [Relay CLI Command Reference](/cli/commands/relay).

151
docs/documentation/platform/gateways/relay-deployment/terraform.mdx Normal file
View File

@@ -0,0 +1,151 @@
---
title: "Terraform"
description: "How to deploy Infisical Relay Servers using Terraform"
---
This guide walks you through deploying an Infisical Relay server using Terraform. Select a provider below for specific instructions.
<Tabs>
<Tab title="AWS EC2">
The provided configuration automates the creation of the EC2 instance, sets up the necessary security group rules, and uses a startup script to install and configure the Infisical Relay service.
### Prerequisites
Before you start, make sure you have the following:
- An AWS account with permissions to create EC2 instances, Security Groups, and Elastic IPs.
- An existing VPC and Subnet ID in your desired AWS region.
- The AMI ID for your chosen OS (this guide uses an Ubuntu 22.04 LTS AMI).
- Credentials for the Infisical Relay to authenticate with your Infisical instance. This guide uses a Machine Identity token, but other methods are available. You can find a full list of authentication options [here](/cli/commands/relay#available-authentication-methods).
### Terraform Configuration
Here is the complete Terraform configuration to deploy the Infisical Relay.
```terraform
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}
provider "aws" {
region = "us-west-2" # Change to your desired AWS region
}
# Security Group for the Infisical Relay instance
resource "aws_security_group" "infisical_relay_sg" {
name = "infisical-relay-sg"
description = "Allows inbound traffic for Infisical Relay and SSH"
vpc_id = "vpc-0c71f9c5709d88d18" # Change to your VPC ID
# Inbound: Allows the Infisical platform to securely communicate with the Relay server.
ingress {
from_port = 8443
to_port = 8443
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
# Inbound: Allows Infisical Gateway to securely communicate via the Relay.
ingress {
from_port = 2222
to_port = 2222
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
# Inbound: Allows secure shell (SSH) access for administration.
ingress {
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"] # Restrict this to your IP in production
}
# Outbound: Allows the Relay server to make necessary outbound connections to the Infisical platform.
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
tags = {
Name = "infisical-relay-sg"
}
}
# Elastic IP for a static public IP address
resource "aws_eip" "infisical_relay_eip" {
tags = {
Name = "infisical-relay-eip"
}
}
# EC2 instance to run Infisical Relay
module "infisical_relay_instance" {
source = "terraform-aws-modules/ec2-instance/aws"
version = "~> 5.6"
name = "infisical-relay-example"
ami = "ami-065778886ef8ec7c8" # Change to your desired AMI ID
instance_type = "t3.micro"
subnet_id = "subnet-0fd2337a1c604a494" # Change to your Subnet ID
vpc_security_group_ids = [aws_security_group.infisical_relay_sg.id]
associate_public_ip_address = false # We are using an Elastic IP instead
user_data = <<-EOT
#!/bin/bash
set -e
# Install Infisical CLI
curl -1sLf 'https://artifacts-cli.infisical.com/setup.deb.sh' | bash
apt-get update && apt-get install -y infisical
# Install the relay as a systemd service.
# This example uses a Machine Identity token for authentication via the INFISICAL_TOKEN environment variable.
#
# Note: For production environments, you might consider fetching the token from AWS Parameter Store or AWS Secrets Manager.
export INFISICAL_TOKEN="your-machine-identity-token"
sudo -E infisical relay systemd install \
--name "my-relay-example" \
--domain "https://app.infisical.com" \
--host "${aws_eip.infisical_relay_eip.public_ip}"
# Start and enable the service to run on boot
sudo systemctl start infisical-relay
sudo systemctl enable infisical-relay
EOT
}
# Associate the Elastic IP with the EC2 instance
resource "aws_eip_association" "eip_assoc" {
instance_id = module.infisical_relay_instance.id
allocation_id = aws_eip.infisical_relay_eip.id
}
```
<Warning>
The provided security group rules are open to the internet (`0.0.0.0/0`) for simplicity. In a production environment, you should restrict the `cidr_blocks` to known IP addresses for enhanced security, especially for the SSH port (22).
</Warning>
### How to Deploy
1. **Save the configuration:** Save the code above to a file named `main.tf`.
2. **Customize values:** Update the placeholder values in `main.tf` to match your AWS environment and Infisical credentials. You'll need to replace:
- `region` in the `provider` block.
- `vpc_id` in the `aws_security_group` resource.
- `ami` and `subnet_id` in the `infisical_relay_instance` module.
- The `INFISICAL_TOKEN` environment variable in the `user_data` script (e.g., `export INFISICAL_TOKEN="your-machine-identity-token"`).
- The `--domain` in the `user_data` script if you are self-hosting Infisical.
3. **Apply the configuration:** Run the following Terraform commands in your terminal:
```bash
terraform init
terraform plan
terraform apply
```
</Tab>
</Tabs>

2
docs/documentation/platform/identities/machine-identities.mdx
View File

@@ -13,7 +13,7 @@ Each identity must authenticate with the Infisical API using a supported authent
Key Features:
- Role Assignment: Identities must be assigned [roles](/documentation/platform/role-based-access-controls). These roles determine the scope of access to resources, either at the organization level or project level.
- 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.
## Workflow

2
docs/documentation/platform/kms/hsm-integration.mdx
View File

@@ -1428,7 +1428,7 @@ Enabling HSM encryption has a set of key benefits:
infisical:
image:
repository: infisical/infisical
tag: "v0.151.0-nightly-20251013.1"
tag: "v0.151.0"
pullPolicy: IfNotPresent
extraVolumeMounts:

269
docs/documentation/platform/kms/kmip.mdx
View File

@@ -8,135 +8,256 @@ description: "Learn more about integrating with Infisical KMS using KMIP (Key Ma
sales@infisical.com if you have any questions.
</Note>
## Overview
Infisical KMS provides Key Management Interoperability Protocol (KMIP) support for integration with KMIP-compatible clients. This allows for enhanced key management across various applications that support the KMIP 1.4 protocol.
Infisical KMS provides **Key Management Interoperability Protocol (KMIP)** support, enabling seamless integration with KMIP-compatible clients. This allows for enhanced key management across various applications that support the **KMIP 1.4 protocol**.
## How KMIP Works with Infisical
## Supported Operations
At a high level, the KMIP integration follows this architecture:
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.
![KMIP Architecture Diagram](/images/kmip-diagram.png)
## Benefits of KMIP Integration
At a high level, the KMIP integration works as follows:
Integrating Infisical KMS with KMIP-compatible clients provides the following benefits:
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
- **Standardized Key Management**: Allows interoperability with security and cryptographic applications that support KMIP.
- **Enterprise-Grade Security**: Utilizes Infisical’s encryption mechanisms to securely store and manage keys.
- **Centralized Key Management**: Enables a unified approach for managing cryptographic keys across multiple environments.
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.
## Compatibility
### Supported Operations
Infisical KMIP supports **KMIP versions 1.0 to 1.4**, ensuring compatibility with a wide range of clients and security tools.
The Infisical KMIP server supports the following operations for symmetric keys:
## Secure Communication & Authorization
- **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
KMIP client-server communication is secured using **mutual TLS (mTLS)**, ensuring strong identity verification and encrypted data exchange via **PKI certificates**. Each KMIP entity must possess valid certificates signed by a trusted Root CA to establish trust.
For strong isolation, each Infisical organization has its own KMIP PKI (Public Key Infrastructure), ensuring that cryptographic operations and certificate authorities remain separate across organizations.
### Compatibility
Infisical KMS enforces a **two-layer authorization model** for KMIP operations:
Infisical KMIP supports KMIP versions 1.0 to 1.4, ensuring compatibility with a wide range of clients and security tools.
1. **KMIP Server Authorization** – The KMIP server, acting as a proxy, must have the `proxy KMIP` permission to forward client requests to Infisical KMS. This is done using a **machine identity** attached to the KMIP server.
2. **KMIP Client Authorization** – Clients must have the necessary KMIP-level permissions to perform specific key management operations.
### Network Requirements
By combining **mTLS for secure communication** and **machine identity-based proxying**, Infisical KMS ensures **strong authentication, controlled access, and centralized key management** for KMIP operations.
Ensure the following network connectivity is in place:
## Setup Instructions
- **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.
### Setup KMIP for your organization
- **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:
<Steps>
<Step title="Navigate to the organization settings > KMIP">
From there, press Setup KMIP.
<Step title="Enable KMIP at the Organization Level">
First, you need to enable KMIP for your entire Infisical organization and set up its PKI infrastructure.
Navigate to **Organization Settings > KMIP** and click **Setup KMIP**.
![KMIP org navigate](/images/platform/kms/kmip/kmip-org-setup-navigation.png)
</Step>
<Step title="Configure KMIP PKI for the organization">
In the modal, select the desired key algorithm to use for the KMIP PKI of your organization. Press continue.
In the modal, select the desired key algorithm to use for the KMIP PKI of your organization, then click **Continue**.
![KMIP org PKI setup](/images/platform/kms/kmip/kmip-org-setup-modal.png)
This generates the KMIP PKI for your organization. After this, you can proceed to setting up your KMIP server.
This generates the KMIP PKI for your organization, creating the cryptographic foundation that will be used for secure KMIP communications.
<Info>
You do not need to manage these certificates yourself; Infisical handles the PKI infrastructure for you.
</Info>
</Step>
</Steps>
### Deploying and Configuring the KMIP Server
<Step title="Create a Machine Identity for the KMIP Server">
The KMIP server needs a machine identity to authenticate with Infisical and proxy requests on behalf of clients.
Follow these steps to configure and deploy a KMIP server.
Configure a [machine identity](/documentation/platform/identities/machine-identities#machine-identities) by heading to your organization's **Access Control** and switching over to the **identities** tab.
From there you can click **Create Identity**.
<Steps>
<Step title="Setup Machine Identity">
Configure a [machine identity](https://infisical.com/docs/documentation/platform/identities/machine-identities#machine-identities) for the KMIP server to use.
This guide assumes you'll be using the [Universal Auth](/documentation/platform/identities/universal-auth) method for the machine identity but you can choose any supported authentication method.
![KMIP create machine identity](/images/platform/kms/kmip/kmip-create-mi.png)
This machine identity will be used by the KMIP server to authenticate and forward client requests to Infisical KMS.
</Step>
<Step title="Create a Custom Organization Role with Proxy KMIP Permission">
The machine identity needs permission to proxy KMIP requests.
Create a custom organization role and give it the **Proxy KMIP** permission.
![KMIP create custom role](/images/platform/kms/kmip/kmip-create-custom-role.png)
![KMIP assign proxy to role](/images/platform/kms/kmip/kmip-assign-custom-role-proxy.png)
Assign the machine identity to the custom organization role. This allows the machine identity to serve KMIP client requests and forward them from your KMIP server to Infisical.
![KMIP assign role to machine identity](/images/platform/kms/kmip/kmip-assign-mi-to-role.png)
This permission allows the KMIP server to act as an intermediary between KMIP clients and Infisical.
</Step>
<Step title="Start up the KMIP server">
To deploy the KMIP server, use the Infisical CLI’s `kmip start` command.
Before proceeding, make sure you have the [Infisical CLI installed](https://infisical.com/docs/cli/overview).
<Step title="Assign the Organization Role to the Machine Identity">
Now connect the machine identity to the role you just created.
Once installed, launch the KMIP server with the following command:
Assign the machine identity to the custom organization role.
![KMIP assign role to machine identity](/images/platform/kms/kmip/kmip-assign-mi-to-role.png)
This grants the machine identity the ability to serve KMIP client requests and forward them from your KMIP server to Infisical.
</Step>
<Step title="Deploy the KMIP Server">
Now you're ready to deploy the KMIP server.
You can run the KMIP server on any infrastructure that can reach the Infisical platform, such as a VM or container.
Once you have your infrastructure ready, you'll need to install the Infisical CLI on the server where you want to run the KMIP server.
To install the latest Infisical CLI visit [Infisical CLI instructions](https://infisical.com/docs/cli/overview).
If you need to install specific versions of the CLI, you can find them on the [Infisical CLI GitHub Releases](https://github.com/Infisical/cli/releases).
Then, launch the KMIP server with the following command:
```bash
infisical kmip start \
--identity-client-id=<machine-identity-client-id> \ # This can be set by defining the INFISICAL_UNIVERSAL_AUTH_CLIENT_ID ENV variable
--identity-client-secret=<machine-identity-client-secret> \ # This can be set by defining the INFISICAL_UNIVERSAL_AUTH_CLIENT_SECRET ENV variable
--domain=https://app.infisical.com \
--identity-client-id=example-client-id \
--identity-client-secret=example-client-secret \
--domain=https://my-infisical-instance.com \
--listen-address="0.0.0.0:5696" \
--hostnames-or-ips="my-kmip-server.com"
```
The following flags are available for the `infisical kmip start` command::
- **listen-address** (default: localhost:5696): The address the KMIP server listens on.
- **identity-auth-method** (default: universal-auth): The authentication method for the machine identity.
- **identity-client-id**: The client ID of the machine identity. This can be set by defining the `INFISICAL_UNIVERSAL_AUTH_CLIENT_ID` ENV variable.
- **identity-client-secret**: The client secret of the machine identity. This can be set by defining the `INFISICAL_UNIVERSAL_AUTH_CLIENT_SECRET` ENV variable.
- **server-name** (default: "kmip-server"): The name of the KMIP server.
- **certificate-ttl** (default: "1y"): The duration for which the server certificate is valid.
- **hostnames-or-ips:** A comma-separated list of hostnames or IPs the KMIP server will use (required).
**Available flags:**
- **listen-address** (default: localhost:5696): The address the KMIP server listens on. In most cases you'll want to listen on all interfaces (0.0.0.0:5696)
- **identity-auth-method** (default: universal-auth): The authentication method for the machine identity
- **identity-client-id**: The client ID of the machine identity (can be set via `INFISICAL_UNIVERSAL_AUTH_CLIENT_ID` env var)
- **identity-client-secret**: The client secret of the machine identity (can be set via `INFISICAL_UNIVERSAL_AUTH_CLIENT_SECRET` env var)
- **server-name** (default: "kmip-server"): The name of the KMIP server
- **certificate-ttl** (default: "1y"): The duration for which the server certificate is valid
- **hostnames-or-ips**: The IP address or the hostname of the server where you have deployed the KMIP server.
Once started, your KMIP server is now running and ready to accept client connections. It will authenticate to Infisical using the machine identity and proxy all KMIP operations.
</Step>
</Steps>
### Add and Configure KMIP Clients
<Step title="Navigate to Your KMS Project">
Now that the KMIP server is running, you need to register KMIP clients that will connect to it.
<Steps>
<Step title="Navigate to the desired KMS project and select KMIP">
From there, press Add KMIP Client
Navigate to the desired KMS project if you already have one or create a new project of type KMS, then select **KMIP** once inside the project, and click **Add KMIP Client**.
![KMIP client overview](/images/platform/kms/kmip/kmip-client-overview.png)
</Step>
<Step title="Configure KMIP client">
In the modal, provide the details of your client. The selected permissions determine what KMIP operations can be performed in your KMS project.
<Step title="Configure the KMIP Client">
Define the client and its permissions.
In the modal, provide the details of your client. The selected permissions determine what KMIP operations (Create, Get, Revoke, etc.) can be performed in your KMS project.
![KMIP client modal](/images/platform/kms/kmip/kmip-client-modal.png)
This creates a KMIP client entity in Infisical that will be authenticated via mTLS certificates.
</Step>
<Step title="Generate client certificate">
Once the KMIP client is created, you will have to generate a client certificate.
Press Generate Certificate.
<Step title="Generate Client Certificate">
Each KMIP client needs its own certificate for mTLS authentication.
Click **Generate Certificate** for your newly created client.
![KMIP generate client cert](/images/platform/kms/kmip/kmip-client-generate-cert.png)
Provide the desired TTL and key algorithm to use and press Generate Client Certificate.
Provide the desired TTL (time-to-live) and key algorithm, then click **Generate Client Certificate**.
![KMIP client cert config](/images/platform/kms/kmip/kmip-client-cert-config-modal.png)
Configure your KMIP clients to use the generated client certificate, certificate chain and private key.
Download the generated client certificate, certificate chain, and private key.
![KMIP client cert modal](/images/platform/kms/kmip/kmip-client-certificate-modal.png)
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.
</Step>
</Steps>
## Additional Resources
## Connecting your KMIP Client to Infisical
- [KMIP 1.4 Specification](http://docs.oasis-open.org/kmip/spec/v1.4/os/kmip-spec-v1.4-os.html)
After completing the setup, configure your KMIP compatible application to connect to the KMIP server.
While exact configuration steps vary by application, you'll generally need to provide:
1. **KMIP Server Address**: The hostname or IP and port where your KMIP server is listening (e.g., `my-kmip-server.com:5696`)
2. **Client Certificates**: The certificate credentials generated from your Infisical KMS project:
- **Client Certificate** (`client-cert.pem`) - Identifies your KMIP client
- **Client Private Key** (`client-key.pem`) - Used for mTLS authentication
- **Certificate Chain** (`cert-chain.pem`) - Verifies the KMIP server
### General Configuration Steps
<Steps>
<Step title="Identify Your KMIP Server Endpoint">
Determine the address where your KMIP server is accessible. This should match one of the hostnames or IPs you specified when starting the KMIP server with the `--hostnames-or-ips` flag.
**Example endpoints:**
- `my-kmip-server.com:5696`
- `10.0.1.50:5696`
- `kmip.example.com:5696`
The default port is `5696`, but this can be changed using the `--listen-address` flag when starting the server.
</Step>
<Step title="Prepare Certificate Files">
Organize the certificate materials you downloaded when generating the client certificate from the Infisical KMS project. You should have three files:
- **client-cert.pem** - The client certificate
- **cert-chain.pem** - The certificate chain (includes intermediate and root CA certificates)
- **client-key.pem** - The private key
Most KMIP clients require these files in PEM format, which is what Infisical provides by default.
</Step>
<Step title="Configure Your KMIP Client Application">
The exact configuration steps vary depending on your KMIP client application. Generally, you'll need to specify:
**Common configuration parameters:**
- **Server hostname/IP**: Your KMIP server address (e.g., `my-kmip-server.com`)
- **Server port**: Default is `5696`
- **Client certificate**: Path to `client-cert.pem`
- **Client private key**: Path to `client-key.pem`
- **CA certificate**: Path to `cert-chain.pem` (used to verify the server)
- **Protocol version**: KMIP 1.0 through 1.4 are supported
**Example configuration for PyKMIP:**
```ini
[client]
host=my-kmip-server.com
port=5696
certfile=/path/to/client-cert.pem
keyfile=/path/to/client-key.pem
ca_certs=/path/to/cert-chain.pem
```
</Step>
<Step title="Test the Connection">
Once configured, test the connection by performing a simple KMIP operation, such as:
- Querying server capabilities
- Creating a test key
- Listing available keys
If the connection is successful, your KMIP client is now integrated with Infisical KMS and can perform key management operations according to the permissions you assigned.
**Troubleshooting connection issues:**
- Verify network connectivity between your KMIP client and the KMIP server
- Check that certificate files are readable and in the correct format
- Ensure the KMIP server is running and accessible
- Review KMIP server logs for authentication errors
- Confirm the client certificate has not expired
If you require further verification of your certificate details and connectivity to the KMIP server from your KMIP client, you can use the following command from your client machine:
```bash
openssl s_client -connect kmip-server-ip-here:5696 --cert /path/to/client-cert.pem --key /path/to/client-cert.pem --CAfile /path/to/cert-chain.pem --tls1_2 --showcerts --state --debug
```
This command attempts to establish a TLS connection to the KMIP server using your client certificate and key, displaying detailed information about the handshake process.
If the connection is successful, you'll see the server's certificate chain and a message indicating that the handshake was completed.
</Step>
</Steps>

45
docs/documentation/platform/pam/overview.mdx Normal file
View File

@@ -0,0 +1,45 @@
---
title: "Infisical PAM"
sidebarTitle: "Overview"
description: "Learn how to manage access to resources like databases, servers, and accounts with policy-based controls and approvals."
---
Infisical Privileged Access Management (PAM) provides a centralized way to manage and secure access to your critical infrastructure. It allows you to enforce fine-grained, policy-based controls over resources like databases, servers, and more, ensuring that only authorized users can access sensitive systems, and only when they need to.
### How it Works
Infisical PAM employs a resource-based model to organize and manage access. This model is designed to be intuitive and scalable.
#### 1. Create a Resource
The first step is to define a resource you want to manage. A resource represents a target system, such as a PostgreSQL database. When creating a resource, you'll provide the necessary connection details, like the host and port.
![Create Resource](/images/pam/overview/create-resource.png)
#### 2. Add Accounts to the Resource
Once a resource is created, you can add accounts to it. An account represents a specific set of credentials (e.g., a username and password) that can be used to access the resource. This allows you to manage multiple sets of credentials for a single database or server from one place.
![Create Account](/images/pam/overview/create-account.png)
### Infisical PAM Features
#### Session Logging and Auditing
- **Session Logging**: All user sessions are extensively logged, providing a detailed and searchable record of activities performed during a session.
- **Audit Logging**: Every significant event, such as a user starting a session or accessing an account's credentials, is recorded in audit logs. This gives you complete visibility over your project.
![Session Page](/images/pam/overview/session-page.png)
#### Automated Credential Rotation
Infisical PAM can automatically rotate account credentials to enhance your security posture.
Here’s how it works:
1. **Add a Rotation Account**: On the resource level, you configure a "rotation account." This is a master or privileged account that has the necessary permissions to change the passwords of other accounts on that same resource.
![Credential Rotation Account](/images/pam/overview/credential-rotation-account.png)
2. **Configure Rotation on Accounts**: For each individual account you want to rotate, you can simply enable rotation and set a desired interval (e.g., every 30 days).
![Rotate Credentials Account](/images/pam/overview/rotate-credentials-account.png)
Infisical will then use the rotation account on the resource to automatically update the credentials of the target account at the specified interval, eliminating credential staleness.

1
docs/documentation/platform/project.mdx
View File

@@ -22,6 +22,7 @@ The supported project types are:
- [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

BIN
docs/images/app-connections/github/create-pat-form.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 294 KiB

BIN
docs/images/app-connections/github/create-pat-method.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 343 KiB

BIN
docs/images/app-connections/github/create-pat-token-generated.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 211 KiB

BIN
docs/images/app-connections/github/pat-connection.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 154 KiB

BIN
docs/images/app-connections/gitlab/gitlab-group-access-token-created.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 305 KiB

BIN
docs/images/app-connections/gitlab/gitlab-group-access-token-form-secret-sync.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 424 KiB

BIN
docs/images/app-connections/gitlab/gitlab-group-access-token-list.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 261 KiB

BIN
docs/images/app-connections/northflank/northflank-app-connection-form.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 124 KiB

BIN
docs/images/app-connections/northflank/northflank-app-connection-generated.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 98 KiB

BIN
docs/images/app-connections/northflank/northflank-app-connection-option.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 167 KiB

BIN
docs/images/app-connections/northflank/step-1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 254 KiB

BIN
docs/images/app-connections/northflank/step-2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 174 KiB

BIN
docs/images/app-connections/northflank/step-3.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 207 KiB

BIN
docs/images/app-connections/northflank/step-4-1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 194 KiB

BIN
docs/images/app-connections/northflank/step-4-2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 178 KiB

BIN
docs/images/app-connections/northflank/step-5.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 172 KiB

BIN
docs/images/app-connections/northflank/step-6.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 178 KiB

BIN
docs/images/app-connections/northflank/step-7.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 154 KiB

BIN
docs/images/integrations/github/integrations-github-config-new-pat.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 147 KiB

BIN
docs/images/kmip-diagram.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 67 KiB

BIN
docs/images/pam/overview/create-account.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 136 KiB

BIN
docs/images/pam/overview/create-resource.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 148 KiB

BIN
docs/images/pam/overview/credential-rotation-account.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 598 KiB

BIN
docs/images/pam/overview/rotate-credentials-account.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 577 KiB

BIN
docs/images/pam/overview/session-page.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.1 MiB

BIN
docs/images/platform/external-migrations/vault-in-platform/import-vault-kubernetes-role-modal.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 408 KiB

BIN
docs/images/platform/gateways/assign-project.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 338 KiB

BIN
docs/images/platform/gateways/create-identity-for-gateway.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 375 KiB

BIN
docs/images/platform/gateways/dynamic-secret.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 384 KiB

BIN
docs/images/platform/gateways/edit-gateway.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 365 KiB

BIN
docs/images/platform/gateways/gateway-list.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 433 KiB

BIN
docs/images/secret-syncs/northflank/configure-destination.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 129 KiB

BIN
docs/images/secret-syncs/northflank/configure-details.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 114 KiB

BIN
docs/images/secret-syncs/northflank/configure-source.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 107 KiB

BIN
docs/images/secret-syncs/northflank/configure-sync-options.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 132 KiB

BIN
docs/images/secret-syncs/northflank/review-configuration.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 131 KiB

BIN
docs/images/secret-syncs/northflank/select-option.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 142 KiB

BIN
docs/images/secret-syncs/northflank/sync-created.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 105 KiB

69
docs/integrations/app-connections/github.mdx
View File

@@ -3,7 +3,7 @@ title: "GitHub Connection"
description: "Learn how to configure a GitHub Connection for Infisical."
---
Infisical supports two methods for connecting to GitHub.
Infisical supports three methods for connecting to GitHub.
<Tabs>
<Tab title="GitHub App (Recommended)">
@@ -178,5 +178,72 @@ Infisical supports two methods for connecting to GitHub.
</Step>
</Steps>
</Tab>
<Tab title="Personal Access Token">
Infisical will use a Personal Access Token to connect to GitHub.
## Create a Personal Access Token
<Steps>
<Step title="Create a Personal Access Token in GitHub">
Navigate to your user Settings > Developer settings > Personal Access Tokens to create a new Personal Access Token.
![integrations github config](../../images/integrations/github/integrations-github-config-settings.png)
![integrations github config](../../images/integrations/github/integrations-github-config-dev-settings.png)
![integrations github config](../../images/integrations/github/integrations-github-config-new-pat.png)
Click **Generate new token** to create the token.
</Step>
<Step title="Fill in the Personal Access Token details">
Fill in the Personal Access Token details:
- **Token name:** A descriptive name for the token (e.g., "infisical-connection-token")
- **Repository access:** Select the repositories you want to grant access to
- Select `All repositories` or `Only selected repositories` to be able to manage the secrets in the selected repositories.
- **Select scopes:** Add the following scopes:
- **Metadata**: Read-only
- **Environments**: Read and write
- **Secrets**: Read and write
![Personal Access Token Form](/images/app-connections/github/create-pat-form.png)
Click **Generate token** to create the token.
</Step>
<Step title="Copy the Personal Access Token">
Copy the generated token immediately as it won't be shown again.
![Personal Access Token Generated](/images/app-connections/github/create-pat-token-generated.png)
<Warning>
Keep your Personal Access Token secure and do not share it. Anyone with access to this token can access your GitHub account and repositories.
</Warning>
</Step>
</Steps>
## Setup GitHub Connection in Infisical
<Steps>
<Step title="Navigate to App Connections">
Navigate to the **App Connections** page in the desired project.
![App Connections Tab](/images/app-connections/general/add-connection.png)
</Step>
<Step title="Add Connection">
Select the **GitHub Connection** option from the connection options modal.
![Select GitHub Connection](/images/app-connections/github/select-github-connection.png)
</Step>
<Step title="Authorize Connection">
Select the **Personal Access Token** method and fill in the **Personal Access Token** field with your Personal Access Token.
You may optionally configure GitHub Enterprise options:
- **Gateway:** The gateway connected to your private network
- **Hostname:** The hostname at which to access your GitHub Enterprise instance
Click **Create Connection**.
![Personal Access Token](/images/app-connections/github/create-pat-method.png)
</Step>
<Step title="Connection Created">
Your **GitHub Connection** is now available for use.
![Personal Access Token Connection](/images/app-connections/github/pat-connection.png)
</Step>
</Steps>
</Tab>
</Tabs>

103
docs/integrations/app-connections/gitlab.mdx
View File

@@ -187,31 +187,92 @@ Infisical supports two methods for connecting to GitLab: **OAuth** and **Access
</Step>
</Steps>
</Tab>
</Tabs>
## Setup GitLab Access Token Connection in Infisical
<Tab title="Group Access Token">
Group access tokens provide access to all projects within a GitLab group, offering group-level control.
<Steps>
<Step title="Navigate to App Connections">
Navigate to the **App Connections** page in the desired project.
![App Connections Tab](/images/app-connections/general/add-connection.png)
</Step>
<Step title="Add Connection">
Select the **GitLab Connection** option from the connection options modal.
![Select GitLab Connection](/images/app-connections/gitlab/select-gitlab-connection.png)
</Step>
<Step title="Configure Access Token">
Select the **Access Token** method, paste your GitLab access token in the provided field, and select the appropriate token type.
<Steps>
<Step title="Navigate to Group Settings">
Go to your GitLab group and navigate to Settings > Access Tokens. Click **Add new token** to create a new group access token.
![GitLab Group Access Tokens](/images/app-connections/gitlab/gitlab-group-access-token-list.png)
</Step>
<Step title="Configure Token">
Fill in the token details:
- **Token name**: A descriptive name for the token
- **Expiration date**: Set an appropriate expiration date
- **Select role and scopes**: Depending on your use case, add the required role and one or more of the following scopes:
![Configure Access Token](/images/app-connections/gitlab/create-gitlab-access-token-connection.png)
<Tabs>
<Tab title="Secret Sync">
For Secret Syncs, the required role depends on your sync destination:
- **Project variables**: Requires **Maintainer** role or higher
- **Group variables**: Requires **Owner** role
Click **Connect** to establish the connection.
</Step>
<Step title="Connection Created">
Your **GitLab Connection** is now available for use.
![GitLab Access Token Connection](/images/app-connections/gitlab/gitlab-access-token-connection.png)
</Step>
</Steps>
Your token will require the `api` scope.
![GitLab Create Group Token](/images/app-connections/gitlab/gitlab-group-access-token-form-secret-sync.png)
Click **Create group access token** to create the token.
<Note>
Use the **Owner** role if you need to sync to group-level variables. The **Maintainer** role is sufficient only for project-level variables.
</Note>
</Tab>
<Tab title="Secret Scanning">
To set up Secret Scanning, the required permissions depend on the data source level:
- **Project-level data source:** Requires **Maintainer** role or higher
- **Group-level data source:** Requires **Owner** role
Your token will require the `api` scope.
![GitLab Create Group Token](/images/app-connections/gitlab/gitlab-group-access-token-form-secret-sync.png)
Click **Create group access token** to create the token.
</Tab>
</Tabs>
<Info>
Group Access Token connections require manual token rotation when your GitLab access token expires or is regenerated. Monitor your connection status and update the token as needed.
</Info>
</Step>
<Step title="Copy Token">
Copy the generated token immediately as it won't be shown again.
![GitLab Group Token Created](/images/app-connections/gitlab/gitlab-group-access-token-created.png)
<Warning>
Keep your access token secure and do not share it. Anyone with access to this token can access all projects within your GitLab group.
</Warning>
</Step>
</Steps>
</Tab>
</Tabs>
## Setup GitLab Access Token Connection in Infisical
<Steps>
<Step title="Navigate to App Connections">
Navigate to the **App Connections** page in the desired project.
![App Connections Tab](/images/app-connections/general/add-connection.png)
</Step>
<Step title="Add Connection">
Select the **GitLab Connection** option from the connection options modal.
![Select GitLab Connection](/images/app-connections/gitlab/select-gitlab-connection.png)
</Step>
<Step title="Configure Access Token">
Select the **Access Token** method, paste your GitLab access token in the provided field, and select the appropriate token type.
![Configure Access Token](/images/app-connections/gitlab/create-gitlab-access-token-connection.png)
Click **Connect** to establish the connection.
</Step>
<Step title="Connection Created">
Your **GitLab Connection** is now available for use.
![GitLab Access Token Connection](/images/app-connections/gitlab/gitlab-access-token-connection.png)
</Step>
</Steps>
</Tab>
</Tabs>

125
docs/integrations/app-connections/northflank.mdx Normal file
View File

@@ -0,0 +1,125 @@
---
title: "Northflank Connection"
description: "Learn how to configure a Northflank Connection for Infisical."
---
Infisical supports the use of [API Tokens](https://northflank.com/docs/v1/api/use-the-api) to connect with Northflank.
<Tip>
Infisical recommends creating a specific API role for the app connection and only giving access to projects that will use the integration.
</Tip>
## Create a Northflank API Token
<Steps>
<Step title="Create an API Role">
Navigate to your team page and click **Create token**.
![Create API Role](/images/app-connections/northflank/step-1.png)
Click on **Create API role**.
![Create API Role](/images/app-connections/northflank/step-2.png)
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.
![Create API Role](/images/app-connections/northflank/step-3.png)
Add the **Projects** -> **Manage** -> **Read** permission.
![Create API Role](/images/app-connections/northflank/step-4-1.png)
Add the **Config & Secrets** -> **Secret Groups** -> **List**, **Update** and **Read Values** permissions.
![Create API Role](/images/app-connections/northflank/step-4-2.png)
Scroll to the bottom and save the API role.
</Step>
<Step title="Create an API Token">
Click on the **API** -> **Tokens** menu on the left and then click the **Create API token** button.
![Create API Token](/images/app-connections/northflank/step-5.png)
Give a name to the API token and click the **Use role** button for the new API role you just created.
![Create API Token](/images/app-connections/northflank/step-6.png)
Click the **View API token** icon to view and copy your token.
![Create API Token](/images/app-connections/northflank/step-7.png)
</Step>
</Steps>
## Create a Northflank Connection in Infisical
<Tabs>
<Tab title="Infisical UI">
<Steps>
<Step title="Navigate to App Connections">
In your Infisical dashboard, navigate to the **App Connections** page in the desired project.
![App Connections Tab](/images/app-connections/general/add-connection.png)
</Step>
<Step title="Select Northflank Connection">
Click **+ Add Connection** and choose **Northflank Connection** from the list of integrations.
![Select Northflank Connection](/images/app-connections/northflank/northflank-app-connection-option.png)
</Step>
<Step title="Fill out the Northflank Connection form">
Complete the form by providing:
- A descriptive name for the connection
- An optional description
- The API Token from the previous step
![Northflank Connection Modal](/images/app-connections/northflank/northflank-app-connection-form.png)
</Step>
<Step title="Connection created">
After submitting the form, your **Northflank Connection** will be successfully created and ready to use with your Infisical project.
![Northflank Connection Created](/images/app-connections/northflank/northflank-app-connection-generated.png)
</Step>
</Steps>
</Tab>
<Tab title="API">
To create a Northflank Connection via API, send a request to the [Create Northflank Connection](/api-reference/endpoints/app-connections/northflank/create) endpoint.
### Sample request
```bash Request
curl --request POST \
--url https://app.infisical.com/api/v1/app-connections/northflank \
--header 'Content-Type: application/json' \
--data '{
"name": "my-northflank-connection",
"method": "api-token",
"projectId": "abcdef12-3456-7890-abcd-ef1234567890",
"credentials": {
"apiToken": "[API TOKEN]"
}
}'
```
### Sample response
```bash Response
{
"appConnection": {
"id": "a1b2c3d4-5678-90ab-cdef-1234567890ab",
"name": "my-northflank-connection",
"description": null,
"projectId": "abcdef12-3456-7890-abcd-ef1234567890",
"version": 1,
"orgId": "abcdef12-3456-7890-abcd-ef1234567890",
"createdAt": "2025-01-23T10:15:00.000Z",
"updatedAt": "2025-01-23T10:15:00.000Z",
"isPlatformManagedCredentials": false,
"credentialsHash": "d41d8cd98f00b204e9800998ecf8427e",
"app": "northflank",
"method": "api-token",
"credentials": {}
}
}
```
</Tab>
</Tabs>

1
docs/integrations/platforms/kubernetes-injector.mdx
View File

@@ -63,6 +63,7 @@ The Infisical Agent Injector supports the following annotations:
- `init`: The init method will create an init container for the pod that will render the secrets into a shared volume mount within the pod. The agent init container will run before any other containers in the pod runs, including other init containers.
- `sidecar`: The sidecar method will create a sidecar container for the pod that will render the secrets into a shared volume mount within the pod. The agent sidecar container will run alongside the main container in the pod. This means that the secrets rendered will always be in sync with your Infisical secrets.
- `sidecar-init`: The sidecar-init method will create the init container and the sidecar container from the other two methods. The init container will run before any other container and fetch the secrets from the start and the sidecar container will keep the secrets in sync throughout the lifecycle of the deployment.
</Accordion>
<Accordion title="org.infisical.com/agent-config-map">
The agent config map annotation is used to specify the name of the config map that contains the configuration for the injector. The config map must be in the same namespace as the pod.

58
docs/integrations/platforms/kubernetes/overview.mdx
View File

@@ -41,6 +41,29 @@ If you require stronger isolation and stricter access controls, a namespace-scop
```bash
helm install --generate-name infisical-helm-charts/secrets-operator
```
<Accordion title="Using your own service account">
By default a service account is created for the operator based on the operator release name.
You can bring your own service account by setting `controllerManager.serviceAccount.create` to `false` and setting `controllerManager.serviceAccount.name` to the name of the service account you want to use in your values.yaml file.
Example values.yaml file:
```yaml values.yaml
controllerManager:
serviceAccount:
create: false
name: my-service-account
# other values...
```
<Note>
Please note that if you set `controllerManager.serviceAccount.create` to `false`, the service account needs to already exist in the namespace you are installing the operator in.
</Note>
<Tip>
Custom service accounts are supported in chart version `0.10.11` and above. Please upgrade your helm chart to `0.10.11` or above before attempting to use custom service accounts.
</Tip>
</Accordion>
</Tab>
<Tab title="Namespace Scoped Installation">
The operator can be configured to watch and manage secrets in a specific namespace instead of having cluster-wide access. This is useful for:
@@ -67,6 +90,29 @@ If you require stronger isolation and stricter access controls, a namespace-scop
--set installCRDs=false
```
<Accordion title="Using your own service account">
By default a service account is created for the operator based on the operator release name.
You can bring your own service account by setting `controllerManager.serviceAccount.create` to `false` and setting `controllerManager.serviceAccount.name` to the name of the service account you want to use in your values.yaml file.
Example values.yaml file:
```yaml values.yaml
controllerManager:
serviceAccount:
create: false
name: my-service-account
# other values...
```
<Note>
Please note that if you set `controllerManager.serviceAccount.create` to `false`, the service account needs to already exist in the namespace you are installing the operator in.
</Note>
<Tip>
Custom service accounts are supported in chart version `0.10.11` and above. Please upgrade your helm chart to `0.10.11` or above before attempting to use custom service accounts.
</Tip>
</Accordion>
When scoped to a namespace, the operator will:
- Only watch InfisicalSecrets in the specified namespace
@@ -158,14 +204,17 @@ The Infisical Secrets Operator integrates with the [Sprig library](https://githu
## Global configuration
To configure global settings that will apply to all instances of `InfisicalSecret`, you can define these configurations in a Kubernetes ConfigMap.
For example, you can configure all `InfisicalSecret` instances to fetch secrets from a single backend API without specifying the `hostAPI` parameter for each instance.
To configure global settings that will apply to all CRD instances (`InfisicalSecret`, `InfisicalPushSecret`, and `InfisicalDynamicSecret`), you can define these configurations in a Kubernetes ConfigMap.
For example, you can configure all CRD instances to fetch secrets from a single backend API without specifying the `hostAPI` parameter for each instance.
### Available global properties
| Property | Description | Default value |
| -------- | --------------------------------------------------------------------------------- | ----------------------------- |
| hostAPI | If `hostAPI` in `InfisicalSecret` instance is left empty, this value will be used | https://app.infisical.com/api |
| hostAPI | If `hostAPI` in a CRD instance is left empty, this value will be used | https://app.infisical.com/api |
| tls.caRef.secretName | If `tls.caRef.secretName` in a CRD instance is left empty, this value will be used | - |
| tls.caRef.secretNamespace | If `tls.caRef.secretNamespace` in a CRD instance is left empty, this value will be used | - |
| tls.caRef.key | If `tls.caRef.key` in a CRD instance is left empty, this value will be used | - |
### Applying global configurations
@@ -185,6 +234,9 @@ metadata:
namespace: infisical-operator-system
data:
hostAPI: https://example.com/api # <-- global hostAPI
tls.caRef.secretName: custom-ca-certificate # <-- global TLS CA secret name
tls.caRef.secretNamespace: default # <-- global TLS CA secret namespace
tls.caRef.key: ca.crt # <-- global TLS CA secret key
```
Then apply this change via kubectl by running the following

160
docs/integrations/secret-syncs/northflank.mdx Normal file
View File

@@ -0,0 +1,160 @@
---
title: "Northflank Sync"
description: "Learn how to configure a Northflank Sync for Infisical."
---
**Prerequisites:**
- Create a [Northflank Connection](/integrations/app-connections/northflank)
<Tabs>
<Tab title="Infisical UI">
<Steps>
<Step title="Add Sync">
Navigate to **Project** > **Integrations** and select the **Secret Syncs** tab. Click on the **Add Sync** button.
![Secret Syncs Tab](/images/secret-syncs/general/secret-sync-tab.png)
</Step>
<Step title="Select 'Northflank'">
![Select Northflank](/images/secret-syncs/northflank/select-option.png)
</Step>
<Step title="Configure source">
Configure the **Source** from where secrets should be retrieved, then click **Next**.
![Configure Source](/images/secret-syncs/northflank/configure-source.png)
- **Environment**: The project environment to retrieve secrets from.
- **Secret Path**: The folder path to retrieve secrets from.
<Tip>
If you need to sync secrets from multiple folder locations, check out [secret imports](/documentation/platform/secret-reference#secret-imports).
</Tip>
</Step>
<Step title="Configure destination">
Configure the **Destination** to where secrets should be deployed, then click **Next**.
![Configure Destination](/images/secret-syncs/northflank/configure-destination.png)
- **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.
</Step>
<Step title="Configure sync options">
Configure the **Sync Options** to specify how secrets should be synced, then click **Next**.
![Configure Sync Options](/images/secret-syncs/northflank/configure-sync-options.png)
- **Initial Sync Behavior**: Determines how Infisical should resolve the initial sync.
- **Overwrite Destination Secrets**: Removes any secrets at the destination endpoint not present in Infisical.
- **Import 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.
<Note>
We highly recommend using a Key Schema to ensure that Infisical only manages the specific keys you intend, keeping everything else untouched.
</Note>
- **Auto-Sync Enabled**: If enabled, secrets will automatically be synced from the source location when changes occur. Disable to enforce manual syncing only.
- **Disable Secret Deletion**: If enabled, Infisical will not remove secrets from the sync destination. Enable this option if you intend to manage some secrets manually outside of Infisical.
</Step>
<Step title="Configure details">
Configure the **Details** of your Northflank Sync, then click **Next**.
![Configure Details](/images/secret-syncs/northflank/configure-details.png)
- **Name**: The name of your sync. Must be slug-friendly.
- **Description**: An optional description for your sync.
</Step>
<Step title="Review configuration">
Review your Northflank Sync configuration, then click **Create Sync**.
![Review Configuration](/images/secret-syncs/northflank/review-configuration.png)
</Step>
<Step title="Sync created">
If enabled, your Northflank Sync will begin syncing your secrets to the destination endpoint.
![Sync Created](/images/secret-syncs/northflank/sync-created.png)
</Step>
</Steps>
</Tab>
<Tab title="API">
To create a **Northflank Sync**, make an API request to the [Create Northflank Sync](/api-reference/endpoints/secret-syncs/northflank/create) API endpoint.
### Sample request
```bash Request
curl --request POST \
--url https://app.infisical.com/api/v1/secret-syncs/northflank \
--header 'Content-Type: application/json' \
--data '{
"name": "my-northflank-sync",
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"description": "an example sync",
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"environment": "dev",
"secretPath": "/my-secrets",
"isAutoSyncEnabled": true,
"syncOptions": {
"initialSyncBehavior": "overwrite-destination",
"keySchema": "INFISICAL_{{secretKey}}"
},
"destinationConfig": {
"projectId": "my-project-id",
"secretGroupId": "my-secret-group-id"
}
}'
```
### Sample response
```json Response
{
"secretSync": {
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"name": "my-northflank-sync",
"description": "an example sync",
"isAutoSyncEnabled": true,
"version": 1,
"folderId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"createdAt": "2023-11-07T05:31:56Z",
"updatedAt": "2023-11-07T05:31:56Z",
"syncStatus": "succeeded",
"lastSyncJobId": "123",
"lastSyncMessage": null,
"lastSyncedAt": "2023-11-07T05:31:56Z",
"importStatus": null,
"lastImportJobId": null,
"lastImportMessage": null,
"lastImportedAt": null,
"removeStatus": null,
"lastRemoveJobId": null,
"lastRemoveMessage": null,
"lastRemovedAt": null,
"syncOptions": {
"initialSyncBehavior": "overwrite-destination",
"keySchema": "INFISICAL_{{secretKey}}",
"disableSecretDeletion": false
},
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"connection": {
"app": "northflank",
"name": "my-northflank-connection",
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a"
},
"environment": {
"slug": "dev",
"name": "Development",
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a"
},
"folder": {
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"path": "/my-secrets"
},
"destination": "northflank",
"destinationConfig": {
"projectId": "my-project-id",
"secretGroupId": "my-secret-group-id"
}
}
}
```
</Tab>
</Tabs>

65
docs/sdks/languages/python.mdx
View File

@@ -72,6 +72,7 @@ The SDK methods are organized into the following high-level categories:
1. `auth`: Handles authentication methods.
2. `secrets`: Manages CRUD operations for secrets.
3. `kms`: Perform cryptographic operations with Infisical KMS.
4. `folders`: Manages folder-related operations.
### `auth`
@@ -415,4 +416,66 @@ decrypted_data = client.kms.decrypt_data(
- `ciphertext` (str): The ciphertext returned from the encrypt operation.
**Returns:**
- `str`: The base64 encoded plaintext.
- `str`: The base64 encoded plaintext.
### `folders`
This sub-class handles operations related to folders:
#### List Folders
```python
folders = client.folders.list_folders(
project_id="<project-id>",
environment_slug="dev",
path="/",
recursive=False, # Optional
last_secret_modified=None # Optional
)
```
**Parameters:**
- `project_id` (str): The ID of your project.
- `environment_slug` (str): The environment in which to list folders.
- `path` (str): The path to list folders from.
- `recursive` (bool, optional): Whether to list folders recursively from the specified path and downwards. Defaults to `False`.
- `last_secret_modified` (datetime, optional): The timestamp used to filter folders with secrets modified after the specified date. Defaults to `None`.
**Returns:**
- `ListFoldersResponse`: The response containing the list of folders.
#### Create Folder
```python
new_folder = client.folders.create_folder(
name="my-folder",
environment_slug="dev",
project_id="<project-id>",
path="/", # Optional
description=None # Optional
)
```
**Parameters:**
- `name` (str): The name of the folder to create.
- `environment_slug` (str): The slug of the environment to create the folder in.
- `project_id` (str): The ID of your project to create the folder in.
- `path` (str, optional): The path to create the folder in. Defaults to `/`.
- `description` (str, optional): An optional description label for the folder. Defaults to `None`.
**Returns:**
- `CreateFolderResponseItem`: The response containing the created folder.
#### Get Folder by ID
```python
folder = client.folders.get_folder_by_id(
id="<folder-id>"
)
```
**Parameters:**
- `id` (str): The ID of the folder to retrieve.
**Returns:**
- `SingleFolderResponseItem`: The response containing the folder details.

21
docs/self-hosting/configuration/envars.mdx
View File

@@ -116,6 +116,27 @@ The platform utilizes Postgres to persist all of its data and Redis for caching
<ParamField query="DB_ROOT_CERT" type="string" default="" optional>
Configure the SSL certificate for securing a Postgres connection by first encoding it in base64.
Use the following command to encode your certificate: `echo "<certificate>" | base64`
Many cloud providers provide a CA certificate for their data regions that you can use to secure your connection with SSL.
<AccordionGroup>
<Accordion title="AWS RDS">
If you're hosting your database on AWS RDS, you can use their publicly available CA certificate as the database root certificate.
You can find all the available CA certificates for AWS RDS on the official [AWS RDS documentation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html).
As an example, if your RDS cluster is hosted in `us-east-1` _(US East, N. Virginia)_, you can use the following root certificate: https://truststore.pki.rds.amazonaws.com/us-east-1/us-east-1-bundle.pem.
All the available CA certificates can be found in the AWS RDS documentation linked above.
Remember to base64 encode the certificate before setting it as the `DB_ROOT_CERT` environment variable. `cat /path/to/certificate.pem | base64`.
```bash
DB_ROOT_CERT=LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1 # .... (base64 encoded certificate)
DB_CONNECTION_URI=<rds-endpoint>?sslmode=verify-ca # or verify-full depending on your security policies
```
</Accordion>
</AccordionGroup>
</ParamField>
<ParamField query="DB_READ_REPLICAS" type="string" default="" optional>

11
docs/self-hosting/deployment-options/kubernetes-helm.mdx
View File

@@ -1,8 +1,10 @@
---
title: "Kubernetes via Helm Chart"
description: "Learn how to use Helm chart to install Infisical on your Kubernetes cluster."
---
---
**Prerequisites**
- You have extensive understanding of [Kubernetes](https://kubernetes.io/)
- Installed [Helm package manager](https://helm.sh/) version v3.11.3 or greater
- You have [kubectl](https://kubernetes.io/docs/reference/kubectl/kubectl/) installed and connected to your kubernetes cluster
@@ -12,7 +14,7 @@ description: "Learn how to use Helm chart to install Infisical on your Kubernete
```bash
helm repo add infisical-helm-charts 'https://dl.cloudsmith.io/public/infisical/helm-charts/helm/charts/'
```
```
```bash
helm repo update
```
</Step>
@@ -61,6 +63,7 @@ description: "Learn how to use Helm chart to install Infisical on your Kubernete
</Tab>
<Tab title="Production deployment">
For production environments, we recommend using Cloud-based Platform as a Service (PaaS) solutions for PostgreSQL and Redis to ensure high availability. In on-premise setups, it's recommended to configure Redis and Postgres for high availability, either by using Bitnami charts or a custom configuration.
```yaml simple-values-example.yaml
apiVersion: v1
kind: Secret
@@ -74,6 +77,10 @@ description: "Learn how to use Helm chart to install Infisical on your Kubernete
DB_CONNECTION_URI: <>
SITE_URL: <>
```
<Tip>
If you need to configure the SSL certificate for your production Postgres instance, you can use the `DB_ROOT_CERT` environment variable. [Learn more about configuring the SSL certificate](/self-hosting/configuration/envars#aws-rds).
</Tip>
</Tab>
</Tabs>
</Step>

192
docs/self-hosting/guides/monitoring-telemetry.mdx
View File

@@ -319,80 +319,137 @@ helm install otel-collector open-telemetry/opentelemetry-collector \
--set config.exporters.prometheus.endpoint=0.0.0.0:8889
```
## Alternative Backends
Since Infisical exports in OpenTelemetry format, you can easily configure the collector to send metrics to other backends instead of (or in addition to) Prometheus:
### Cloud-Native Examples
```yaml
# Add to your otel-collector-config.yaml exporters section
exporters:
# AWS CloudWatch
awsemf:
region: us-west-2
log_group_name: /aws/emf/infisical
log_stream_name: metrics
# Google Cloud Monitoring
googlecloud:
project_id: your-project-id
# Azure Monitor
azuremonitor:
connection_string: "your-connection-string"
# Datadog
datadog:
api:
key: "your-api-key"
site: "datadoghq.com"
# New Relic
newrelic:
apikey: "your-api-key"
host_override: "otlp.nr-data.net"
```
### Multi-Backend Configuration
```yaml
service:
pipelines:
metrics:
receivers: [otlp]
processors: [batch]
exporters: [prometheus, awsemf, datadog] # Send to multiple backends
```
## Setting Up Grafana
1. **Access Grafana**: Navigate to your Grafana instance
2. **Login**: Use your configured credentials
3. **Add Prometheus Data Source**:
- Go to Configuration → Data Sources
- Click "Add data source"
- Select "Prometheus"
- Set URL to your Prometheus endpoint
- Click "Save & Test"
## Available Metrics
Infisical exposes the following key metrics in OpenTelemetry format:
### API Performance Metrics
### Core API Metrics
- `API_latency` - API request latency histogram in milliseconds
These metrics track all HTTP API requests to Infisical, including request counts, latency, and errors. Use these to monitor overall API health, identify performance bottlenecks, and track usage patterns across users and machine identities.
- **Labels**: `route`, `method`, `statusCode`
- **Example**: Monitor response times for specific endpoints
#### Total API Requests
- `API_errors` - API error count histogram
- **Labels**: `route`, `method`, `type`, `name`
- **Example**: Track error rates by endpoint and error type
- **Metric Name**: `infisical.http.server.request.count`
- **Type**: Counter
- **Unit**: `{request}`
- **Description**: Total number of API requests to Infisical (covers both human users and machine identities)
- **Attributes**:
- `infisical.organization.id` (string): Organization ID
- `infisical.organization.name` (string): Organization name (e.g., "Platform Engineering Team")
- `infisical.user.id` (string, optional): User ID if human user
- `infisical.user.email` (string, optional): User email (e.g., "jane.doe@cisco.com")
- `infisical.identity.id` (string, optional): Machine identity ID
- `infisical.identity.name` (string, optional): Machine identity name (e.g., "prod-k8s-operator")
- `infisical.auth.method` (string, optional): Auth method used
- `http.request.method` (string): HTTP method (GET, POST, PUT, DELETE)
- `http.route` (string): API endpoint route pattern
- `http.response.status_code` (int): HTTP status code
- `infisical.project.id` (string, optional): Project ID
- `infisical.project.name` (string, optional): Project name
- `user_agent.original` (string, optional): User agent string
- `client.address` (string, optional): IP address
#### Request Duration
- **Metric Name**: `infisical.http.server.request.duration`
- **Type**: Histogram
- **Unit**: `s` (seconds)
- **Description**: API request latency
- **Buckets**: [0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10]
- **Attributes**:
- `infisical.organization.id` (string): Organization ID
- `infisical.organization.name` (string): Organization name
- `infisical.user.id` (string, optional): User ID if human user
- `infisical.user.email` (string, optional): User email
- `infisical.identity.id` (string, optional): Machine identity ID
- `infisical.identity.name` (string, optional): Machine identity name
- `http.request.method` (string): HTTP method
- `http.route` (string): API endpoint route pattern
- `http.response.status_code` (int): HTTP status code
- `infisical.project.id` (string, optional): Project ID
- `infisical.project.name` (string, optional): Project name
#### API Errors by Actor
- **Metric Name**: `infisical.http.server.error.count`
- **Type**: Counter
- **Unit**: `{error}`
- **Description**: API errors grouped by actor (for identifying misconfigured services)
- **Attributes**:
- `infisical.organization.id` (string): Organization ID
- `infisical.organization.name` (string): Organization name
- `infisical.user.id` (string, optional): User ID if human
- `infisical.user.email` (string, optional): User email
- `infisical.identity.id` (string, optional): Identity ID if machine
- `infisical.identity.name` (string, optional): Identity name
- `http.route` (string): API endpoint where error occurred
- `http.request.method` (string): HTTP method
- `error.type` (string): Error category/type (client_error, server_error, auth_error, rate_limit_error, etc.)
- `infisical.project.id` (string, optional): Project ID
- `infisical.project.name` (string, optional): Project name
- `client.address` (string, optional): IP address
- `user_agent.original` (string, optional): User agent information
### Secret Operations Metrics
These metrics provide visibility into secret access patterns, helping you understand which secrets are being accessed, by whom, and from where. Essential for security auditing and access pattern analysis.
#### Secret Read Operations
- **Metric Name**: `infisical.secret.read.count`
- **Type**: Counter
- **Unit**: `{operation}`
- **Description**: Number of secret read operations
- **Attributes**:
- `infisical.organization.id` (string): Organization ID
- `infisical.organization.name` (string): Organization name
- `infisical.project.id` (string): Project ID
- `infisical.project.name` (string): Project name (e.g., "payment-service-secrets")
- `infisical.environment` (string): Environment (dev, staging, prod)
- `infisical.secret.path` (string): Path to secrets (e.g., "/microservice-a/database")
- `infisical.secret.name` (string, optional): Name of secret
- `infisical.user.id` (string, optional): User ID if human
- `infisical.user.email` (string, optional): User email
- `infisical.identity.id` (string, optional): Machine identity ID
- `infisical.identity.name` (string, optional): Machine identity name
- `user_agent.original` (string, optional): User agent/SDK information
- `client.address` (string, optional): IP address
### Authentication Metrics
These metrics track authentication attempts and outcomes, enabling you to monitor login success rates, detect potential security threats, and identify authentication issues.
#### Login Attempts
- **Metric Name**: `infisical.auth.attempt.count`
- **Type**: Counter
- **Unit**: `{attempt}`
- **Description**: Authentication attempts (both successful and failed)
- **Attributes**:
- `infisical.organization.id` (string): Organization ID
- `infisical.organization.name` (string): Organization name
- `infisical.user.id` (string, optional): User ID if human (if identifiable)
- `infisical.user.email` (string, optional): User email (if identifiable)
- `infisical.identity.id` (string, optional): Identity ID if machine (if identifiable)
- `infisical.identity.name` (string, optional): Identity name (if identifiable)
- `infisical.auth.method` (string): Authentication method attempted
- `infisical.auth.result` (string): success or failure
- `error.type` (string, optional): Reason for failure if failed (invalid_credentials, expired_token, invalid_token, etc.)
- `client.address` (string): IP address
- `user_agent.original` (string, optional): User agent/client information
- `infisical.auth.attempt.username` (string, optional): Attempted username/email (if available)
### Legacy Metrics
These metrics are from the previous instrumentation and may be deprecated in future versions. Consider migrating to the new Core API Metrics for more comprehensive observability.
- `API_latency` - API request latency histogram in milliseconds (Labels: `route`, `method`, `statusCode`)
- `API_errors` - API error count histogram (Labels: `route`, `method`, `type`, `name`)
### Integration & Secret Sync Metrics
These metrics monitor secret synchronization operations between Infisical and external systems, helping you track sync health, identify integration failures, and troubleshoot connectivity issues.
- `integration_secret_sync_errors` - Integration secret sync error count
- **Labels**: `version`, `integration`, `integrationId`, `type`, `status`, `name`, `projectId`
@@ -414,16 +471,11 @@ Infisical exposes the following key metrics in OpenTelemetry format:
### System Metrics
These metrics are automatically collected by OpenTelemetry's HTTP instrumentation:
These low-level HTTP metrics are automatically collected by OpenTelemetry's instrumentation layer, providing baseline performance data for all HTTP traffic.
- `http_server_duration` - HTTP server request duration metrics (histogram buckets, count, sum)
- `http_client_duration` - HTTP client request duration metrics (histogram buckets, count, sum)
### Custom Business Metrics
- `infisical_secret_operations_total` - Total secret operations
- `infisical_secrets_processed_total` - Total secrets processed
## Troubleshooting
### Common Issues

1
docs/snippets/AppConnectionsBrowser.jsx
View File

@@ -47,6 +47,7 @@ export const AppConnectionsBrowser = () => {
{"name": "Auth0", "slug": "auth0", "path": "/integrations/app-connections/auth0", "description": "Learn how to connect your Auth0 to pull secrets from Infisical.", "category": "Identity & Auth"},
{"name": "Okta", "slug": "okta", "path": "/integrations/app-connections/okta", "description": "Learn how to connect your Okta to pull secrets from Infisical.", "category": "Identity & Auth"},
{"name": "Laravel Forge", "slug": "laravel-forge", "path": "/integrations/app-connections/laravel-forge", "description": "Learn how to connect your Laravel Forge to pull secrets from Infisical.", "category": "Hosting"},
{"name": "Northflank", "slug": "northflank", "path": "/integrations/app-connections/northflank", "description": "Learn how to connect your Northflank projects to pull secrets from Infisical.", "category": "Hosting"}
].sort(function(a, b) {
return a.name.toLowerCase().localeCompare(b.name.toLowerCase());
});

3
docs/snippets/SecretSyncsBrowser.jsx
View File

@@ -37,7 +37,8 @@ export const SecretSyncsBrowser = () => {
{"name": "Humanitec", "slug": "humanitec", "path": "/integrations/secret-syncs/humanitec", "description": "Learn how to sync secrets from Infisical to Humanitec.", "category": "DevOps Tools"},
{"name": "OCI Vault", "slug": "oci-vault", "path": "/integrations/secret-syncs/oci-vault", "description": "Learn how to sync secrets from Infisical to OCI Vault.", "category": "Cloud Providers"},
{"name": "Zabbix", "slug": "zabbix", "path": "/integrations/secret-syncs/zabbix", "description": "Learn how to sync secrets from Infisical to Zabbix.", "category": "Monitoring"},
{"name": "Laravel Forge", "slug": "laravel-forge", "path": "/integrations/secret-syncs/laravel-forge", "description": "Learn how to sync secrets from Infisical to Laravel Forge.", "category": "Hosting"}
{"name": "Laravel Forge", "slug": "laravel-forge", "path": "/integrations/secret-syncs/laravel-forge", "description": "Learn how to sync secrets from Infisical to Laravel Forge.", "category": "Hosting"},
{"name": "Northflank", "slug": "northflank", "path": "/integrations/secret-syncs/northflank", "description": "Learn how to sync secrets from Infisical to Northflank projects.", "category": "Hosting"}
].sort(function(a, b) {
return a.name.toLowerCase().localeCompare(b.name.toLowerCase());
});