mirror of
https://github.com/Infisical/infisical.git
synced 2026-01-10 07:58:15 -05:00
Merge remote-tracking branch 'origin' into request-cert-guide
This commit is contained in:
Tuan Dang
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Get Certificate Request"
|
||||
openapi: "GET /api/v1/cert-manager/certificates/certificate-requests/{requestId}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Issue Certificate"
|
||||
openapi: "POST /api/v1/cert-manager/certificates"
|
||||
---
|
||||
4
docs/api-reference/endpoints/token-auth/get-token.mdx
Normal file
4
docs/api-reference/endpoints/token-auth/get-token.mdx
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Get Token"
|
||||
openapi: "GET /api/v1/auth/token-auth/tokens/{tokenId}"
|
||||
---
|
||||
230
docs/docs.json
230
docs/docs.json
@@ -130,6 +130,7 @@
|
||||
"integrations/app-connections/laravel-forge",
|
||||
"integrations/app-connections/ldap",
|
||||
"integrations/app-connections/mssql",
|
||||
"integrations/app-connections/mongodb",
|
||||
"integrations/app-connections/mysql",
|
||||
"integrations/app-connections/netlify",
|
||||
"integrations/app-connections/northflank",
|
||||
@@ -444,6 +445,7 @@
|
||||
"documentation/platform/secret-rotation/aws-iam-user-secret",
|
||||
"documentation/platform/secret-rotation/azure-client-secret",
|
||||
"documentation/platform/secret-rotation/ldap-password",
|
||||
"documentation/platform/secret-rotation/mongodb-credentials",
|
||||
"documentation/platform/secret-rotation/mssql-credentials",
|
||||
"documentation/platform/secret-rotation/mysql-credentials",
|
||||
"documentation/platform/secret-rotation/okta-client-secret",
|
||||
@@ -708,6 +710,7 @@
|
||||
{
|
||||
"group": "Infrastructure Integrations",
|
||||
"pages": [
|
||||
"integrations/platforms/certificate-agent",
|
||||
"documentation/platform/pki/k8s-cert-manager",
|
||||
"documentation/platform/pki/integration-guides/gloo-mesh",
|
||||
"documentation/platform/pki/integration-guides/windows-server-acme",
|
||||
@@ -783,7 +786,23 @@
|
||||
"group": "Infisical PAM",
|
||||
"pages": [
|
||||
"documentation/platform/pam/overview",
|
||||
"documentation/platform/pam/session-recording"
|
||||
{
|
||||
"group": "Getting Started",
|
||||
"pages": [
|
||||
"documentation/platform/pam/getting-started/setup",
|
||||
"documentation/platform/pam/getting-started/resources",
|
||||
"documentation/platform/pam/getting-started/accounts"
|
||||
]
|
||||
},
|
||||
"documentation/platform/pam/architecture"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Product Reference",
|
||||
"pages": [
|
||||
"documentation/platform/pam/product-reference/auditing",
|
||||
"documentation/platform/pam/product-reference/session-recording",
|
||||
"documentation/platform/pam/product-reference/credential-rotation"
|
||||
]
|
||||
}
|
||||
]
|
||||
@@ -1385,6 +1404,18 @@
|
||||
"api-reference/endpoints/app-connections/mssql/delete"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "MongoDB",
|
||||
"pages": [
|
||||
"api-reference/endpoints/app-connections/mongodb/list",
|
||||
"api-reference/endpoints/app-connections/mongodb/available",
|
||||
"api-reference/endpoints/app-connections/mongodb/get-by-id",
|
||||
"api-reference/endpoints/app-connections/mongodb/get-by-name",
|
||||
"api-reference/endpoints/app-connections/mongodb/create",
|
||||
"api-reference/endpoints/app-connections/mongodb/update",
|
||||
"api-reference/endpoints/app-connections/mongodb/delete"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "MySQL",
|
||||
"pages": [
|
||||
@@ -1921,6 +1952,19 @@
|
||||
"api-reference/endpoints/secret-rotations/mssql-credentials/update"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "MongoDB Credentials",
|
||||
"pages": [
|
||||
"api-reference/endpoints/secret-rotations/mongodb-credentials/create",
|
||||
"api-reference/endpoints/secret-rotations/mongodb-credentials/delete",
|
||||
"api-reference/endpoints/secret-rotations/mongodb-credentials/get-by-id",
|
||||
"api-reference/endpoints/secret-rotations/mongodb-credentials/get-by-name",
|
||||
"api-reference/endpoints/secret-rotations/mongodb-credentials/get-generated-credentials-by-id",
|
||||
"api-reference/endpoints/secret-rotations/mongodb-credentials/list",
|
||||
"api-reference/endpoints/secret-rotations/mongodb-credentials/rotate-secrets",
|
||||
"api-reference/endpoints/secret-rotations/mongodb-credentials/update"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "MySQL Credentials",
|
||||
"pages": [
|
||||
@@ -2485,8 +2529,8 @@
|
||||
"pages": [
|
||||
"api-reference/endpoints/certificates/list",
|
||||
"api-reference/endpoints/certificates/read",
|
||||
"api-reference/endpoints/certificates/issue-certificate",
|
||||
"api-reference/endpoints/certificates/sign-certificate",
|
||||
"api-reference/endpoints/certificates/certificate-request",
|
||||
"api-reference/endpoints/certificates/create-certificate",
|
||||
"api-reference/endpoints/certificates/renew",
|
||||
"api-reference/endpoints/certificates/update-config",
|
||||
"api-reference/endpoints/certificates/revoke",
|
||||
@@ -3036,6 +3080,186 @@
|
||||
{
|
||||
"source": "/documentation/platform/pki/est",
|
||||
"destination": "/documentation/platform/pki/enrollment-methods/est"
|
||||
},
|
||||
{
|
||||
"source": "/api-reference/endpoints/integrations/create-auth",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/api-reference/endpoints/integrations/create",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/api-reference/endpoints/integrations/delete-auth-by-id",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/api-reference/endpoints/integrations/delete-auth",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/api-reference/endpoints/integrations/delete",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/api-reference/endpoints/integrations/find-auth",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/api-reference/endpoints/integrations/list-auth",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/api-reference/endpoints/integrations/list-project-integrations",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/api-reference/endpoints/integrations/update",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/api-reference/overview/examples/integration",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/documentation/platform/integrations",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cicd/circleci",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cicd/codefresh",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cicd/octopus-deploy",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cicd/rundeck",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cicd/travisci",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/aws-parameter-store",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/aws-secret-manager",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/azure-app-configuration",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/azure-devops",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/azure-key-vault",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/checkly",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/cloud-66",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/cloudflare-pages",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/cloudflare-workers",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/databricks",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/digital-ocean-app-platform",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/flyio",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/gcp-secret-manager",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/hashicorp-vault",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/hasura-cloud",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/heroku",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/laravel-forge",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/netlify",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/northflank",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/qovery",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/railway",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/render",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/supabase",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/terraform-cloud",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/vercel",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/windmill",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/overview",
|
||||
"destination": "/integrations/secret-syncs"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/aws-amplify",
|
||||
"destination": "/integrations/cicd/aws-amplify"
|
||||
},
|
||||
{
|
||||
"source": "/integrations/cloud/teamcity",
|
||||
"destination": "/integrations/secret-syncs/teamcity"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
77
docs/documentation/platform/pam/architecture.mdx
Normal file
77
docs/documentation/platform/pam/architecture.mdx
Normal file
@@ -0,0 +1,77 @@
|
||||
---
|
||||
title: "Architecture"
|
||||
sidebarTitle: "Architecture"
|
||||
description: "Learn about the architecture, components, and security model of Infisical PAM."
|
||||
---
|
||||
|
||||
Infisical PAM utilizes a secure, proxy-based architecture designed to provide access to private resources without exposing them directly to the internet. This system relies on a combination of the Infisical CLI, a Relay server, and a self-hosted Gateway. For more information on Gateways, refer to the [Gateway Overview](/documentation/platform/gateways/overview).
|
||||
|
||||
## Core Components
|
||||
|
||||
The architecture consists of three main components working in unison:
|
||||
|
||||
<Steps>
|
||||
<Step title="Infisical CLI">
|
||||
The client-side interface used to initiate access requests. It creates a local listener that forwards traffic securely to the Gateway.
|
||||
</Step>
|
||||
<Step title="Infisical Gateway">
|
||||
A lightweight service deployed within your private network (e.g., VPC, on-prem). It acts as a proxy, intercepting traffic to enforce policies and record sessions before forwarding requests to the target resource.
|
||||
</Step>
|
||||
<Step title="Target Resource">
|
||||
The actual infrastructure being accessed, such as a PostgreSQL database, a Linux server, or a web application.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Access Flow
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
subgraph Client ["User Environment"]
|
||||
CLI["Infisical CLI"]
|
||||
end
|
||||
|
||||
Relay["Relay Server"]
|
||||
|
||||
subgraph Network ["Private Network (VPC)"]
|
||||
Gateway["Infisical Gateway"]
|
||||
DB[("Target Resource (Database/Server)")]
|
||||
end
|
||||
|
||||
CLI <-->|Encrypted Tunnel| Relay
|
||||
Relay <-->|Reverse Tunnel| Gateway
|
||||
Gateway <-->|Native Protocol| DB
|
||||
```
|
||||
|
||||
When a user accesses a resource (e.g., via `infisical access`), the following workflow occurs:
|
||||
|
||||
1. **Connection Initiation**: The Infisical CLI initiates a connection to the Relay server.
|
||||
2. **Tunnel Establishment**: The Relay facilitates an end-to-end encrypted tunnel between the CLI and the Gateway.
|
||||
3. **Proxy & Credential Injection**: The Gateway authenticates the request and connects to the target resource on the user's behalf. It automatically injects the necessary credentials (e.g., database passwords, SSH keys), ensuring the user never directly handles sensitive secrets.
|
||||
4. **Traffic Forwarding**: Traffic flows securely from the user's machine, through the Relay, to the Gateway, and finally to the resource.
|
||||
|
||||
## Session Recording & Auditing
|
||||
|
||||
|
||||
|
||||
A key feature of the Gateway is its ability to act as a "middleman" for all session traffic.
|
||||
|
||||
- **Interception**: Because the Gateway sits between the secure tunnel and the target resource, it intercepts all data flowing through the connection.
|
||||
- **Logging**: This traffic is logged as part of [Session Recording](/documentation/platform/pam/product-reference/session-recording). The Gateway temporarily stores encrypted session logs locally.
|
||||
- **Upload**: Once the session concludes, the logs are securely uploaded to the Infisical platform for storage and review.
|
||||
|
||||
## Security Architecture
|
||||
|
||||
The PAM security model allows you to maintain a zero-trust environment while enabling convenient access.
|
||||
|
||||
### End-to-End Encryption
|
||||
The connection between the Infisical CLI (client) and the Gateway is end-to-end encrypted. The Relay server acts solely as a router for encrypted packets and **cannot decrypt or inspect** the traffic passing through it.
|
||||
|
||||
### Network Security
|
||||
The Gateway uses **SSH reverse tunnels** to connect to the Relay. This design offers significant security benefits:
|
||||
- **No Inbound Ports**: You do not need to open any inbound firewall ports (like 22 or 5432) to the internet.
|
||||
- **Outbound-Only**: The Gateway only requires outbound connectivity to the Relay server and Infisical API.
|
||||
|
||||
For a deep dive into the underlying cryptography, certificate management, and isolation guarantees, refer to the [Gateway Security Architecture](/documentation/platform/gateways/security).
|
||||
|
||||
### Deployment
|
||||
For instructions on setting up the necessary infrastructure, see the [Gateway Deployment Guide](/documentation/platform/gateways/gateway-deployment).
|
||||
47
docs/documentation/platform/pam/getting-started/accounts.mdx
Normal file
47
docs/documentation/platform/pam/getting-started/accounts.mdx
Normal file
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: "PAM Account"
|
||||
sidebarTitle: "Accounts"
|
||||
description: "Learn how to create and manage accounts in PAM to control access to resources like databases and servers."
|
||||
---
|
||||
|
||||
An **Account** contains the credentials (such as a username and password) used to connect to a [Resource](/documentation/platform/pam/getting-started/resources).
|
||||
|
||||
## Relationship to Resources
|
||||
|
||||
Accounts belong to Resources. A single Resource can have multiple Accounts associated with it, each with different permission levels.
|
||||
|
||||
For example, your database would normally have multiple accounts. You might have a superuser account for admins, a standard read/write account for applications, and a read-only account for reporting.
|
||||
|
||||
In PAM, these are represented as:
|
||||
- **Resource**: `Production Database` (PostgreSQL)
|
||||
- **Account 1**: `postgres` (Superuser)
|
||||
- **Account 2**: `app_user` (Read/Write)
|
||||
- **Account 3**: `analytics` (Read-only)
|
||||
|
||||
When a user requests access in PAM, they request access to a specific **Account** on a **Resource**.
|
||||
|
||||
## Creating an Account
|
||||
|
||||
<Info>
|
||||
**Prerequisite**: You must have at least one [Resource](/documentation/platform/pam/getting-started/resources) created before adding accounts.
|
||||
</Info>
|
||||
|
||||
To add an account, navigate to the **Accounts** tab in your PAM project and click **Add Account**.
|
||||
|
||||
|
||||
|
||||
Next, select the **Resource** that this account belongs to.
|
||||
|
||||
|
||||
|
||||
After selecting a resource, provide the credentials (username, password, etc.) for this account. The required fields vary depending on the resource type. For example, for a Linux server, you would enter the username and the corresponding password or SSH key.
|
||||
|
||||
|
||||
|
||||
Clicking **Create Account** will trigger a validation check. Infisical will attempt to connect to the resource using the provided credentials to verify they are valid.
|
||||
|
||||
## Automated Credential Rotation
|
||||
|
||||
Infisical supports automated credential rotation for some accounts on select resources, allowing you to automatically change passwords at set intervals to enhance security.
|
||||
|
||||
To learn more about how to configure this, please refer to the [Credential Rotation guide](/documentation/platform/pam/product-reference/credential-rotation).
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: "PAM Resource"
|
||||
sidebarTitle: "Resources"
|
||||
description: "Learn how to add and configure resources like databases and servers, and set up automated credential rotation."
|
||||
---
|
||||
|
||||
A resource represents a target system, such as a database, server, or application, that you want to manage access to. Some examples of resources are:
|
||||
- PostgreSQL Database
|
||||
- MCP Server
|
||||
- Linux Server
|
||||
- Web Application
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before you can create a resource, you must have an **Infisical Gateway** deployed that is able to reach the target resource over the network.
|
||||
|
||||
The Gateway acts as a secure bridge, allowing Infisical to reach your private infrastructure without exposing it to the public internet. When creating a resource, you will be asked to specify which Gateway should be used to connect to it.
|
||||
|
||||
[Read the Gateway Deployment Guide](/documentation/platform/gateways/gateway-deployment)
|
||||
|
||||
## Creating a Resource
|
||||
|
||||
To add a resource, navigate to the **Resources** tab in your PAM project and click **Add Resource**.
|
||||
|
||||
|
||||
|
||||
Next, select the type of resource you want to add.
|
||||
|
||||
|
||||
|
||||
After selecting a resource type, provide the necessary connection details. The required fields vary depending on the resource type.
|
||||
|
||||
**Important**: You must select the **Gateway** that has network access to this resource.
|
||||
|
||||
In this PostgreSQL example, you provide details such as host, port, gateway, and database name.
|
||||
|
||||
|
||||
|
||||
Clicking **Create Resource** will trigger a connection test from the selected Gateway to your target resource. If the connection fails, an error message will be displayed to help you troubleshoot (usually indicating a network firewall issue between the Gateway and the Resource).
|
||||
|
||||
## Automated Credential Rotation
|
||||
|
||||
Some resources, such as PostgreSQL, support automated credential rotation to enhance your security posture. This feature requires configuring a privileged "Rotation Account" on the resource.
|
||||
|
||||
To learn more about how to configure this, please refer to the [Credential Rotation guide](/documentation/platform/pam/product-reference/credential-rotation).
|
||||
35
docs/documentation/platform/pam/getting-started/setup.mdx
Normal file
35
docs/documentation/platform/pam/getting-started/setup.mdx
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: "Setup"
|
||||
sidebarTitle: "Setup"
|
||||
description: "This guide provides a step-by-step walkthrough for configuring Infisical's Privileged Access Management (PAM). Learn how to deploy a gateway, define resources, and grant your team secure, audited access to critical infrastructure."
|
||||
---
|
||||
|
||||
Infisical's Privileged Access Management (PAM) solution enables you to provide developers with secure, just-in-time access to your critical infrastructure, such as databases, servers, and web applications. Instead of sharing static credentials, your team can request temporary access through Infisical, which is then brokered through a secure gateway with full auditing and session recording.
|
||||
|
||||
Getting started involves a few key components:
|
||||
- **Gateways:** A lightweight service you deploy in your own infrastructure to act as a secure entry point to your private resources.
|
||||
- **Resources:** The specific systems you want to manage access to (e.g., a PostgreSQL database or an SSH server).
|
||||
- **Accounts:** The privileged credentials (e.g., a database user or an SSH user) that Infisical uses to connect to a resource on behalf of a user.
|
||||
|
||||
The following steps will guide you through the entire setup process, from deploying your first gateway to establishing a secure connection.
|
||||
|
||||
<Steps>
|
||||
<Step title="Deploy a Gateway">
|
||||
Before you can manage any resources, you must deploy an **Infisical Gateway** within your infrastructure. This component is responsible for brokering connections to your private resources.
|
||||
|
||||
[Read the Gateway Deployment Guide](/documentation/platform/gateways/gateway-deployment)
|
||||
</Step>
|
||||
<Step title="Create a Resource">
|
||||
Once the Gateway is active, define a **Resource** in Infisical (e.g., "Production Database"). You will link this resource to your deployed Gateway so Infisical knows how to reach it.
|
||||
|
||||
[Learn about Resources](/documentation/platform/pam/getting-started/resources)
|
||||
</Step>
|
||||
<Step title="Add Accounts">
|
||||
Add **Accounts** to your Resource (e.g., `postgres` or `read_only_user`). These represent the actual PAM users or privileged identities that are utilized when a user connects.
|
||||
|
||||
[Learn about Accounts](/documentation/platform/pam/getting-started/accounts)
|
||||
</Step>
|
||||
<Step title="Connect">
|
||||
Users can now use the Infisical CLI to securely connect to the resource using the defined accounts, with full auditing and session recording enabled.
|
||||
</Step>
|
||||
</Steps>
|
||||
@@ -1,45 +1,67 @@
|
||||
---
|
||||
title: "Infisical PAM"
|
||||
title: "Overview"
|
||||
sidebarTitle: "Overview"
|
||||
description: "Learn how to manage access to resources like databases, servers, and accounts with policy-based controls and approvals."
|
||||
description: "Manage and secure access to critical infrastructure like databases and servers 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
|
||||
## The PAM Workflow
|
||||
|
||||
Infisical PAM employs a resource-based model to organize and manage access. This model is designed to be intuitive and scalable.
|
||||
At its core, Infisical PAM is designed to decouple **user identity** from **infrastructure credentials**. Instead of sharing static passwords or SSH keys, users authenticate with their SSO identity, and Infisical handles the rest.
|
||||
|
||||
#### 1. Create a Resource
|
||||
Here is how a typical access lifecycle looks:
|
||||
|
||||
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.
|
||||
1. **Discovery**: A user logs into Infisical and sees a catalog of resources (databases, servers) and accounts they are allowed to access.
|
||||
2. **Connection**: The user selects a resource and an account (e.g., "Production DB" as `read_only`). They initiate the connection via the Infisical CLI.
|
||||
3. **Credential Injection**: Infisical validates the request. If allowed, it establishes a secure tunnel and automatically injects the credentials for the target account. **The user never sees the underlying password or key.**
|
||||
4. **Monitoring**: The session is established. All traffic is intercepted, logged, and recorded for audit purposes.
|
||||
|
||||
|
||||
## Core Concepts
|
||||
|
||||
#### 2. Add Accounts to the Resource
|
||||
To successfully implement Infisical PAM, it is essential to understand the relationship between the following components:
|
||||
|
||||
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.
|
||||
<CardGroup cols={3}>
|
||||
<Card title="Gateway" icon="server">
|
||||
A lightweight service deployed in your network that acts as a secure bridge to your private infrastructure.
|
||||
</Card>
|
||||
<Card title="Resource" icon="database">
|
||||
The specific target you are protecting (e.g., a PostgreSQL database or an Ubuntu server).
|
||||
</Card>
|
||||
<Card title="Account" icon="user-lock">
|
||||
The specific identity on the Resource that the user is trying to access. One Resource can have multiple Accounts.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
|
||||
### Relationship Model
|
||||
|
||||
### Infisical PAM Features
|
||||
The hierarchy is structured as follows:
|
||||
|
||||
#### Session Logging and Auditing
|
||||
```mermaid
|
||||
graph TD
|
||||
GW[Gateway] --> |Provides Access| DB[Resource: Production DB]
|
||||
GW[Gateway] --> |Provides Access| SRV[Resource: Linux Server]
|
||||
|
||||
DB --> A1[Account: admin]
|
||||
DB --> A2[Account: readonly]
|
||||
|
||||
SRV --> A3[Account: ubuntu]
|
||||
```
|
||||
|
||||
- **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.
|
||||
1. **Gateway**: Deployed once per network/VPC. It provides connectivity to all resources in that environment.
|
||||
2. **Resource**: Configured within Infisical. It points to a specific IP/Host accessible by the Gateway.
|
||||
3. **Account**: Defined under a Resource. Users request access to a specific *Account* on a *Resource*.
|
||||
|
||||
|
||||
## Network Architecture
|
||||
|
||||
#### Automated Credential Rotation
|
||||
Infisical PAM uses a secure proxy-based architecture to connect users to resources without direct network exposure.
|
||||
|
||||
Infisical PAM can automatically rotate account credentials to enhance your security posture.
|
||||
When a user accesses a resource, their connection is routed securely through a Relay to your self-hosted Gateway, which then connects to the target resource. This ensures zero-trust access without exposing your infrastructure to the public internet.
|
||||
|
||||
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.
|
||||
|
||||
For a deep dive into the technical architecture and security model, see [Architecture](/documentation/platform/pam/architecture).
|
||||
|
||||
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).
|
||||
|
||||
## Core Capabilities
|
||||
|
||||
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.
|
||||
- **[Auditing](/documentation/platform/pam/product-reference/auditing)**: Track and review a comprehensive log of all user actions and system events.
|
||||
- **[Session Recording](/documentation/platform/pam/product-reference/session-recording)**: Record and playback user sessions for security reviews, compliance, and troubleshooting.
|
||||
- **[Automated Credential Rotation](/documentation/platform/pam/product-reference/credential-rotation)**: Automatically rotate credentials for supported resources to minimize the risk of compromised credentials.
|
||||
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "Auditing"
|
||||
sidebarTitle: "Auditing"
|
||||
description: "Learn how Infisical audits all actions across your PAM project."
|
||||
---
|
||||
|
||||
## What's Audited
|
||||
|
||||
Infisical logs a wide range of actions to provide a complete audit trail for your PAM project. These actions include:
|
||||
|
||||
- Session Start and End
|
||||
- Fetching session credentials
|
||||
- Creating, updating, or deleting resources, accounts, folders, and sessions
|
||||
|
||||
<Info>
|
||||
Please note: Audit logs track metadata about sessions (e.g., start/end times), but not the specific commands executed *within* them. For detailed in-session activity, check out [Session Recording](/documentation/platform/pam/product-reference/session-recording).
|
||||
</Info>
|
||||
|
||||
## Viewing Audit Logs
|
||||
|
||||
You can view, search, and filter all events from the **Audit Logs** page within your PAM project.
|
||||
|
||||
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: "Credential Rotation"
|
||||
sidebarTitle: "Credential Rotation"
|
||||
description: "Learn how to automate credential rotation for your PAM resources."
|
||||
---
|
||||
|
||||
Automated Credential Rotation enhances your security posture by automatically changing the passwords of your accounts at set intervals. This minimizes the risk of compromised credentials by ensuring that even if a password is leaked, it remains valid only for a short period.
|
||||
|
||||
## How it Works
|
||||
|
||||
When rotation is enabled, Infisical's Gateway connects to the target resource using a privileged "Rotation Account". It then executes the necessary commands to change the password for the target user account to a new, cryptographically secure random value.
|
||||
|
||||
## Configuration
|
||||
|
||||
Setting up automated rotation requires a two-step configuration: first at the Resource level, and then at the individual Account level.
|
||||
|
||||
<Steps>
|
||||
<Step title="Configure Rotation Account on Resource">
|
||||
A **Rotation Account** is a master or privileged account that has the necessary permissions to change the passwords of other users on the target system.
|
||||
|
||||
When creating or editing a [Resource](/documentation/platform/pam/getting-started/resources), you must provide the credentials for this privileged account.
|
||||
|
||||
*Example: For a PostgreSQL database, this would typically be the `postgres` superuser or another role with `ALTER ROLE` privileges.*
|
||||
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Enable Rotation on Account">
|
||||
Once the resource has a rotation account configured, you can enable rotation for individual [Accounts](/documentation/platform/pam/getting-started/accounts) that belong to that resource.
|
||||
|
||||
In the account settings:
|
||||
1. Toggle **Enable Rotation**.
|
||||
2. Set the **Rotation Interval** (e.g., every 7 days, 30 days).
|
||||
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Supported Resources
|
||||
|
||||
Automated rotation is currently supported for the following resource types:
|
||||
|
||||
- **PostgreSQL**: Requires a user with `ALTER ROLE` permissions.
|
||||
|
||||
<Note>
|
||||
We are constantly adding support for more resource types.
|
||||
</Note>
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: "Session Recording"
|
||||
sidebarTitle: "Session Recording"
|
||||
description: "Learn how Infisical records and stores session activity for auditing and monitoring."
|
||||
---
|
||||
|
||||
Infisical PAM provides robust session recording capabilities to help you audit and monitor user activity across your infrastructure.
|
||||
|
||||
## How It Works
|
||||
|
||||
When a user initiates a session by accessing an account, a recording of the session begins. The Gateway securely caches all recording data in temporary encrypted files on its local system.
|
||||
|
||||
Once the session concludes, the gateway transmits the complete recording to the Infisical platform for long-term, centralized storage. This asynchronous process ensures that sessions remain operational even if the connection to the Infisical platform is temporarily lost. After the upload is complete, administrators can search and review the session logs on the Infisical platform.
|
||||
|
||||
## What's Captured
|
||||
|
||||
The content captured during a session depends on the type of resource being accessed.
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Database Sessions">
|
||||
Infisical captures all queries executed and their corresponding responses, including timestamps for each action.
|
||||
</Accordion>
|
||||
<Accordion title="SSH Sessions">
|
||||
Infisical captures all commands executed and their corresponding responses, including timestamps for each action.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
## Viewing Recordings
|
||||
|
||||
To review session recordings:
|
||||
|
||||
1. Navigate to the **Sessions** page in your PAM project.
|
||||
2. Click on a session from the list to view its details.
|
||||
|
||||
|
||||
|
||||
The session details page provides key information, including the complete session logs, connection status, the user who initiated it, and more.
|
||||
|
||||
|
||||
|
||||
### Searching Logs
|
||||
|
||||
You can use the search bar to quickly find relevant information:
|
||||
|
||||
**Sessions page:** Search across all session logs to locate specific queries or outputs.
|
||||
|
||||
|
||||
**Individual session page:** Search within that specific session's logs to pinpoint activity.
|
||||
|
||||
|
||||
## FAQ
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Are session recordings encrypted?">
|
||||
Yes. All session recordings are encrypted at rest by default, ensuring your data is always secure.
|
||||
</Accordion>
|
||||
<Accordion title="Why aren't recordings streamed in real-time?">
|
||||
Currently, Infisical uses an asynchronous approach where the gateway records the entire session locally before uploading it. This design makes your PAM sessions more resilient, as they don't depend on a constant, active connection to the Infisical platform. We may introduce live streaming capabilities in a future release.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
258
docs/documentation/platform/pam/resources/aws-iam.mdx
Normal file
258
docs/documentation/platform/pam/resources/aws-iam.mdx
Normal file
@@ -0,0 +1,258 @@
|
||||
---
|
||||
title: "AWS IAM"
|
||||
sidebarTitle: "AWS IAM"
|
||||
description: "Learn how to configure AWS Management Console access through Infisical PAM for secure, audited, and just-in-time access to AWS."
|
||||
---
|
||||
|
||||
Infisical PAM supports secure, just-in-time access to the **AWS Management Console** through federated sign-in. This allows your team to access AWS without sharing long-lived credentials, while maintaining a complete audit trail of who accessed what and when.
|
||||
|
||||
## How It Works
|
||||
|
||||
Unlike database or SSH resources that require a Gateway for network connectivity, AWS Console access works differently. Infisical uses AWS STS (Security Token Service) to assume roles on your behalf and generates temporary federated sign-in URLs.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant User
|
||||
participant Infisical
|
||||
participant Resource Role as Resource Role<br/>(Your AWS Account)
|
||||
participant Target Role as Target Role<br/>(Your AWS Account)
|
||||
participant Console as AWS Console
|
||||
|
||||
User->>Infisical: Request AWS Console access
|
||||
Infisical->>Resource Role: AssumeRole (with ExternalId)
|
||||
Resource Role-->>Infisical: Temporary credentials
|
||||
Infisical->>Target Role: AssumeRole (role chaining)
|
||||
Target Role-->>Infisical: Session credentials
|
||||
Infisical->>Console: Generate federation URL
|
||||
Console-->>Infisical: Signed console URL
|
||||
Infisical-->>User: Return console URL
|
||||
User->>Console: Open AWS Console (federated)
|
||||
```
|
||||
|
||||
### Key Concepts
|
||||
|
||||
1. **Resource Role**: An IAM role in your AWS account that trusts Infisical. This is the "bridge" role that Infisical assumes first.
|
||||
|
||||
2. **Target Role**: The IAM role that end users will actually use in the AWS Console. The Resource Role assumes this role on behalf of the user.
|
||||
|
||||
3. **Role Chaining**: Infisical uses AWS role chaining - it first assumes the Resource Role, then uses those credentials to assume the Target Role. This provides an additional layer of security and audit capability.
|
||||
|
||||
4. **External ID**: A unique identifier (your Infisical Project ID) used in the trust policy to prevent [confused deputy attacks](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html).
|
||||
|
||||
## Session Behavior
|
||||
|
||||
### Session Duration
|
||||
|
||||
The session duration is set when creating the account and applies to all access requests. You can specify the duration using human-readable formats like `15m`, `30m`, or `1h`. Due to AWS role chaining limitations:
|
||||
|
||||
- **Minimum**: 15 minutes (`15m`)
|
||||
- **Maximum**: 1 hour (`1h`)
|
||||
|
||||
### Session Tracking
|
||||
|
||||
Infisical tracks:
|
||||
- When the session was created
|
||||
- Who accessed which role
|
||||
- When the session expires
|
||||
|
||||
<Info>
|
||||
**Important**: AWS Console sessions cannot be terminated early. Once a federated URL is generated, the session remains valid until the configured duration expires. However, you can [revoke active sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html) by modifying the role's trust policy.
|
||||
</Info>
|
||||
|
||||
### CloudTrail Integration
|
||||
|
||||
All actions performed in the AWS Console are logged in [AWS CloudTrail](https://console.aws.amazon.com/cloudtrail). The session is identified by the `RoleSessionName`, which includes the user's email address for attribution:
|
||||
|
||||
```
|
||||
arn:aws:sts::123456789012:assumed-role/pam-readonly/user@example.com
|
||||
```
|
||||
|
||||
This allows you to correlate Infisical PAM sessions with CloudTrail logs for complete audit visibility.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before configuring AWS Console access in Infisical PAM, you need to set up two IAM roles in your AWS account:
|
||||
|
||||
1. **Resource Role** - Trusted by Infisical, can assume target roles
|
||||
2. **Target Role(s)** - The actual roles users will use in the console
|
||||
|
||||
<Info>
|
||||
**No Gateway Required**: Unlike database or SSH resources, AWS Console access does not require an Infisical Gateway. Infisical communicates directly with AWS APIs.
|
||||
</Info>
|
||||
|
||||
## Create the PAM Resource
|
||||
|
||||
The PAM Resource represents the connection between Infisical and your AWS account. It contains the Resource Role that Infisical will assume.
|
||||
|
||||
<Steps>
|
||||
<Step title="Create the Resource Role Permissions Policy">
|
||||
First, create an IAM policy that allows the Resource Role to assume your target roles. For simplicity, you can use a wildcard to allow assuming any role in your account:
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [{
|
||||
"Effect": "Allow",
|
||||
"Action": "sts:AssumeRole",
|
||||
"Resource": "arn:aws:iam::<YOUR_ACCOUNT_ID>:role/*"
|
||||
}]
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
|
||||
<Note>
|
||||
**For more granular control**: If you want to restrict which roles the Resource Role can assume, replace the wildcard (`/*`) with a more specific pattern. For example:
|
||||
- `arn:aws:iam::<YOUR_ACCOUNT_ID>:role/pam-*` to only allow roles with the `pam-` prefix
|
||||
- `arn:aws:iam::<YOUR_ACCOUNT_ID>:role/infisical-*` to only allow roles with the `infisical-` prefix
|
||||
|
||||
This allows you to limit the blast radius of the Resource Role's permissions.
|
||||
</Note>
|
||||
</Step>
|
||||
|
||||
<Step title="Create the Resource Role with Trust Policy">
|
||||
Create an IAM role (e.g., `InfisicalResourceRole`) with:
|
||||
- The permissions policy from the previous step attached
|
||||
- The following trust policy:
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [{
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "arn:aws:iam::<INFISICAL_AWS_ACCOUNT_ID>:root"
|
||||
},
|
||||
"Action": "sts:AssumeRole",
|
||||
"Condition": {
|
||||
"StringEquals": {
|
||||
"sts:ExternalId": "<YOUR_INFISICAL_PROJECT_ID>"
|
||||
}
|
||||
}
|
||||
}]
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<Warning>
|
||||
**Security Best Practice**: Always use the External ID condition. This prevents confused deputy attacks where another Infisical customer could potentially trick Infisical into assuming your role.
|
||||
</Warning>
|
||||
|
||||
**Infisical AWS Account IDs:**
|
||||
| Region | Account ID |
|
||||
|--------|------------|
|
||||
| US | `381492033652` |
|
||||
| EU | `345594589636` |
|
||||
|
||||
<Note>
|
||||
**For Dedicated Instances**: Your AWS account ID differs from the ones listed above. Please contact Infisical support to obtain your dedicated AWS account ID.
|
||||
</Note>
|
||||
|
||||
<Note>
|
||||
**For Self-Hosted Instances**: Use the AWS account ID where your Infisical instance is deployed. This is the account that hosts your Infisical infrastructure and will be assuming the Resource Role.
|
||||
</Note>
|
||||
</Step>
|
||||
|
||||
<Step title="Create the Resource in Infisical">
|
||||
1. Navigate to your PAM project and go to the **Resources** tab
|
||||
2. Click **Add Resource** and select **AWS IAM**
|
||||
3. Enter a name for the resource (e.g., `production-aws`)
|
||||
4. Enter the **Resource Role ARN** - the ARN of the role you created in the previous step
|
||||
|
||||
|
||||
|
||||
Clicking **Create Resource** will validate that Infisical can assume the Resource Role. If the connection fails, verify:
|
||||
- The trust policy has the correct Infisical AWS account ID
|
||||
- The External ID matches your project ID
|
||||
- The role ARN is correct
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Create PAM Accounts
|
||||
|
||||
A PAM Account represents a specific Target Role that users can request access to. You can create multiple accounts per resource, each pointing to a different target role with different permission levels.
|
||||
|
||||
<Steps>
|
||||
<Step title="Create the Target Role Trust Policy">
|
||||
Each target role needs a trust policy that allows your Resource Role to assume it:
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [{
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "arn:aws:iam::<YOUR_ACCOUNT_ID>:role/InfisicalResourceRole"
|
||||
},
|
||||
"Action": "sts:AssumeRole",
|
||||
"Condition": {
|
||||
"StringEquals": {
|
||||
"sts:ExternalId": "<YOUR_INFISICAL_PROJECT_ID>"
|
||||
}
|
||||
}
|
||||
}]
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Create the Account in Infisical">
|
||||
1. Navigate to the **Accounts** tab in your PAM project
|
||||
2. Click **Add Account** and select the AWS IAM resource you created
|
||||
3. Fill in the account details:
|
||||
|
||||
|
||||
|
||||
<ParamField path="Name" type="string" required>
|
||||
A friendly name for this account (e.g., `readonly`, `admin`, `developer`)
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Description" type="string">
|
||||
Optional description of what this account is used for
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Target Role ARN" type="string" required>
|
||||
The ARN of the IAM role users will assume (e.g., `arn:aws:iam::123456789012:role/pam-readonly`)
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Default Session Duration" type="string" required>
|
||||
Session duration using human-readable format (e.g., `15m`, `30m`, `1h`). Minimum 15 minutes, maximum 1 hour.
|
||||
|
||||
<Warning>
|
||||
Due to AWS role chaining limitations, the maximum session duration is **1 hour**, regardless of the target role's configured maximum session duration.
|
||||
</Warning>
|
||||
</ParamField>
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Access the AWS Console
|
||||
|
||||
Once your resource and accounts are configured, users can request access through Infisical:
|
||||
|
||||
|
||||
|
||||
<Steps>
|
||||
<Step title="Navigate to Accounts">
|
||||
Go to the **Accounts** tab in your PAM project.
|
||||
</Step>
|
||||
|
||||
<Step title="Find the Account">
|
||||
Find the AWS Console account you want to access.
|
||||
</Step>
|
||||
|
||||
<Step title="Request Access">
|
||||
Click the **Access** button.
|
||||
|
||||
Infisical will:
|
||||
1. Assume the Resource Role using your project's External ID
|
||||
2. Assume the Target Role using role chaining
|
||||
3. Generate a federated sign-in URL
|
||||
4. Open the AWS Console in a new browser tab
|
||||
|
||||
The user will be signed into the AWS Console with the permissions of the Target Role.
|
||||
</Step>
|
||||
</Steps>
|
||||
224
docs/documentation/platform/pam/resources/kubernetes.mdx
Normal file
224
docs/documentation/platform/pam/resources/kubernetes.mdx
Normal file
@@ -0,0 +1,224 @@
|
||||
---
|
||||
title: "Kubernetes"
|
||||
sidebarTitle: "Kubernetes"
|
||||
description: "Learn how to configure Kubernetes cluster access through Infisical PAM for secure, audited, and just-in-time access to your Kubernetes clusters."
|
||||
---
|
||||
|
||||
Infisical PAM supports secure, just-in-time access to Kubernetes clusters through service account token authentication. This allows your team to access Kubernetes clusters without sharing long-lived credentials, while maintaining a complete audit trail of who accessed what and when.
|
||||
|
||||
## How It Works
|
||||
|
||||
Kubernetes access in Infisical PAM uses an Infisical Gateway to securely proxy connections to your Kubernetes API server. When a user requests access, Infisical generates a temporary kubeconfig that routes traffic through the Gateway, enabling secure access without exposing your cluster directly.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant User
|
||||
participant CLI as Infisical CLI
|
||||
participant Infisical
|
||||
participant Gateway as Infisical Gateway
|
||||
participant K8s as Kubernetes API Server
|
||||
|
||||
User->>CLI: Request Kubernetes access
|
||||
CLI->>Infisical: Authenticate & request session
|
||||
Infisical-->>CLI: Session credentials & Gateway info
|
||||
CLI->>CLI: Start local proxy
|
||||
CLI->>Gateway: Establish secure tunnel
|
||||
User->>CLI: kubectl commands
|
||||
CLI->>Gateway: Proxy kubectl requests
|
||||
Gateway->>K8s: Forward with SA token
|
||||
K8s-->>Gateway: Response
|
||||
Gateway-->>CLI: Return response
|
||||
CLI-->>User: kubectl output
|
||||
```
|
||||
|
||||
### Key Concepts
|
||||
|
||||
1. **Gateway**: An Infisical Gateway deployed in your network that can reach the Kubernetes API server. The Gateway handles secure communication between users and your cluster.
|
||||
|
||||
2. **Service Account Token**: A Kubernetes service account token that grants access to the cluster. This token is stored securely in Infisical and used by the Gateway to authenticate with the Kubernetes API.
|
||||
|
||||
3. **Local Proxy**: The Infisical CLI starts a local proxy on your machine that intercepts kubectl commands and routes them securely through the Gateway to your cluster.
|
||||
|
||||
4. **Session Tracking**: All access sessions are logged, including when the session was created, who accessed the cluster, session duration, and when it ended.
|
||||
|
||||
### Session Tracking
|
||||
|
||||
Infisical tracks:
|
||||
- When the session was created
|
||||
- Who accessed which cluster
|
||||
- Session duration
|
||||
- All kubectl commands executed during the session
|
||||
- When the session ended
|
||||
|
||||
<Info>
|
||||
**Session Logs**: After ending a session (by stopping the proxy), you can view detailed session logs in the Sessions page, including all commands executed during the session.
|
||||
</Info>
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before configuring Kubernetes access in Infisical PAM, you need:
|
||||
|
||||
1. **Infisical Gateway** - A Gateway deployed in your network with access to the Kubernetes API server
|
||||
2. **Service Account** - A Kubernetes service account with appropriate RBAC permissions
|
||||
3. **Infisical CLI** - The Infisical CLI installed on user machines
|
||||
|
||||
<Warning>
|
||||
**Gateway Required**: Unlike AWS Console access, Kubernetes access requires an Infisical Gateway to be deployed and registered with your Infisical instance. The Gateway must have network connectivity to your Kubernetes API server.
|
||||
</Warning>
|
||||
|
||||
## Create the PAM Resource
|
||||
|
||||
The PAM Resource represents the connection between Infisical and your Kubernetes cluster.
|
||||
|
||||
<Steps>
|
||||
<Step title="Ensure Gateway is Running">
|
||||
Before creating the resource, ensure you have an Infisical Gateway running and registered with your Infisical instance. The Gateway must have network access to your Kubernetes API server.
|
||||
</Step>
|
||||
|
||||
<Step title="Create the Resource in Infisical">
|
||||
1. Navigate to your PAM project and go to the **Resources** tab
|
||||
2. Click **Add Resource** and select **Kubernetes**
|
||||
3. Enter a name for the resource (e.g., `production-k8s`, `staging-cluster`)
|
||||
4. Enter the **Kubernetes API Server URL** - the URL to your Kubernetes API endpoint (e.g.`https://kubernetes.example.com:6443`)
|
||||
5. Select the **Gateway** that has access to this cluster
|
||||
6. Configure SSL verification options if needed
|
||||
|
||||
<Note>
|
||||
**SSL Verification**: You may need to disable SSL verification if your Kubernetes API server uses a self-signed certificate or if the certificate's hostname doesn't match the URL you're using to access it.
|
||||
</Note>
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Create a Service Account
|
||||
|
||||
Infisical PAM currently supports service account token authentication for Kubernetes. You'll need to create a service account with appropriate permissions in your cluster.
|
||||
|
||||
<Steps>
|
||||
<Step title="Create the Service Account YAML">
|
||||
Create a file named `sa.yaml` with the following content:
|
||||
|
||||
```yaml sa.yaml
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: infisical-pam-sa
|
||||
namespace: kube-system
|
||||
---
|
||||
# Bind the ServiceAccount to the desired ClusterRole
|
||||
# This example uses cluster-admin - adjust based on your needs
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
name: infisical-pam-binding
|
||||
subjects:
|
||||
- kind: ServiceAccount
|
||||
name: infisical-pam-sa
|
||||
namespace: kube-system
|
||||
roleRef:
|
||||
kind: ClusterRole
|
||||
name: cluster-admin # Change this to a more restrictive role as needed
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
---
|
||||
# Create a static, non-expiring token for the ServiceAccount
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: infisical-pam-sa-token
|
||||
namespace: kube-system
|
||||
annotations:
|
||||
kubernetes.io/service-account.name: infisical-pam-sa
|
||||
type: kubernetes.io/service-account-token
|
||||
```
|
||||
|
||||
<Warning>
|
||||
**Security Best Practice**: The example above uses `cluster-admin` for simplicity. In production environments, you should create custom ClusterRoles or Roles with the minimum permissions required for each use case.
|
||||
</Warning>
|
||||
</Step>
|
||||
|
||||
<Step title="Apply the Service Account">
|
||||
Apply the configuration to your cluster:
|
||||
|
||||
```bash
|
||||
kubectl apply -f sa.yaml
|
||||
```
|
||||
|
||||
This creates:
|
||||
- A ServiceAccount named `infisical-pam-sa` in the `kube-system` namespace
|
||||
- A ClusterRoleBinding that grants the service account its permissions
|
||||
- A Secret containing a static, non-expiring token for the service account
|
||||
</Step>
|
||||
|
||||
<Step title="Retrieve the Service Account Token">
|
||||
Get the service account token that you'll use when creating the PAM account:
|
||||
|
||||
```bash
|
||||
kubectl -n kube-system get secret infisical-pam-sa-token -o jsonpath='{.data.token}' | base64 -d
|
||||
```
|
||||
|
||||
Copy this token - you'll need it in the next step.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Create PAM Accounts
|
||||
|
||||
Once you have configured the PAM resource, you'll need to configure a PAM account for your Kubernetes resource.
|
||||
A PAM Account represents a specific service account that users can request access to. You can create multiple accounts per resource, each with different permission levels.
|
||||
|
||||
<Steps>
|
||||
<Step title="Navigate to Accounts">
|
||||
Go to the **Accounts** tab in your PAM project.
|
||||
</Step>
|
||||
|
||||
<Step title="Add New Account">
|
||||
Click **Add Account** and select the Kubernetes resource you created.
|
||||
</Step>
|
||||
|
||||
<Step title="Fill in Account Details">
|
||||
Fill in the account details and paste the service account token you retrieved earlier.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Access Kubernetes Cluster
|
||||
|
||||
Once your resource and accounts are configured, users can request access through the Infisical CLI:
|
||||
|
||||
<Steps>
|
||||
<Step title="Get the Access Command">
|
||||
1. Navigate to the **Accounts** tab in your PAM project
|
||||
2. Find the Kubernetes account you want to access
|
||||
3. Click the **Access** button
|
||||
4. Copy the provided CLI command
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Run the Access Command">
|
||||
Run the copied command in your terminal.
|
||||
|
||||
The CLI will:
|
||||
1. Authenticate with Infisical
|
||||
2. Establish a secure connection through the Gateway
|
||||
3. Start a local proxy on your machine
|
||||
4. Configure kubectl to use the proxy
|
||||
</Step>
|
||||
|
||||
<Step title="Use kubectl">
|
||||
Once the proxy is running, you can use `kubectl` commands as normal:
|
||||
|
||||
```bash
|
||||
kubectl get pods
|
||||
kubectl get namespaces
|
||||
kubectl describe deployment my-app
|
||||
```
|
||||
|
||||
All commands are routed securely through the Infisical Gateway to your cluster.
|
||||
</Step>
|
||||
|
||||
<Step title="End the Session">
|
||||
When you're done, stop the proxy by pressing `Ctrl+C` in the terminal where it's running. This will:
|
||||
- Close the secure tunnel
|
||||
- End the session
|
||||
- Log the session details to Infisical
|
||||
|
||||
You can view session logs in the **Sessions** page of your PAM project.
|
||||
</Step>
|
||||
</Steps>
|
||||
@@ -1,60 +0,0 @@
|
||||
---
|
||||
title: "Session Recording"
|
||||
sidebarTitle: "Session Recording"
|
||||
description: "Learn how Infisical records and stores session activity for auditing and monitoring."
|
||||
---
|
||||
|
||||
Infisical's Privileged Access Management (PAM) provides robust session recording capabilities to help you audit and monitor user activity across your infrastructure.
|
||||
|
||||
## How It Works
|
||||
|
||||
When a user initiates a session through the Infisical Gateway, a recording of the session begins. The gateway securely caches all recording data in temporary encrypted files on its local system.
|
||||
|
||||
Once the session concludes, the gateway transmits the complete recording to the Infisical platform for long-term, centralized storage. This asynchronous process ensures that sessions remain operational even if the connection to the Infisical platform is temporarily lost. After the upload is complete, administrators can search and review the session logs in the Infisical UI.
|
||||
|
||||
## What's Captured
|
||||
|
||||
The content captured during a session depends on the type of resource being accessed.
|
||||
|
||||
### Database Sessions
|
||||
|
||||
For database connections, Infisical captures all queries executed and their corresponding responses.
|
||||
|
||||
<Note>
|
||||
Support for additional resource types like SSH, RDP, Kubernetes, and MCP is coming soon.
|
||||
</Note>
|
||||
|
||||
## Viewing Recordings
|
||||
|
||||
To review session recordings:
|
||||
|
||||
1. Navigate to the **PAM Sessions** page in your project.
|
||||
2. Click on a session from the list to view its details.
|
||||
|
||||
|
||||
|
||||
The session details page provides key information, including the complete session logs, connection status, the user who initiated it, and more.
|
||||
|
||||
|
||||
|
||||
### Searching Logs
|
||||
|
||||
You can use the search bar to quickly find relevant information:
|
||||
|
||||
- **On the main Sessions page:** Search across all session logs to locate specific queries or outputs.
|
||||
- **On an individual session page:** Search within that specific session's logs to pinpoint activity.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## FAQ
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Are session recordings encrypted?">
|
||||
Yes. All session recordings are encrypted at rest by default, ensuring your audit data is always secure.
|
||||
</Accordion>
|
||||
<Accordion title="Why aren't recordings streamed in real-time?">
|
||||
Currently, Infisical uses an asynchronous approach where the gateway records the entire session locally before uploading it. This design makes your PAM sessions more resilient, as they don't depend on a constant, active connection to the Infisical platform. We may introduce live streaming capabilities in a future release.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
@@ -1,401 +0,0 @@
|
||||
---
|
||||
title: "Certificates"
|
||||
sidebarTitle: "Certificates"
|
||||
description: "Learn how to issue X.509 certificates with Infisical."
|
||||
---
|
||||
|
||||
## Concept
|
||||
|
||||
Assuming that you've created a Private CA hierarchy with a root CA and an intermediate CA, you can now issue/revoke X.509 certificates using the intermediate CA.
|
||||
|
||||
<div align="center">
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Root CA]
|
||||
A --> B[Intermediate CA]
|
||||
A --> C[Intermediate CA]
|
||||
B --> D[Leaf Certificate]
|
||||
C --> E[Leaf Certificate]
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
## Workflow
|
||||
|
||||
The typical workflow for managing certificates consists of the following steps:
|
||||
|
||||
1. Issuing a certificate under an intermediate CA with details like name and validity period. As part of certificate issuance, you can either issue a certificate directly from a CA or do it via a certificate template.
|
||||
2. Managing certificate lifecycle events such as certificate renewal and revocation. As part of the certificate revocation flow,
|
||||
you can also query for a Certificate Revocation List [CRL](https://en.wikipedia.org/wiki/Certificate_revocation_list), a time-stamped, signed
|
||||
data structure issued by a CA containing a list of revoked certificates to check if a certificate has been revoked.
|
||||
|
||||
<Note>
|
||||
Note that this workflow can be executed via the Infisical UI or manually such
|
||||
as via API.
|
||||
</Note>
|
||||
|
||||
## Guide to Issuing Certificates
|
||||
|
||||
In the following steps, we explore how to issue a X.509 certificate under a CA.
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Infisical UI">
|
||||
|
||||
<Steps>
|
||||
<Step title="Creating a certificate template">
|
||||
A certificate template is a set of policies for certificates issued under that template; each template is bound to a specific CA and can also be bound to a certificate collection for alerting such that any certificate issued under the template is automatically added to the collection.
|
||||
|
||||
With certificate templates, you can specify, for example, that issued certificates must have a common name (CN) adhering to a specific format like `.*.acme.com` or perhaps that the max TTL cannot be more than 1 year.
|
||||
|
||||
Head to your Project > Certificate Authorities > Your Issuing CA and create a certificate template.
|
||||
|
||||
|
||||
|
||||
Here's some guidance on each field:
|
||||
|
||||
- Template Name: A name for the certificate template.
|
||||
- Issuing CA: The Certificate Authority (CA) that will issue certificates based on this template.
|
||||
- Certificate Collection (Optional): The certificate collection that certificates should be added to when issued under the template.
|
||||
- Common Name (CN): A regular expression used to validate the common name in certificate requests.
|
||||
- Alternative Names (SANs): A regular expression used to validate subject alternative names in certificate requests.
|
||||
- TTL: The maximum Time-to-Live (TTL) for certificates issued using this template.
|
||||
- Key Usage: The key usage constraint or default value for certificates issued using this template.
|
||||
- Extended Key Usage: The extended key usage constraint or default value for certificates issued using this template.
|
||||
</Step>
|
||||
<Step title="Creating a certificate">
|
||||
To create a certificate, head to your Project > Internal PKI > Certificates and press **Issue** under the Certificates section.
|
||||
|
||||
|
||||
|
||||
Here, set the **Certificate Template** to the template from step 1 and fill out the rest of the details for the certificate to be issued.
|
||||
|
||||
|
||||
|
||||
Here's some guidance on each field:
|
||||
|
||||
- Friendly Name: A friendly name for the certificate; this is only for display and defaults to the common name of the certificate if left empty.
|
||||
- Common Name (CN): The common name for the certificate like `service.acme.com`.
|
||||
- Alternative Names (SANs): A comma-delimited list of Subject Alternative Names (SANs) for the certificate; these can be hostnames or email addresses like `app1.acme.com, app2.acme.com`.
|
||||
- TTL: The lifetime of the certificate in seconds.
|
||||
- Key Usage: The key usage extension of the certificate.
|
||||
- Extended Key Usage: The extended key usage extension of the certificate.
|
||||
|
||||
<Note>
|
||||
Note that Infisical PKI supports issuing certificates without certificate templates as well. If this is desired, then you can set the **Certificate Template** field to **None**
|
||||
and specify the **Issuing CA** and optional **Certificate Collection** fields; the rest of the fields for the issued certificate remain the same.
|
||||
|
||||
That said, we recommend using certificate templates to enforce policies and attach expiration monitoring on issued certificates.
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
<Step title="Copying the certificate details">
|
||||
Once you have created the certificate from step 1, you'll be presented with the certificate details including the **Certificate Body**, **Certificate Chain**, and **Private Key**.
|
||||
|
||||
|
||||
|
||||
<Note>
|
||||
Make sure to download and store the **Private Key** in a secure location as it will only be displayed once at the time of certificate issuance.
|
||||
The **Certificate Body** and **Certificate Chain** will remain accessible and can be copied at any time.
|
||||
</Note>
|
||||
</Step>
|
||||
</Steps>
|
||||
</Tab>
|
||||
<Tab title="API">
|
||||
|
||||
<Steps>
|
||||
<Step title="Creating a certificate template">
|
||||
A certificate template is a set of policies for certificates issued under that template; each template is bound to a specific CA and can also be bound to a certificate collection for alerting such that any certificate issued under the template is automatically added to the collection.
|
||||
|
||||
With certificate templates, you can specify, for example, that issued certificates must have a common name (CN) adhering to a specific format like .*.acme.com or perhaps that the max TTL cannot be more than 1 year.
|
||||
|
||||
To create a certificate template, make an API request to the [Create Certificate Template](/api-reference/endpoints/certificate-templates-v2/create) API endpoint, specifying the issuing CA.
|
||||
|
||||
### Sample request
|
||||
|
||||
```bash Request
|
||||
curl --request POST \
|
||||
--url https://us.infisical.com/api/v2/certificate-templates \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data '{
|
||||
"projectId": "<string>",
|
||||
"name": "<string>",
|
||||
"description": "<string>",
|
||||
"subject": [
|
||||
{
|
||||
"type": "common_name",
|
||||
"allowed": [
|
||||
"*.infisical.com"
|
||||
]
|
||||
}
|
||||
],
|
||||
"sans": [
|
||||
{
|
||||
"type": "dns_name",
|
||||
"allowed": [
|
||||
"*.sample.com"
|
||||
]
|
||||
}
|
||||
],
|
||||
"keyUsages": {
|
||||
"allowed": [
|
||||
"digital_signature"
|
||||
]
|
||||
},
|
||||
"extendedKeyUsages": {
|
||||
"allowed": [
|
||||
"client_auth"
|
||||
]
|
||||
},
|
||||
"algorithms": {
|
||||
"signature": [
|
||||
"SHA256-RSA"
|
||||
],
|
||||
"keyAlgorithm": [
|
||||
"RSA-2048"
|
||||
]
|
||||
},
|
||||
"validity": {
|
||||
"max": "365d"
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
### Sample response
|
||||
|
||||
```bash Response
|
||||
{
|
||||
"certificateTemplate": {
|
||||
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"name": "<string>",
|
||||
"description": "<string>",
|
||||
"subject": [
|
||||
{
|
||||
"type": "common_name",
|
||||
"allowed": [
|
||||
"*.infisical.com"
|
||||
]
|
||||
}
|
||||
],
|
||||
"sans": [
|
||||
{
|
||||
"type": "dns_name",
|
||||
"allowed": [
|
||||
"*.sample.com"
|
||||
]
|
||||
}
|
||||
],
|
||||
"keyUsages": {
|
||||
"allowed": [
|
||||
"digital_signature"
|
||||
]
|
||||
},
|
||||
"extendedKeyUsages": {
|
||||
"allowed": [
|
||||
"client_auth"
|
||||
]
|
||||
},
|
||||
"algorithms": {
|
||||
"signature": [
|
||||
"SHA256-RSA"
|
||||
],
|
||||
"keyAlgorithm": [
|
||||
"RSA-2048"
|
||||
]
|
||||
},
|
||||
"validity": {
|
||||
"max": "365d"
|
||||
},
|
||||
"createdAt": "2023-11-07T05:31:56Z",
|
||||
"updatedAt": "2023-11-07T05:31:56Z"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
</Step>
|
||||
<Step title="Creating a certificate">
|
||||
To create a certificate under the certificate template, make an API request to the [Issue Certificate](/api-reference/endpoints/certificates/issue-certificate) API endpoint,
|
||||
specifying the issuing CA.
|
||||
|
||||
### Sample request
|
||||
|
||||
```bash Request
|
||||
curl --location --request POST 'https://app.infisical.com/api/v1/cert-manager/certificates/issue-certificate' \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data-raw '{
|
||||
"profileId": "<profile-id>",
|
||||
"commonName": "service.acme.com",
|
||||
"ttl": "1y",
|
||||
"signatureAlgorithm": "RSA-SHA256",
|
||||
"keyAlgorithm": "RSA_2048"
|
||||
}'
|
||||
```
|
||||
|
||||
### Sample response
|
||||
|
||||
```bash Response
|
||||
{
|
||||
certificate: "...",
|
||||
certificateChain: "...",
|
||||
issuingCaCertificate: "...",
|
||||
privateKey: "...",
|
||||
serialNumber: "..."
|
||||
}
|
||||
```
|
||||
|
||||
<Note>
|
||||
Note that Infisical PKI supports issuing certificates without certificate templates as well. If this is desired, then you can set the **Certificate Template** field to **None**
|
||||
and specify the **Issuing CA** and optional **Certificate Collection** fields; the rest of the fields for the issued certificate remain the same.
|
||||
|
||||
That said, we recommend using certificate templates to enforce policies and attach expiration monitoring on issued certificates.
|
||||
</Note>
|
||||
|
||||
<Note>
|
||||
Make sure to store the `privateKey` as it is only returned once here at the time of certificate issuance. The `certificate` and `certificateChain` will remain accessible and can be retrieved at any time.
|
||||
</Note>
|
||||
|
||||
If you have an external private key, you can also create a certificate by making an API request containing a pem-encoded CSR (Certificate Signing Request) to the [Sign Certificate](/api-reference/endpoints/certificates/sign-certificate) API endpoint, specifying the issuing CA.
|
||||
|
||||
### Sample request
|
||||
|
||||
```bash Request
|
||||
curl --location --request POST 'https://app.infisical.com/api/v1/cert-manager/certificates/sign-certificate' \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data-raw '{
|
||||
"certificateTemplateId": "<certificate-template-id>",
|
||||
"csr": "...",
|
||||
"ttl": "1y",
|
||||
}'
|
||||
```
|
||||
|
||||
### Sample response
|
||||
|
||||
```bash Response
|
||||
{
|
||||
certificate: "...",
|
||||
certificateChain: "...",
|
||||
issuingCaCertificate: "...",
|
||||
privateKey: "...",
|
||||
serialNumber: "..."
|
||||
}
|
||||
```
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## Guide to Revoking Certificates
|
||||
|
||||
In the following steps, we explore how to revoke a X.509 certificate under a CA and obtain a Certificate Revocation List (CRL) for a CA.
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Infisical UI">
|
||||
<Steps>
|
||||
<Step title="Revoking a Certificate">
|
||||
Assuming that you've issued a certificate under a CA, you can revoke it by
|
||||
selecting the **Revoke Certificate** option for it and specifying the reason
|
||||
for revocation.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Obtaining a CRL">
|
||||
In order to check the revocation status of a certificate, you can check it
|
||||
against the CRL of a CA by heading to its Issuing CA and downloading the CRL.
|
||||
|
||||
|
||||
|
||||
To verify a certificate against the
|
||||
downloaded CRL with OpenSSL, you can use the following command:
|
||||
|
||||
```bash
|
||||
openssl verify -crl_check -CAfile chain.pem -CRLfile crl.pem cert.pem
|
||||
```
|
||||
|
||||
Note that you can also obtain the CRL from the certificate itself by
|
||||
referencing the CRL distribution point extension on the certificate.
|
||||
|
||||
To check a certificate against the CRL distribution point specified within it with OpenSSL, you can use the following command:
|
||||
|
||||
```bash
|
||||
openssl verify -verbose -crl_check -crl_download -CAfile chain.pem cert.pem
|
||||
```
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
</Tab>
|
||||
<Tab title="API">
|
||||
<Steps>
|
||||
<Step title="Revoking a certificate">
|
||||
Assuming that you've issued a certificate under a CA, you can revoke it by making an API request to the [Revoke Certificate](/api-reference/endpoints/certificates/revoke) API endpoint,
|
||||
specifying the serial number of the certificate and the reason for revocation.
|
||||
|
||||
### Sample request
|
||||
|
||||
```bash Request
|
||||
curl --location --request POST 'https://app.infisical.com/api/v1/cert-manager/certificates/<cert-id>/revoke' \
|
||||
--header 'Authorization: Bearer <access-token>' \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data-raw '{
|
||||
"revocationReason": "UNSPECIFIED"
|
||||
}'
|
||||
```
|
||||
|
||||
### Sample response
|
||||
|
||||
```bash Response
|
||||
{
|
||||
message: "Successfully revoked certificate",
|
||||
serialNumber: "...",
|
||||
revokedAt: "..."
|
||||
}
|
||||
```
|
||||
</Step>
|
||||
<Step title="Obtaining a CRL">
|
||||
In order to check the revocation status of a certificate, you can check it against the CRL of the issuing CA.
|
||||
To obtain the CRLs of the CA, make an API request to the [List CRLs](/api-reference/endpoints/certificate-authorities/crl) API endpoint.
|
||||
|
||||
### Sample request
|
||||
|
||||
```bash Request
|
||||
curl --location --request GET 'https://app.infisical.com/api/v1/cert-manager/ca/internal/<ca-id>/crls' \
|
||||
--header 'Authorization: Bearer <access-token>'
|
||||
```
|
||||
|
||||
### Sample response
|
||||
|
||||
```bash Response
|
||||
[
|
||||
{
|
||||
id: "...",
|
||||
crl: "..."
|
||||
},
|
||||
...
|
||||
]
|
||||
```
|
||||
|
||||
To verify a certificate against the CRL with OpenSSL, you can use the following command:
|
||||
|
||||
```bash
|
||||
openssl verify -crl_check -CAfile chain.pem -CRLfile crl.pem cert.pem
|
||||
```
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## FAQ
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="What is the workflow for renewing a certificate?">
|
||||
To renew a certificate, you have to issue a new certificate from the same CA
|
||||
with the same common name as the old certificate. The original certificate
|
||||
will continue to be valid through its original TTL unless explicitly
|
||||
revoked.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
@@ -29,13 +29,13 @@ Refer to the documentation for each [enrollment method](/documentation/platform/
|
||||
## Guide to Renewing Certificates
|
||||
|
||||
To [renew a certificate](/documentation/platform/pki/concepts/certificate-lifecycle#renewal), you can either request a new certificate from a certificate profile or have the platform
|
||||
automatically request a new one for you. Whether you pursue a client-driven or server-driven approach is totally dependent on the enrollment method configured on your certificate
|
||||
automatically request a new one for you to be delivered downstream to a target destination. Whether you pursue a client-driven or server-driven approach is totally dependent on the enrollment method configured on your certificate
|
||||
profile as well as your infrastructure use-case.
|
||||
|
||||
### Client-Driven Certificate Renewal
|
||||
|
||||
Client-driven certificate renewal is when renewal is initiated client-side by the end-entity consuming the certificate.
|
||||
This is the most common approach to certificate renewal and is suitable for most use-cases.
|
||||
More specifically, the client (e.g. [Infisical Agent](/integrations/platforms/certificate-agent), [ACME client](https://letsencrypt.org/docs/client-options/), etc.) monitors the certificate and makes a request for Infisical to issue a new certificate back to it when the existing certificate is nearing expiration. This is the most common approach to certificate renewal and is suitable for most use-cases.
|
||||
|
||||
### Server-Driven Certificate Renewal
|
||||
|
||||
|
||||
@@ -28,6 +28,17 @@ In the following steps, we explore how to issue a X.509 certificate using the AC
|
||||
|
||||
|
||||
|
||||
<Note>
|
||||
|
||||
By default, when the ACME client requests a certificate against the certificate profile for a particular domain, Infisical will verify domain ownership using the [HTTP-01 challenge](https://letsencrypt.org/docs/challenge-types/#http-01-challenge) method prior to issuing a certificate back to the client.
|
||||
|
||||
If you want Infisical to skip domain ownership validation entirely, you can enable the **Skip DNS Ownership Validation** checkbox.
|
||||
|
||||
Note that skipping domain ownership validation for the ACME enrollment method is **not the same** as skipping validation for an [External ACME CA integration](/documentation/platform/pki/ca/acme-ca).
|
||||
|
||||
When using the ACME enrollment, the domain ownership check occurring between the ACME client and Infisical can be skipped. In contrast, External ACME CA integrations always require domain ownership validation, as Infisical must complete a DNS-01 challenge with the upstream ACME-compatible CA.
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
<Step title="Obtain the ACME configuration">
|
||||
Once you've created the certificate profile, you can obtain its ACME configuration details by clicking the **Reveal ACME EAB** option on the profile.
|
||||
|
||||
@@ -100,32 +100,34 @@ Here, select the certificate profile from step 1 that will be used to issue the
|
||||
</Step>
|
||||
<Step title="Issue a certificate">
|
||||
|
||||
To issue a certificate against the certificate profile, make an API request to the [Issue Certificate](/api-reference/endpoints/certificates/issue-certificate) API endpoint.
|
||||
To issue a certificate against the certificate profile, make an API request to the [Issue Certificate](/api-reference/endpoints/certificates/create-certificate) API endpoint.
|
||||
|
||||
### Sample request
|
||||
|
||||
```bash Request
|
||||
curl --location --request POST 'https://app.infisical.com/api/v1/cert-manager/certificates/issue-certificate' \
|
||||
curl --location --request POST 'https://app.infisical.com/api/v1/cert-manager/certificates' \
|
||||
--header 'Authorization: Bearer <access-token>' \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data-raw '{
|
||||
"profileId": "<certificate-profile-id>",
|
||||
"commonName": "service.acme.com",
|
||||
"ttl": "1y",
|
||||
"signatureAlgorithm": "RSA-SHA256",
|
||||
"keyAlgorithm": "RSA_2048",
|
||||
"keyUsages": ["digital_signature", "key_encipherment"],
|
||||
"extendedKeyUsages": ["server_auth"],
|
||||
"altNames": [
|
||||
{
|
||||
"type": "DNS",
|
||||
"value": "service.acme.com"
|
||||
},
|
||||
{
|
||||
"type": "DNS",
|
||||
"value": "www.service.acme.com"
|
||||
}
|
||||
]
|
||||
"attributes": {
|
||||
"commonName": "service.acme.com",
|
||||
"ttl": "1y",
|
||||
"signatureAlgorithm": "RSA-SHA256",
|
||||
"keyAlgorithm": "RSA_2048",
|
||||
"keyUsages": ["digital_signature", "key_encipherment"],
|
||||
"extendedKeyUsages": ["server_auth"],
|
||||
"altNames": [
|
||||
{
|
||||
"type": "DNS",
|
||||
"value": "service.acme.com"
|
||||
},
|
||||
{
|
||||
"type": "DNS",
|
||||
"value": "www.service.acme.com"
|
||||
}
|
||||
]
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
@@ -133,31 +135,39 @@ Here, select the certificate profile from step 1 that will be used to issue the
|
||||
|
||||
```bash Response
|
||||
{
|
||||
"certificate": "-----BEGIN CERTIFICATE-----\nMIIEpDCCAowCCQD...\n-----END CERTIFICATE-----",
|
||||
"certificateChain": "-----BEGIN CERTIFICATE-----\nMIIEpDCCAowCCQD...\n-----END CERTIFICATE-----",
|
||||
"issuingCaCertificate": "-----BEGIN CERTIFICATE-----\nMIIEpDCCAowCCQD...\n-----END CERTIFICATE-----",
|
||||
"privateKey": "-----BEGIN PRIVATE KEY-----\nMIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC...\n-----END PRIVATE KEY-----",
|
||||
"serialNumber": "123456789012345678",
|
||||
"certificateId": "880h3456-e29b-41d4-a716-446655440003"
|
||||
"certificate": {
|
||||
"certificate": "-----BEGIN CERTIFICATE-----\nMIIEpDCCAowCCQD...\n-----END CERTIFICATE-----",
|
||||
"certificateChain": "-----BEGIN CERTIFICATE-----\nMIIEpDCCAowCCQD...\n-----END CERTIFICATE-----",
|
||||
"issuingCaCertificate": "-----BEGIN CERTIFICATE-----\nMIIEpDCCAowCCQD...\n-----END CERTIFICATE-----",
|
||||
"privateKey": "-----BEGIN PRIVATE KEY-----\nMIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC...\n-----END PRIVATE KEY-----",
|
||||
"serialNumber": "123456789012345678",
|
||||
"certificateId": "880h3456-e29b-41d4-a716-446655440003"
|
||||
},
|
||||
"certificateRequestId": "..."
|
||||
}
|
||||
```
|
||||
|
||||
<Note>
|
||||
Make sure to store the `privateKey` as it is only returned once here at the time of certificate issuance. The `certificate` and `certificateChain` will remain accessible and can be retrieved at any time.
|
||||
Note: If the certificate is available to be issued immediately, the `certificate` field in the response will contain the certificate data. If issuance is delayed (for example, due to pending approval or additional processing), the `certificate` field will be `null` and you can use the `certificateRequestId` to poll for status or retrieve the certificate when it is ready using the [Get Certificate Request](/api-reference/endpoints/certificates/certificate-request) API endpoint.
|
||||
|
||||
Also be sure to store the `privateKey` as it is only returned once here at the time of certificate issuance. The `certificate` and `certificateChain` will remain accessible and can be retrieved at any time.
|
||||
|
||||
</Note>
|
||||
|
||||
If you have an external private key, you can also issue a certificate by making an API request containing a pem-encoded CSR (Certificate Signing Request) to the [Sign Certificate](/api-reference/endpoints/certificates/sign-certificate) API endpoint.
|
||||
If you have an external private key, you can also issue a certificate by making an API request containing a pem-encoded CSR (Certificate Signing Request) to the same [Issue Certificate](/api-reference/endpoints/certificates/create-certificate) API endpoint.
|
||||
|
||||
### Sample request
|
||||
|
||||
```bash Request
|
||||
curl --location --request POST 'https://app.infisical.com/api/v1/cert-manager/certificates/sign-certificate' \
|
||||
curl --location --request POST 'https://app.infisical.com/api/v1/cert-manager/certificates' \
|
||||
--header 'Authorization: Bearer <access-token>' \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data-raw '{
|
||||
"profileId": "<certificate-profile-id>",
|
||||
"csr": "-----BEGIN CERTIFICATE REQUEST-----\nMIICvDCCAaQCAQAwdzELMAkGA1UEBhMCVVMxDTALBgNVBAgMBE9oaW8...\n-----END CERTIFICATE REQUEST-----",
|
||||
"ttl": "1y"
|
||||
"attributes": {
|
||||
"ttl": "1y"
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
@@ -165,11 +175,14 @@ Here, select the certificate profile from step 1 that will be used to issue the
|
||||
|
||||
```bash Response
|
||||
{
|
||||
"certificate": "-----BEGIN CERTIFICATE-----\nMIIEpDCCAowCCQD...\n-----END CERTIFICATE-----",
|
||||
"certificateChain": "-----BEGIN CERTIFICATE-----\nMIIEpDCCAowCCQD...\n-----END CERTIFICATE-----",
|
||||
"issuingCaCertificate": "-----BEGIN CERTIFICATE-----\nMIIEpDCCAowCCQD...\n-----END CERTIFICATE-----",
|
||||
"serialNumber": "123456789012345679",
|
||||
"certificateId": "990i4567-e29b-41d4-a716-446655440004"
|
||||
"certificate": {
|
||||
"certificate": "-----BEGIN CERTIFICATE-----\nMIIEpDCCAowCCQD...\n-----END CERTIFICATE-----",
|
||||
"certificateChain": "-----BEGIN CERTIFICATE-----\nMIIEpDCCAowCCQD...\n-----END CERTIFICATE-----",
|
||||
"issuingCaCertificate": "-----BEGIN CERTIFICATE-----\nMIIEpDCCAowCCQD...\n-----END CERTIFICATE-----",
|
||||
"serialNumber": "123456789012345679",
|
||||
"certificateId": "990i4567-e29b-41d4-a716-446655440004"
|
||||
},
|
||||
"certificateRequestId": "..."
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
@@ -139,7 +139,7 @@ The following steps show how to install cert-manager (using `kubectl`) and obtai
|
||||
```
|
||||
|
||||
<Note>
|
||||
- Currently, the Infisical ACME server only supports the HTTP-01 challenge and requires successful challenge completion before issuing certificates. Support for optional challenges and DNS-01 is planned for a future release.
|
||||
- Currently, the [ACME enrollment method](/documentation/platform/pki/enrollment-methods/acme) only supports the [HTTP-01 challenge](https://letsencrypt.org/docs/challenge-types/#http-01-challenge) method. Support for the [DNS-01 challenge](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge) method is planned for a future release. If domain ownership validation is not desired, you can disable it by enabling the **Skip DNS ownership validation** option in your ACME certificate profile configuration.
|
||||
- An `Issuer` is namespace-scoped. Certificates can only be issued using an `Issuer` that exists in the same namespace as the `Certificate` resource.
|
||||
- If you need to issue certificates across multiple namespaces with a single resource, create a `ClusterIssuer` instead. The configuration is identical except `kind: ClusterIssuer` and no `metadata.namespace`.
|
||||
- More details: https://cert-manager.io/docs/configuration/acme/
|
||||
|
||||
@@ -0,0 +1,177 @@
|
||||
---
|
||||
title: "MongoDB Credentials Rotation"
|
||||
description: "Learn how to automatically rotate MongoDB credentials."
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. Create a [MongoDB Connection](/integrations/app-connections/mongodb) with the required **Secret Rotation** permissions
|
||||
2. Create two designated database users for Infisical to rotate the credentials for. Be sure to grant each user login permissions for the desired database with the necessary privileges their use case will require.
|
||||
|
||||
An example creation statement might look like:
|
||||
```bash
|
||||
// Switch to the target database
|
||||
use my_database
|
||||
|
||||
// Create first user
|
||||
db.createUser({
|
||||
user: "infisical_user_1",
|
||||
pwd: "temporary_password",
|
||||
roles: []
|
||||
})
|
||||
|
||||
// Create second user
|
||||
db.createUser({
|
||||
user: "infisical_user_2",
|
||||
pwd: "temporary_password",
|
||||
roles: []
|
||||
})
|
||||
|
||||
// Grant necessary permissions to both users
|
||||
db.grantRolesToUser("infisical_user_1", [
|
||||
{ role: "readWrite", db: "my_database" }
|
||||
])
|
||||
|
||||
db.grantRolesToUser("infisical_user_2", [
|
||||
{ role: "readWrite", db: "my_database" }
|
||||
])
|
||||
```
|
||||
|
||||
<Tip>
|
||||
To learn more about MongoDB's permission system, please visit their [documentation](https://www.mongodb.com/docs/manual/core/security-built-in-roles/).
|
||||
</Tip>
|
||||
|
||||
3. Ensure your network security policies allow incoming requests from Infisical to this rotation provider, if network restrictions apply.
|
||||
|
||||
## Create a MongoDB Credentials Rotation in Infisical
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Infisical UI">
|
||||
1. Navigate to your Secret Manager Project's Dashboard and select **Add Secret Rotation** from the actions dropdown.
|
||||
|
||||
|
||||
2. Select the **MongoDB Credentials** option.
|
||||
|
||||
|
||||
3. Select the **MongoDB Connection** to use and configure the rotation behavior. Then click **Next**.
|
||||
|
||||
|
||||
- **MongoDB Connection** - the connection that will perform the rotation of the configured database user credentials.
|
||||
- **Rotation Interval** - the interval, in days, that once elapsed will trigger a rotation.
|
||||
- **Rotate At** - the local time of day when rotation should occur once the interval has elapsed.
|
||||
- **Auto-Rotation Enabled** - whether secrets should automatically be rotated once the rotation interval has elapsed. Disable this option to manually rotate secrets or pause secret rotation.
|
||||
|
||||
4. Input the usernames of the database users created above that will be used for rotation. Then click **Next**.
|
||||
|
||||
|
||||
- **Database Username 1** - the username of the first user that will be used for rotation.
|
||||
- **Database Username 2** - the username of the second user that will be used for rotation.
|
||||
|
||||
5. Specify the secret names that the active credentials should be mapped to. Then click **Next**.
|
||||
|
||||
|
||||
- **Username** - the name of the secret that the active username will be mapped to.
|
||||
- **Password** - the name of the secret that the active password will be mapped to.
|
||||
|
||||
6. Give your rotation a name and description (optional). Then click **Next**.
|
||||
|
||||
|
||||
- **Name** - the name of the secret rotation configuration. Must be slug-friendly.
|
||||
- **Description** (optional) - a description of this rotation configuration.
|
||||
|
||||
7. Review your configuration, then click **Create Secret Rotation**.
|
||||
|
||||
|
||||
8. Your **MongoDB Credentials** are now available for use via the mapped secrets.
|
||||
|
||||
</Tab>
|
||||
<Tab title="API">
|
||||
To create a MongoDB Credentials Rotation, make an API request to the [Create MongoDB
|
||||
Credentials Rotation](/api-reference/endpoints/secret-rotations/mongodb-credentials/create) API endpoint.
|
||||
|
||||
### Sample request
|
||||
|
||||
```bash Request
|
||||
curl --request POST \
|
||||
--url https://us.infisical.com/api/v2/secret-rotations/mongodb-credentials \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data '{
|
||||
"name": "my-mongodb-rotation",
|
||||
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"description": "my database credentials rotation",
|
||||
"connectionId": "11c76f38-cd13-4137-b1a3-ecd6a429952c",
|
||||
"environment": "dev",
|
||||
"secretPath": "/",
|
||||
"isAutoRotationEnabled": true,
|
||||
"rotationInterval": 30,
|
||||
"rotateAtUtc": {
|
||||
"hours": 0,
|
||||
"minutes": 0
|
||||
},
|
||||
"parameters": {
|
||||
"username1": "infisical_user_1",
|
||||
"username2": "infisical_user_2"
|
||||
},
|
||||
"secretsMapping": {
|
||||
"username": "MONGODB_DB_USERNAME",
|
||||
"password": "MONGODB_DB_PASSWORD"
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
### Sample response
|
||||
|
||||
```bash Response
|
||||
{
|
||||
"secretRotation": {
|
||||
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"name": "my-mongodb-rotation",
|
||||
"description": "my database credentials rotation",
|
||||
"secretsMapping": {
|
||||
"username": "MONGODB_DB_USERNAME",
|
||||
"password": "MONGODB_DB_PASSWORD"
|
||||
},
|
||||
"isAutoRotationEnabled": true,
|
||||
"activeIndex": 0,
|
||||
"folderId": "b3257e1f-8d32-4e86-8bfd-b1f1bc1bf2c3",
|
||||
"connectionId": "11c76f38-cd13-4137-b1a3-ecd6a429952c",
|
||||
"createdAt": "2023-11-07T05:31:56Z",
|
||||
"updatedAt": "2023-11-07T05:31:56Z",
|
||||
"rotationInterval": 30,
|
||||
"rotationStatus": "success",
|
||||
"lastRotationAttemptedAt": "2023-11-07T05:31:56Z",
|
||||
"lastRotatedAt": "2023-11-07T05:31:56Z",
|
||||
"lastRotationJobId": null,
|
||||
"nextRotationAt": "2023-11-07T05:31:56Z",
|
||||
"isLastRotationManual": true,
|
||||
"connection": {
|
||||
"app": "mongodb",
|
||||
"name": "my-mongodb-connection",
|
||||
"id": "11c76f38-cd13-4137-b1a3-ecd6a429952c"
|
||||
},
|
||||
"environment": {
|
||||
"slug": "dev",
|
||||
"name": "Development",
|
||||
"id": "170a40f1-1b48-4cc7-addf-e563aa9fbe37"
|
||||
},
|
||||
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"folder": {
|
||||
"id": "b3257e1f-8d32-4e86-8bfd-b1f1bc1bf2c3",
|
||||
"path": "/"
|
||||
},
|
||||
"rotateAtUtc": {
|
||||
"hours": 0,
|
||||
"minutes": 0
|
||||
},
|
||||
"lastRotationMessage": null,
|
||||
"type": "mongodb-credentials",
|
||||
"parameters": {
|
||||
"username1": "infisical_user_1",
|
||||
"username2": "infisical_user_2"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 930 KiB After Width: | Height: | Size: 97 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 132 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 97 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 161 KiB |
BIN
docs/images/pam/architecture/session-logging.png
Normal file
BIN
docs/images/pam/architecture/session-logging.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 293 KiB |
BIN
docs/images/pam/getting-started/accounts/add-account-button.png
Normal file
BIN
docs/images/pam/getting-started/accounts/add-account-button.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 282 KiB |
BIN
docs/images/pam/getting-started/accounts/create-account.png
Normal file
BIN
docs/images/pam/getting-started/accounts/create-account.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 344 KiB |
BIN
docs/images/pam/getting-started/accounts/select-resource.png
Normal file
BIN
docs/images/pam/getting-started/accounts/select-resource.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 307 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 241 KiB |
BIN
docs/images/pam/getting-started/resources/create-resource.png
Normal file
BIN
docs/images/pam/getting-started/resources/create-resource.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 338 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 363 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 348 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 427 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 136 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 148 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 598 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 577 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.1 MiB |
BIN
docs/images/pam/product-reference/auditing/audit-logs.png
Normal file
BIN
docs/images/pam/product-reference/auditing/audit-logs.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 563 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 474 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 503 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 419 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 576 KiB |
BIN
docs/images/pam/resources/aws-iam/access-account.png
Normal file
BIN
docs/images/pam/resources/aws-iam/access-account.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 85 KiB |
BIN
docs/images/pam/resources/aws-iam/create-account.png
Normal file
BIN
docs/images/pam/resources/aws-iam/create-account.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 129 KiB |
BIN
docs/images/pam/resources/aws-iam/create-resource.png
Normal file
BIN
docs/images/pam/resources/aws-iam/create-resource.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 110 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 143 KiB |
BIN
docs/images/pam/resources/aws-iam/resource-role-policy.png
Normal file
BIN
docs/images/pam/resources/aws-iam/resource-role-policy.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 142 KiB |
BIN
docs/images/pam/resources/aws-iam/resource-role-trust-policy.png
Normal file
BIN
docs/images/pam/resources/aws-iam/resource-role-trust-policy.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 214 KiB |
BIN
docs/images/pam/resources/aws-iam/target-role-trust-policy.png
Normal file
BIN
docs/images/pam/resources/aws-iam/target-role-trust-policy.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 213 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 415 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 462 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 500 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 570 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 313 KiB After Width: | Height: | Size: 154 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.2 MiB After Width: | Height: | Size: 103 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 132 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 132 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 103 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 112 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 161 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 124 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 142 KiB |
141
docs/integrations/app-connections/mongodb.mdx
Normal file
141
docs/integrations/app-connections/mongodb.mdx
Normal file
@@ -0,0 +1,141 @@
|
||||
---
|
||||
title: "MongoDB Connection"
|
||||
description: "Learn how to configure a MongoDB Connection for Infisical."
|
||||
---
|
||||
|
||||
Infisical supports the use of Username & Password authentication to connect with MongoDB databases.
|
||||
|
||||
## Configure a MongoDB user for Infisical
|
||||
|
||||
<Steps>
|
||||
<Step title="Create a MongoDB user">
|
||||
Infisical recommends creating a designated user in your MongoDB database for your connection.
|
||||
|
||||
```bash
|
||||
use [TARGET-DATABASE]
|
||||
db.createUser({
|
||||
user: "infisical_manager",
|
||||
pwd: "[ENTER-YOUR-USER-PASSWORD]",
|
||||
roles: []
|
||||
})
|
||||
```
|
||||
</Step>
|
||||
|
||||
<Step title="Grant Relevant Permissions">
|
||||
Depending on how you intend to use your MongoDB connection, you'll need to grant one or more of the following permissions.
|
||||
|
||||
<Tip>
|
||||
To learn more about MongoDB's permission system, please visit their [documentation](https://www.mongodb.com/docs/manual/core/security-built-in-roles/).
|
||||
</Tip>
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Secret Rotation">
|
||||
For Secret Rotations, your Infisical user will require the ability to create, update, and delete users in the target database:
|
||||
|
||||
```bash
|
||||
use [TARGET-DATABASE]
|
||||
db.grantRolesToUser("infisical_manager", [
|
||||
{ role: "userAdmin", db: "[TARGET-DATABASE]" }
|
||||
])
|
||||
```
|
||||
|
||||
<Note>
|
||||
The `userAdmin` role allows managing users (create, update passwords, delete) within the specified database.
|
||||
</Note>
|
||||
</Tab>
|
||||
</Tabs>
|
||||
</Step>
|
||||
|
||||
</Steps>
|
||||
|
||||
## Create MongoDB 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.
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Select MongoDB Connection">
|
||||
Click the **+ Add Connection** button and select the **MongoDB Connection** option from the available integrations.
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Fill out the MongoDB Connection Modal">
|
||||
Complete the MongoDB Connection form by entering:
|
||||
- A descriptive name for the connection
|
||||
- An optional description for future reference
|
||||
- The MongoDB host URL for your database
|
||||
- The MongoDB port for your database
|
||||
- The MongoDB username for your database
|
||||
- The MongoDB password for your database
|
||||
- The MongoDB database name to connect to
|
||||
|
||||
You can optionally configure SSL/TLS for your MongoDB connection in the **SSL** section.
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Connection Created">
|
||||
After clicking Create, your **MongoDB Connection** is established and ready to use with your Infisical project.
|
||||
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
</Tab>
|
||||
<Tab title="API">
|
||||
To create a MongoDB Connection, make an API request to the [Create MongoDB Connection](/api-reference/endpoints/app-connections/mongodb/create) API endpoint.
|
||||
|
||||
### Sample request
|
||||
|
||||
```bash Request
|
||||
curl --request POST \
|
||||
--url https://app.infisical.com/api/v1/app-connections/mongodb \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data '{
|
||||
"name": "my-mongodb-connection",
|
||||
"method": "username-and-password",
|
||||
"projectId": "7ffbb072-2575-495a-b5b0-127f88caef78",
|
||||
"credentials": {
|
||||
"host": "[MONGODB HOST]",
|
||||
"port": 27017,
|
||||
"username": "[MONGODB USERNAME]",
|
||||
"password": "[MONGODB PASSWORD]",
|
||||
"database": "[MONGODB DATABASE]"
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
### Sample response
|
||||
|
||||
```bash Response
|
||||
{
|
||||
"appConnection": {
|
||||
"id": "e5d18aca-86f7-4026-a95e-efb8aeb0d8e6",
|
||||
"name": "my-mongodb-connection",
|
||||
"projectId": "7ffbb072-2575-495a-b5b0-127f88caef78",
|
||||
"description": null,
|
||||
"version": 1,
|
||||
"orgId": "6f03caa1-a5de-43ce-b127-95a145d3464c",
|
||||
"createdAt": "2025-04-23T19:46:34.831Z",
|
||||
"updatedAt": "2025-04-23T19:46:34.831Z",
|
||||
"isPlatformManagedCredentials": false,
|
||||
"credentialsHash": "d41d8cd98f00b204e9800998ecf8427e",
|
||||
"app": "mongodb",
|
||||
"method": "username-and-password",
|
||||
"credentials": {
|
||||
"host": "[MONGODB HOST]",
|
||||
"port": 27017,
|
||||
"username": "[MONGODB USERNAME]",
|
||||
"database": "[MONGODB DATABASE]",
|
||||
"sslEnabled": false,
|
||||
"sslRejectUnauthorized": false,
|
||||
"sslCertificate": ""
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
</Tab>
|
||||
|
||||
</Tabs>
|
||||
@@ -1,8 +0,0 @@
|
||||
---
|
||||
title: "TeamCity"
|
||||
description: "How to sync secrets from Infisical to TeamCity"
|
||||
---
|
||||
|
||||
<Note>
|
||||
The TeamCity Native Integration will be deprecated in 2026. Please migrate to our new [TeamCity Sync](../secret-syncs/teamcity).
|
||||
</Note>
|
||||
552
docs/integrations/platforms/certificate-agent.mdx
Normal file
552
docs/integrations/platforms/certificate-agent.mdx
Normal file
@@ -0,0 +1,552 @@
|
||||
---
|
||||
title: "Infisical Agent"
|
||||
sidebarTitle: "Infisical Agent"
|
||||
description: "Learn how to use Infisical CLI Agent to manage certificates automatically."
|
||||
---
|
||||
|
||||
## Concept
|
||||
|
||||
The Infisical Agent is a client daemon that is packaged into the [Infisical CLI](/cli/overview).
|
||||
It can be used to request a certificate from Infisical using the [API enrollment method](/documentation/platform/pki/enrollment-methods/api) configured on a [certificate profile](/documentation/platform/pki/certificates/profiles), persist it to a specified path on the filesystem, and automatically monitor and renew it before expiration.
|
||||
|
||||
The Infisical Agent is notable:
|
||||
|
||||
- Automating certificate management: The agent can request, persist, monitor, and renew certificates from Infisical automatically without manual intervention. It also supports post-event hooks to execute custom commands after certificate issuance, renewal, or failure events.
|
||||
- Leveraging workload identity: The agent can authenticate with Infisical as a [machine identity](/documentation/platform/identities/machine-identities) using an infrastructure-native authentication method such as [AWS Auth](/docs/documentation/platform/identities/aws-auth), [Azure Auth](/docs/documentation/platform/identities/azure-auth), [GCP Auth](/docs/documentation/platform/identities/gcp-auth), [Kubernetes Auth](/docs/documentation/platform/identities/kubernetes-auth), etc.
|
||||
|
||||
The typical workflow for using the agent involves installing the Infisical CLI on the target machine, creating a configuration file defining the certificate to request and how it should be managed, and then starting the agent with that configuration so it can request, persist, monitor, and renew the certificate before it expires.
|
||||
This follows a [client-driven approach](/documentation/platform/pki/certificates/certificates#client-driven-certificate-renewal) to certificate renewal.
|
||||
|
||||
## Workflow
|
||||
|
||||
A typical workflow for using the Infisical Agent to request certificates from Infisical consists of the following steps:
|
||||
|
||||
1. Create a [certificate profile](/documentation/platform/pki/certificates/profiles) in Infisical with the [API enrollment method](/documentation/platform/pki/enrollment-methods/api) configured on it.
|
||||
2. Install the [Infisical CLI](/cli/overview) on the target machine.
|
||||
3. Create an agent [configuration file](/integrations/platforms/certificate-agent#agent-configuration) containing details about the certificate to request and how it should be managed such as renewal thresholds, post-event hooks, etc.
|
||||
4. Start the agent with that configuration so it can request, persist, monitor, and going forward automatically renew the certificate before it expires on the target machine.
|
||||
|
||||
## Operating the Agent
|
||||
|
||||
This section describes how to use the Infisical Agent to request certificates from Infisical. It covers how the agent authenticates with Infisical,
|
||||
and how to configure it to start requesting certificates from Infisical.
|
||||
|
||||
### Authentication
|
||||
|
||||
The Infisical Agent can authenticate with Infisical as a [machine identity](/documentation/platform/identities/machine-identities) using one of its supported authentication methods.
|
||||
|
||||
Upon successful authentication, the agent receives a short-lived access token that it uses to make subsequent authenticated requests to obtain and renew certificates from Infisical;
|
||||
the agent automatically handles token renewal as documented [here](/integrations/platforms/infisical-agent#token-renewal).
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Universal Auth">
|
||||
The Universal Auth method uses a client ID and secret for authentication.
|
||||
|
||||
<Steps>
|
||||
<Step title="Create a universal auth machine identity">
|
||||
To create a universal auth machine identity, follow the step by step guide outlined [here](/documentation/platform/identities/universal-auth).
|
||||
</Step>
|
||||
<Step title="Configure the agent">
|
||||
Update the agent configuration file with the auth method and credentials:
|
||||
|
||||
```yaml
|
||||
auth:
|
||||
type: "universal-auth"
|
||||
config:
|
||||
client-id: "./client-id" # Path to file containing client ID
|
||||
client-secret: "./client-secret" # Path to file containing client secret
|
||||
remove-client-secret-on-read: false # Optional: remove secret file after reading
|
||||
```
|
||||
|
||||
You can also provide credentials directly:
|
||||
|
||||
```yaml
|
||||
auth:
|
||||
type: "universal-auth"
|
||||
config:
|
||||
client-id: "your-client-id"
|
||||
client-secret: "your-client-secret"
|
||||
```
|
||||
</Step>
|
||||
|
||||
</Steps>
|
||||
</Accordion>
|
||||
<Accordion title="Kubernetes Auth">
|
||||
The Kubernetes Auth method is used when running the agent in a Kubernetes environment.
|
||||
|
||||
<Steps>
|
||||
<Step title="Create a Kubernetes machine identity">
|
||||
To create a Kubernetes machine identity, follow the step by step guide outlined [here](/documentation/platform/identities/kubernetes-auth).
|
||||
</Step>
|
||||
<Step title="Configure the agent">
|
||||
Configure the agent to use Kubernetes service account authentication:
|
||||
|
||||
```yaml
|
||||
auth:
|
||||
type: "kubernetes-auth"
|
||||
config:
|
||||
identity-id: "your-kubernetes-identity-id"
|
||||
service-account-token-path: "/var/run/secrets/kubernetes.io/serviceaccount/token"
|
||||
```
|
||||
</Step>
|
||||
|
||||
</Steps>
|
||||
</Accordion>
|
||||
<Accordion title="Azure Auth">
|
||||
The Azure Auth method is used when running the agent in an Azure environment.
|
||||
|
||||
<Steps>
|
||||
<Step title="Create an Azure machine identity">
|
||||
To create an Azure machine identity, follow the step by step guide outlined [here](/documentation/platform/identities/azure-auth).
|
||||
</Step>
|
||||
<Step title="Configure the agent">
|
||||
Configure the agent to use Azure managed identity authentication:
|
||||
|
||||
```yaml
|
||||
auth:
|
||||
type: "azure-auth"
|
||||
config:
|
||||
identity-id: "your-azure-identity-id"
|
||||
```
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
</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.
|
||||
|
||||
<Steps>
|
||||
<Step title="Create a GCP machine identity">
|
||||
To create a GCP machine identity, follow the step by step guide outlined [here](/documentation/platform/identities/gcp-auth).
|
||||
</Step>
|
||||
<Step title="Configure the agent">
|
||||
Update the agent configuration file with the specified auth method and identity ID:
|
||||
|
||||
```yaml
|
||||
auth:
|
||||
type: "gcp-id-token"
|
||||
config:
|
||||
identity-id: "your-gcp-identity-id"
|
||||
```
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="GCP IAM">
|
||||
The GCP IAM method is used to authenticate with Infisical with a GCP service account key.
|
||||
|
||||
<Steps>
|
||||
<Step title="Create a GCP machine identity">
|
||||
To create a GCP machine identity, follow the step by step guide outlined [here](/documentation/platform/identities/gcp-auth).
|
||||
</Step>
|
||||
<Step title="Configure the agent">
|
||||
Update the agent configuration file with the specified auth method, identity ID, and service account key:
|
||||
|
||||
```yaml
|
||||
auth:
|
||||
type: "gcp-iam"
|
||||
config:
|
||||
identity-id: "your-gcp-identity-id"
|
||||
service-account-key: "/path/to/service-account-key.json"
|
||||
```
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
</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.
|
||||
|
||||
<Steps>
|
||||
<Step title="Create an AWS machine identity">
|
||||
To create an AWS machine identity, follow the step by step guide outlined [here](/documentation/platform/identities/aws-auth).
|
||||
</Step>
|
||||
<Step title="Configure the agent">
|
||||
Update the agent configuration file with the specified auth method and identity ID:
|
||||
|
||||
```yaml
|
||||
auth:
|
||||
type: "aws-iam"
|
||||
config:
|
||||
identity-id: "your-aws-identity-id"
|
||||
```
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
### Agent Configuration
|
||||
|
||||
The Infisical Agent relies on a YAML configuration file to define its behavior, including how it should authenticate with Infisical, the certificate it should request, and how that certificate should be managed including auto-renewal.
|
||||
|
||||
The code snippet below shows an example configuration file that instructs the agent to request and continuously renew a certificate from Infisical.
|
||||
|
||||
Note that not all configuration options in this file are required but this example includes all of the available options.
|
||||
|
||||
```yaml example-cert-agent-config.yaml
|
||||
version: v1
|
||||
|
||||
# Infisical server configuration
|
||||
infisical:
|
||||
address: "https://app.infisical.com" # The URL of the Infisical instance (e.g. https://app.infisical.com, https://eu.infisical.com, https://your-self-hosted-instance.com)
|
||||
retry-strategy:
|
||||
max-retries: 3
|
||||
max-delay: "5s"
|
||||
base-delay: "200ms"
|
||||
|
||||
# Infisical authentication configuration
|
||||
auth:
|
||||
type: "universal-auth" # The authentication method to use (e.g. universal-auth, kubernetes-auth, azure-auth, gcp-id-token, gcp-iam, aws-iam)
|
||||
config:
|
||||
client-id: "your-client-id"
|
||||
client-secret: "your-client-secret"
|
||||
|
||||
# Certificate configuration
|
||||
certificates:
|
||||
- profile-name: "prof-web-server-12345"
|
||||
project-slug: "my-project-slug"
|
||||
attributes:
|
||||
common-name: "api.example.com"
|
||||
alt-names: ["api.example.com", "api-v2.example.com"]
|
||||
ttl: "90d"
|
||||
key-algorithm: "RSA_2048"
|
||||
signature-algorithm: "RSA-SHA256"
|
||||
key-usages:
|
||||
- "digital_signature"
|
||||
- "key_encipherment"
|
||||
extended-key-usages:
|
||||
- "server_auth"
|
||||
|
||||
# Enable automatic certificate renewal
|
||||
lifecycle:
|
||||
renew-before-expiry: "30d"
|
||||
status-check-interval: "6h"
|
||||
|
||||
# Configure where to store the issued certificate and its associated private key and certificate chain
|
||||
file-output:
|
||||
private-key:
|
||||
path: "/etc/ssl/private/web.key"
|
||||
permission: "0600" # Read/write for owner only
|
||||
certificate:
|
||||
path: "/etc/ssl/certs/web.crt"
|
||||
permission: "0644" # Read for all, write for owner
|
||||
chain:
|
||||
path: "/etc/ssl/certs/web-chain.crt"
|
||||
permission: "0644" # Read for all, write for owner
|
||||
omit-root: true # Exclude the root CA certificate in chain
|
||||
|
||||
# Configure custom commands to execute after certificate issuance, renewal, or failure events
|
||||
post-hooks:
|
||||
on-issuance:
|
||||
command: |
|
||||
echo "Certificate issued for ${CERT_COMMON_NAME}"
|
||||
systemctl reload nginx
|
||||
timeout: 30
|
||||
|
||||
on-renewal:
|
||||
command: |
|
||||
echo "Certificate renewed for ${CERT_COMMON_NAME}"
|
||||
systemctl reload nginx
|
||||
timeout: 30
|
||||
|
||||
on-failure:
|
||||
command: |
|
||||
echo "Certificate operation failed: ${ERROR_MESSAGE}"
|
||||
mail -s "Certificate Alert" admin@company.com < /dev/null
|
||||
timeout: 30
|
||||
```
|
||||
|
||||
To be more specific, the configuration file instructs the agent to:
|
||||
|
||||
- Authenticate with Infisical using the [Universal Auth](/integrations/platforms/certificate-agent#universal-auth) authentication method.
|
||||
- Request a 90-day certificate against the [certificate profile](/documentation/platform/pki/certificates/profiles) named `prof-web-server-12345` with the common name `web.company.com` and the subject alternative names `web.company.com` and `www.company.com`.
|
||||
- Automatically renew the certificate 30 days before expiration by checking the certificate status every 6 hours and retrying up to 3 times with a base delay of 200ms and a maximum delay of 5s if the certificate status check fails.
|
||||
- Store the certificate and its associated private key and certificate chain (excluding the root CA certificate) in the filesystem at the specified paths with the specified permissions.
|
||||
- Execute custom commands after certificate issuance, renewal, or failure events such as reloading an `nginx` service or sending an email notification.
|
||||
|
||||
### Agent Execution
|
||||
|
||||
After creating the configuration file, you can run the command below with the `--config` flag pointing to the path where the agent configuration file is located.
|
||||
|
||||
```bash
|
||||
infisical cert-manager agent --config /path/to/your/agent-config.yaml
|
||||
```
|
||||
|
||||
This will start the agent as a daemon process, continuously monitoring and managing certificates according to your configuration. You can also run it in the foreground for debugging:
|
||||
|
||||
```bash
|
||||
infisical cert-manager agent --config /path/to/your/agent-config.yaml --verbose
|
||||
```
|
||||
|
||||
For production deployments, you may consider running the agent as a system service to ensure it starts automatically and runs continuously.
|
||||
|
||||
### Agent Certificate Configuration Parameters
|
||||
|
||||
The table below provides a complete list of parameters that can be configured in the **certificate configuration** section of the agent configuration file:
|
||||
|
||||
| Parameter | Required | Description |
|
||||
| ------------------------------------ | ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `profile-name` | Yes | The name of the [certificate profile](/documentation/platform/pki/certificates/profiles) to request a certificate against (e.g., `web-server-12345`) |
|
||||
| `project-slug` | Yes | The slug of the project to request a certificate against (e.g., `my-project-slug`) |
|
||||
| `common-name` | Optional | The common name for the certificate (e.g. `www.example.com`) |
|
||||
| `alt-names` | Optional | The list of subject alternative names for the certificate (e.g., `["www.example.com", "api.example.com"]`) |
|
||||
| `ttl` | Optional (uses profile default if not specified) | The time-to-live duration for the certificate, specified as a duration string (e.g. `72h`, `90d`, `1y`, etc.) |
|
||||
| `key-algorithm` | Optional | The algorithm for the certificate key pair. One of: `RSA_2048`, `RSA_3072`, `RSA_4096`, `EC_prime256v1`, `EC_secp384r1`, `EC_secp521r1`. |
|
||||
| `signature-algorithm` | Optional | The algorithm used to sign the certificate. One of: `RSA-SHA256`, `RSA-SHA384`, `RSA-SHA512`, `ECDSA-SHA256`, `ECDSA-SHA384`, `ECDSA-SHA512`. |
|
||||
| `key-usages` | Optional | The list of key usage values for the certificate. One or more of: `digital_signature`, `key_encipherment`, `non_repudiation`, `data_encipherment`, `key_agreement`, `key_cert_sign`, `crl_sign`, `encipher_only`, `decipher_only`. |
|
||||
| `extended-key-usages` | Optional | The list of extended key usage values for the certificate. One or more of: `server_auth`, `client_auth`, `code_signing`, `email_protection`, `timestamping`, `ocsp_signing`. |
|
||||
| `csr-path` | Conditional | The path to a certificate signing request (CSR) file (e.g., `./csr/webserver.csr`, `/etc/ssl/csr.pem`). This is required if using a pre-generated CSR. |
|
||||
| `file-output.private-key.path` | Optional (required if the `csr-path` is not specified) | The path to store the private key (required if not using a CSR) |
|
||||
| `file-output.private-key.permission` | Optional (defaults to `0600`) | The octal file permissions for the private key file (e.g. `0600`) |
|
||||
| `file-output.certificate.path` | Yes | The path to store the issued certificate in the filesystem |
|
||||
| `file-output.certificate.permission` | Optional (defaults to `0600`) | The octal file permissions for the certificate file (e.g. `0644`) |
|
||||
| `file-output.chain.path` | Optional | The path to store the certificate chain in the filesystem. |
|
||||
| `file-output.chain.permission` | Optional (defaults to `0600`) | The octal permissions for the chain file (e.g. `0644`) |
|
||||
| `file-output.chain.omit-root` | Optional (defaults to `true`) | Whether to exclude the root CA certificate from the returned certificate chain |
|
||||
| `lifecycle.renew-before-expiry` | Optional (auto-renewal is disabled if not set) | Duration before certificate expiration when renewal checks should begin, specified as a duration string (e.g. `72h`, `90d`, `1y`, etc.) |
|
||||
| `lifecycle.status-check-interval` | Optional (defaults to `10s`) | How frequently the agent checks certificate status and renewal needs, specified as a duration string (e.g. `10s`, `30m`, `1d`, etc.) |
|
||||
| `post-hooks.on-issuance.command` | Optional | The shell command to execute after a certificate is successfully issued for the first time (e.g., `systemctl reload nginx`, `/usr/local/bin/reload-service.sh`) |
|
||||
| `post-hooks.on-issuance.timeout` | Optional (defaults to `30`) | Maximum execution time in seconds for the on-issuance post-hook command before it is terminated (e.g., `30`, `60`, `120`) |
|
||||
| `post-hooks.on-renewal.command` | Optional | The shell command to execute after a certificate is successfully renewed (e.g., `systemctl reload nginx`, `docker restart web-server`) |
|
||||
| `post-hooks.on-renewal.timeout` | Optional (defaults to `30`) | Maximum execution time in seconds for the on-renewal post-hook command before it is terminated (e.g., `30`, `60`, `120`) |
|
||||
| `post-hooks.on-failure.command` | Optional | The shell command to execute when certificate issuance or renewal fails (e.g., `logger 'Certificate renewal failed'`, `/usr/local/bin/alert.sh`) |
|
||||
| `post-hooks.on-failure.timeout` | Optional (defaults to `30`) | Maximum execution time in seconds for the on-failure post-hook command before it is terminated (e.g., `10`, `30`, `60`) |
|
||||
|
||||
### Post-Event Hooks
|
||||
|
||||
The Infisical Agent supports running custom commands in response to certificate lifecycle events such as issuance, renewal, and failure through the `post-hooks` configuration
|
||||
in the agent configuration file.
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Issuance Hook">
|
||||
Runs when a new certificate is successfully issued:
|
||||
|
||||
```yaml
|
||||
post-hooks:
|
||||
on-issuance:
|
||||
command: |
|
||||
echo "New certificate issued for ${CERT_COMMON_NAME}"
|
||||
chown nginx:nginx ${CERT_FILE_PATH}
|
||||
chmod 644 ${CERT_FILE_PATH}
|
||||
systemctl reload nginx
|
||||
timeout: 30
|
||||
```
|
||||
|
||||
</Tab>
|
||||
|
||||
<Tab title="Renewal Hook">
|
||||
Runs when a certificate is successfully renewed:
|
||||
|
||||
```yaml
|
||||
post-hooks:
|
||||
on-renewal:
|
||||
command: |
|
||||
echo "Certificate renewed for ${CERT_COMMON_NAME}"
|
||||
# Reload services that use the certificate
|
||||
systemctl reload nginx
|
||||
systemctl reload haproxy
|
||||
|
||||
# Send notification
|
||||
curl -X POST https://hooks.slack.com/... \
|
||||
-d "{'text': 'Certificate for ${CERT_COMMON_NAME} renewed successfully'}"
|
||||
timeout: 60
|
||||
```
|
||||
|
||||
</Tab>
|
||||
|
||||
<Tab title="Failure Hook">
|
||||
Runs when certificate operations fail:
|
||||
|
||||
```yaml
|
||||
post-hooks:
|
||||
on-failure:
|
||||
command: |
|
||||
echo "Certificate operation failed for ${CERT_COMMON_NAME}: ${ERROR_MESSAGE}"
|
||||
# Send alert
|
||||
mail -s "Certificate Failure Alert" admin@company.com < /dev/null
|
||||
# Log to syslog
|
||||
logger -p daemon.error "Certificate agent failure: ${ERROR_MESSAGE}"
|
||||
timeout: 30
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
### Retrying mechanism
|
||||
|
||||
The Infisical Agent will automatically attempt to retry any failed API requests including authentication, certificate issuance, and renewal operations.
|
||||
By default, the agent will retry up to 3 times with a base delay of 200ms and a maximum delay of 5s.
|
||||
|
||||
You can configure the retrying mechanism through the agent configuration file:
|
||||
|
||||
```yaml
|
||||
infisical:
|
||||
address: "https://app.infisical.com"
|
||||
retry-strategy:
|
||||
max-retries: 3
|
||||
max-delay: "5s"
|
||||
base-delay: "200ms"
|
||||
# ... rest of the agent configuration file
|
||||
```
|
||||
|
||||
## Example Agent Configuration Files
|
||||
|
||||
Since there are several ways you might want to use the Infisical Agent to request certificates from Infisical,
|
||||
we provide a few example configuration files for common use cases below to help you get started.
|
||||
|
||||
### One-Time Certificate Issuance
|
||||
|
||||
The code snippet below shows a configuration file that instructs the agent to request a certificate from Infisical
|
||||
once without performing any subsequent auto-renewal.
|
||||
|
||||
```yaml
|
||||
version: v1
|
||||
|
||||
# Infisical server configuration
|
||||
infisical:
|
||||
address: "https://app.infisical.com" # The URL of the Infisical instance (e.g. https://app.infisical.com, https://eu.infisical.com, https://your-self-hosted-instance.com)
|
||||
retry-strategy:
|
||||
max-retries: 3
|
||||
max-delay: "5s"
|
||||
base-delay: "200ms"
|
||||
|
||||
# Infisical authentication configuration
|
||||
auth:
|
||||
type: "universal-auth" # The authentication method to use (e.g. universal-auth, kubernetes-auth, azure-auth, gcp-id-token, gcp-iam, aws-iam)
|
||||
config:
|
||||
client-id: "your-client-id"
|
||||
client-secret: "your-client-secret"
|
||||
|
||||
# Certificate configuration
|
||||
certificates:
|
||||
- profile-name: "prof-web-server-12345"
|
||||
project-slug: "my-project-slug"
|
||||
attributes:
|
||||
common-name: "api.example.com"
|
||||
alt-names:
|
||||
- "api.example.com"
|
||||
- "api-v2.example.com"
|
||||
key-algorithm: "RSA_2048"
|
||||
signature-algorithm: "RSA-SHA256"
|
||||
key-usages:
|
||||
- "digital_signature"
|
||||
- "key_encipherment"
|
||||
extended-key-usages:
|
||||
- "server_auth"
|
||||
ttl: "30d"
|
||||
file-output:
|
||||
private-key:
|
||||
path: "/etc/ssl/private/api.example.com.key"
|
||||
permission: "0600"
|
||||
certificate:
|
||||
path: "/etc/ssl/certs/api.example.com.crt"
|
||||
permission: "0644"
|
||||
chain:
|
||||
path: "/etc/ssl/certs/api.example.com.chain.crt"
|
||||
permission: "0644"
|
||||
omit-root: true
|
||||
```
|
||||
|
||||
### One-Time Certificate Issuance using a Pre-Generated CSR
|
||||
|
||||
The code snippet below shows a configuration file that instructs the agent to request a certificate from Infisical
|
||||
once using a pre-generated CSR.
|
||||
|
||||
Note that when `csr-path` is specified:
|
||||
|
||||
- The `private-key` is omitted from the configuration file because we assume that it is pre-generated and managed externally, with only the CSR being submitted to Infisical for signing.
|
||||
- The agent will not be able to perform any auto-renewal operations, as it is assumed to not have access to the private key required to generate a new CSR.
|
||||
|
||||
```yaml
|
||||
version: v1
|
||||
|
||||
# Infisical server configuration
|
||||
infisical:
|
||||
address: "https://app.infisical.com" # The URL of the Infisical instance (e.g. https://app.infisical.com, https://eu.infisical.com, https://your-self-hosted-instance.com)
|
||||
retry-strategy:
|
||||
max-retries: 3
|
||||
max-delay: "5s"
|
||||
base-delay: "200ms"
|
||||
|
||||
# Infisical authentication configuration
|
||||
auth:
|
||||
type: "universal-auth" # The authentication method to use (e.g. universal-auth, kubernetes-auth, azure-auth, gcp-id-token, gcp-iam, aws-iam)
|
||||
config:
|
||||
client-id: "your-client-id"
|
||||
client-secret: "your-client-secret"
|
||||
|
||||
# Certificate configuration
|
||||
certificates:
|
||||
- profile-name: "prof-web-server-12345"
|
||||
project-slug: "my-project-slug"
|
||||
csr-path: "/etc/ssl/requests/api.csr"
|
||||
file-output:
|
||||
certificate:
|
||||
path: "/etc/ssl/certs/api.example.com.crt"
|
||||
permission: "0644"
|
||||
chain:
|
||||
path: "/etc/ssl/certs/api.example.com.chain.crt"
|
||||
permission: "0644"
|
||||
omit-root: true
|
||||
```
|
||||
|
||||
### Certificate Issuance with Automatic Renewal
|
||||
|
||||
The code snippet below shows a configuration file that instructs the agent to request a certificate from Infisical and continuously renew it 14 days before expiration, checking the certificate status every 6 hours.
|
||||
|
||||
```yaml
|
||||
version: v1
|
||||
|
||||
# Infisical server configuration
|
||||
infisical:
|
||||
address: "https://app.infisical.com" # The URL of the Infisical instance (e.g. https://app.infisical.com, https://eu.infisical.com, https://your-self-hosted-instance.com)
|
||||
retry-strategy:
|
||||
max-retries: 3
|
||||
max-delay: "5s"
|
||||
base-delay: "200ms"
|
||||
|
||||
# Infisical authentication configuration
|
||||
auth:
|
||||
type: "universal-auth" # The authentication method to use (e.g. universal-auth, kubernetes-auth, azure-auth, gcp-id-token, gcp-iam, aws-iam)
|
||||
config:
|
||||
client-id: "your-client-id"
|
||||
client-secret: "your-client-secret"
|
||||
|
||||
# Certificate configuration
|
||||
certificates:
|
||||
- profile-name: "prof-web-server-12345"
|
||||
project-slug: "my-project-slug"
|
||||
attributes:
|
||||
common-name: "api.example.com"
|
||||
alt-names:
|
||||
- "api.example.com"
|
||||
- "api-v2.example.com"
|
||||
key-algorithm: "RSA_2048"
|
||||
signature-algorithm: "RSA-SHA256"
|
||||
key-usages:
|
||||
- "digital_signature"
|
||||
- "key_encipherment"
|
||||
extended-key-usages:
|
||||
- "server_auth"
|
||||
ttl: "30d"
|
||||
lifecycle:
|
||||
renew-before-expiry: "14d" # Renew 14 days before expiration
|
||||
status-check-interval: "6h" # Check certificate status every 6 hours
|
||||
file-output:
|
||||
private-key:
|
||||
path: "/etc/ssl/private/api.example.com.key"
|
||||
permission: "0600"
|
||||
certificate:
|
||||
path: "/etc/ssl/certs/api.example.com.crt"
|
||||
permission: "0644"
|
||||
chain:
|
||||
path: "/etc/ssl/certs/api.example.com.chain.crt"
|
||||
permission: "0644"
|
||||
post-hooks:
|
||||
on-issuance:
|
||||
command: "systemctl reload nginx"
|
||||
timeout: 30
|
||||
on-renewal:
|
||||
command: "systemctl reload nginx && logger 'Certificate renewed'"
|
||||
timeout: 30
|
||||
```
|
||||
106
docs/self-hosting/guides/cdn-caching.mdx
Normal file
106
docs/self-hosting/guides/cdn-caching.mdx
Normal file
@@ -0,0 +1,106 @@
|
||||
---
|
||||
title: "CDN Caching for Static Assets"
|
||||
description: "How to set up CDN caching to prevent version skew issues during deployments"
|
||||
---
|
||||
|
||||
This guide explains a common issue with frontend asset caching during deployments and how to solve it using a CDN.
|
||||
|
||||
## The Problem: Version Skew
|
||||
|
||||
Modern frontend build tools like Vite generate content-hashed filenames for static assets (e.g., `main-abc123.js`). Each build produces unique filenames based on file contents. During deployments, this can cause a race condition:
|
||||
|
||||
1. User loads `index.html` which references `main-abc123.js`
|
||||
2. New deployment replaces containers with a new build
|
||||
3. New containers only serve `main-xyz789.js` (new build)
|
||||
4. User's browser requests `main-abc123.js` from cached HTML
|
||||
5. Request returns **404** — the old asset no longer exists
|
||||
|
||||
This results in broken pages, failed SPA navigation, and requires users to manually refresh.
|
||||
|
||||
<Note>
|
||||
This is a documented limitation in Vite's official guidance: [Load Error Handling](https://vite.dev/guide/build#load-error-handling)
|
||||
</Note>
|
||||
|
||||
### Current Behavior
|
||||
|
||||
Infisical includes a built-in workaround that detects version mismatches and triggers a page reload. While functional, this introduces a noticeable delay for users during deployments.
|
||||
|
||||
## The Solution: External Asset Storage
|
||||
|
||||
The solution is to store static assets externally (e.g., S3, GCS, Azure Blob) and serve them through a CDN (e.g., CloudFront, Cloud CDN, Cloudflare). Assets are uploaded **before** container deployment, ensuring old versions remain available.
|
||||
|
||||
### How It Works
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
User[User Browser]
|
||||
CDN[CDN]
|
||||
S3[(Object Storage)]
|
||||
App[Your Infrastructure]
|
||||
|
||||
User --> CDN
|
||||
CDN -->|"/assets/*"| S3
|
||||
CDN -->|"/* (default)"| App
|
||||
```
|
||||
|
||||
The key points:
|
||||
|
||||
- **Asset persistence**: Old assets remain available even after new deployments
|
||||
- **Deployment order**: Upload new assets before deploying new containers
|
||||
- **Long cache TTL**: Content-hashed files can be cached indefinitely (we recommend 30 days)
|
||||
- **Automatic cleanup**: Configure lifecycle rules to expire old assets after 30 days
|
||||
|
||||
At Infisical, we use **CloudFront + S3** for this purpose, but you can use any CDN and object storage combination that fits your infrastructure.
|
||||
|
||||
## Exporting Assets
|
||||
|
||||
Infisical provides a built-in command to export frontend assets from the Docker image:
|
||||
|
||||
```bash
|
||||
# Export as tar archive to stdout
|
||||
docker run --rm infisical/infisical npm run --silent assets:export > assets.tar
|
||||
|
||||
# Extract the archive
|
||||
tar -xf assets.tar
|
||||
ls assets/ # Content-hashed JS/CSS files
|
||||
```
|
||||
|
||||
Or export directly to a mounted directory:
|
||||
|
||||
```bash
|
||||
docker run --rm -v $(pwd)/cdn-assets:/output \
|
||||
infisical/infisical npm run --silent assets:export /output
|
||||
```
|
||||
|
||||
### What Gets Exported
|
||||
|
||||
The command exports the `/assets` directory containing:
|
||||
|
||||
- JavaScript bundles (e.g., `main-abc123.js`, `chunk-def456.js`)
|
||||
- CSS files (e.g., `styles-789xyz.css`)
|
||||
- Other static assets with content hashes
|
||||
|
||||
These files are safe to cache with long TTLs because their filenames change whenever the content changes.
|
||||
|
||||
## Integration with Your Pipeline
|
||||
|
||||
The general deployment flow should be:
|
||||
|
||||
1. **Build** your new Docker image (or pull the official Infisical image)
|
||||
2. **Export** assets using `npm run assets:export`
|
||||
3. **Upload** assets to your object storage
|
||||
4. **Deploy** the new container version
|
||||
|
||||
```bash
|
||||
# Example: Export and upload to S3
|
||||
docker run --rm infisical/infisical:$VERSION npm run --silent assets:export > assets.tar
|
||||
tar -xf assets.tar
|
||||
aws s3 sync assets s3://your-bucket/assets --cache-control "public, max-age=2592000"
|
||||
|
||||
# Then deploy your container
|
||||
```
|
||||
|
||||
<Warning>
|
||||
Always upload assets **before** deploying the new container. This ensures the assets referenced by the new `index.html` exist before users can access them.
|
||||
</Warning>
|
||||
|
||||
@@ -362,6 +362,13 @@ export const AppConnectionsBrowser = () => {
|
||||
"Learn how to connect your Northflank projects to pull secrets from Infisical.",
|
||||
category: "Hosting",
|
||||
},
|
||||
{
|
||||
name: "MongoDB",
|
||||
slug: "mongodb",
|
||||
path: "/integrations/app-connections/mongodb",
|
||||
description: "Learn how to connect your MongoDB to pull secrets from Infisical.",
|
||||
category: "Databases"
|
||||
}
|
||||
].sort(function (a, b) {
|
||||
return a.name.toLowerCase().localeCompare(b.name.toLowerCase());
|
||||
});
|
||||
|
||||
@@ -16,7 +16,8 @@ export const RotationsBrowser = () => {
|
||||
{"name": "PostgreSQL", "slug": "postgres-credentials", "path": "/documentation/platform/secret-rotation/postgres-credentials", "description": "Learn how to automatically rotate PostgreSQL database credentials.", "category": "Databases"},
|
||||
{"name": "Redis", "slug": "redis-credentials", "path": "/documentation/platform/secret-rotation/redis-credentials", "description": "Learn how to automatically rotate Redis database credentials.", "category": "Databases"},
|
||||
{"name": "Microsoft SQL Server", "slug": "mssql-credentials", "path": "/documentation/platform/secret-rotation/mssql-credentials", "description": "Learn how to automatically rotate Microsoft SQL Server credentials.", "category": "Databases"},
|
||||
{"name": "Oracle Database", "slug": "oracledb-credentials", "path": "/documentation/platform/secret-rotation/oracledb-credentials", "description": "Learn how to automatically rotate Oracle Database credentials.", "category": "Databases"}
|
||||
{"name": "Oracle Database", "slug": "oracledb-credentials", "path": "/documentation/platform/secret-rotation/oracledb-credentials", "description": "Learn how to automatically rotate Oracle Database credentials.", "category": "Databases"},
|
||||
{"name": "MongoDB Credentials", "slug": "mongodb-credentials", "path": "/documentation/platform/secret-rotation/mongodb-credentials", "description": "Learn how to automatically rotate MongoDB credentials.", "category": "Databases"}
|
||||
].sort(function(a, b) {
|
||||
return a.name.toLowerCase().localeCompare(b.name.toLowerCase());
|
||||
});
|
||||
|
||||
Reference in New Issue
Block a user