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

Merge branch 'main' into feature/mongodb-secret-rotation

Browse Source
This commit is contained in:
Victor Santos
2025-12-03 17:23:06 -03:00
parent 4ed75e3e0e aa9c125124
commit 42f3566ff4
877 changed files with 20380 additions and 10351 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/documentation/getting-started/concepts/client-integrations.mdx
View File

@@ -24,7 +24,7 @@ Infisical offers a non-exhaustive set of clients and interfaces to support a wid
- [External Secrets Operator (ESO)](https://external-secrets.io/latest/provider/infisical): Allows Infisical to act as a backend provider for syncing secrets into Kubernetes `Secret` objects using the widely adopted External Secrets Operator.
- [Kubernetes PKI Issuer](/documentation/platform/pki/pki-issuer): A controller that issues X.509 certificates from Infisical PKI using the cert-manager Issuer and Certificate CRDs.
- [Kubernetes cert-manager](/documentation/platform/pki/k8s-cert-manager): A controller that issues X.509 certificates from Infisical using the [ACME enrollment method](/documentation/platform/pki/enrollment-methods/acme) configured on a [certificate profile](/documentation/platform/pki/certificates/profiles) using the cert-manager Issuer and Certificate CRDs.
- [Secret Syncs](/integrations/secret-syncs/overview): Native integrations to forward secrets to services like GitHub, GitLab, AWS Secrets Manager, Vercel, and more.

29
docs/documentation/guides/nextjs-vercel.mdx
View File

@@ -183,32 +183,7 @@ At this stage, you know how to use the Infisical CLI to inject secrets into your
## Infisical-Vercel integration for production environment variables
We'll now use the Infisical-Vercel integration send secrets from Infisical to Vercel as production environment variables.
### Infisical-Vercel integration
To begin we have to import the Next.js app into Vercel as a project. [Follow these instructions](https://vercel.com/docs/frameworks/nextjs) to deploy the Next.js app to Vercel.
Next, navigate to your project's integrations tab in Infisical and press on the Vercel tile to grant Infisical access to your Vercel account.
![integrations](../../images/integrations.png)
![integrations vercel authorization](../../images/integrations/vercel/integrations-vercel-auth.png)
<Note>
Opting in for the Infisical-Vercel integration will break end-to-end encryption since Infisical will be able to read
your secrets. This is, however, necessary for Infisical to sync the secrets to Vercel.
Your secrets remain encrypted at rest following our [security guide mechanics](/internals/security).
</Note>
Now select **Production** for (the source) **Environment** and sync it to the **Production Environment** of the (target) application in Vercel.
Lastly, press create integration to start syncing secrets to Vercel.
![integrations vercel](../../images/integrations/vercel/integrations-vercel-create.png)
![integrations vercel](../../images/integrations/vercel/integrations-vercel.png)
You should now see your secret from Infisical appear as production environment variables in your Vercel project.
Use our [Vercel Secret Syncs](../../integrations/secret-syncs/vercel) guide to sync secrets from Infisical to Vercel as production environment variables.
At this stage, you know how to use the Infisical-Vercel integration to sync production secrets from Infisical to Vercel.
@@ -245,4 +220,4 @@ At this stage, you know how to use the Infisical-Vercel integration to sync prod
See also:
- [Documentation for the Infisical CLI](/cli/overview)
- [Documentation for the Vercel integration](/integrations/cloud/vercel)
- [Documentation for the Vercel Secret Sync](../../integrations/secret-syncs/vercel)

12
docs/documentation/platform/integrations.mdx
View File

@@ -1,12 +0,0 @@
---
title: "Integrations"
description: "How to sync your secrets among various 3rd-party services with Infisical."
---
Integrations allow environment variables to be synced across your entire infrastructure from local development to CI/CD and production.
<Card title="View integrations" icon="link" href="/integrations/overview">
View all available integrations and their guides
</Card>
![integrations](../../images/integrations.png)

77
docs/documentation/platform/pam/architecture.mdx Normal file
View 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
![Session Logging](/images/pam/architecture/session-logging.png)
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
View 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**.
![Add Account Button](/images/pam/getting-started/accounts/add-account-button.png)
Next, select the **Resource** that this account belongs to.
![Select Resource](/images/pam/getting-started/accounts/select-resource.png)
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.
![Create Account](/images/pam/getting-started/accounts/create-account.png)
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).

45
docs/documentation/platform/pam/getting-started/resources.mdx Normal file
View File

@@ -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**.
![Add Resource Button](/images/pam/getting-started/resources/add-resource-button.png)
Next, select the type of resource you want to add.
![Select Resource Type](/images/pam/getting-started/resources/select-resource-type.png)
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.
![Create Resource](/images/pam/getting-started/resources/create-resource.png)
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
View 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>

68
docs/documentation/platform/pam/overview.mdx
View File

@@ -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.
![Create Resource](/images/pam/overview/create-resource.png)
## 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>
![Create Account](/images/pam/overview/create-account.png)
### 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*.
![Session Page](/images/pam/overview/session-page.png)
## 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.
![Credential Rotation Account](/images/pam/overview/credential-rotation-account.png)
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).
![Rotate Credentials Account](/images/pam/overview/rotate-credentials-account.png)
## 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.

23
docs/documentation/platform/pam/product-reference/auditing.mdx Normal file
View File

@@ -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.
![Audit Logs](/images/pam/product-reference/auditing/audit-logs.png)

47
docs/documentation/platform/pam/product-reference/credential-rotation.mdx Normal file
View File

@@ -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.*
![Credential Rotation Account](/images/pam/getting-started/resources/credential-rotation-account.png)
</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).
![Rotate Credentials Account](/images/pam/getting-started/resources/rotate-credentials-account.png)
</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>

60
docs/documentation/platform/pam/product-reference/session-recording.mdx Normal file
View File

@@ -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.
![PAM Sessions](/images/pam/product-reference/session-recording/sessions-page.png)
The session details page provides key information, including the complete session logs, connection status, the user who initiated it, and more.
![PAM Individual Session](/images/pam/product-reference/session-recording/individual-session-page.png)
### 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.
![PAM Sessions Search](/images/pam/product-reference/session-recording/sessions-page-search.png)
**Individual session page:** Search within that specific session's logs to pinpoint activity.
![PAM Individual Session Search](/images/pam/product-reference/session-recording/individual-session-page-search.png)
## 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>

60
docs/documentation/platform/pam/session-recording.mdx
View File

@@ -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.
![PAM Sessions](/images/pam/session-recording/sessions-page.png)
The session details page provides key information, including the complete session logs, connection status, the user who initiated it, and more.
![PAM Individual Session](/images/pam/session-recording/individual-session-page.png)
### 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.
![PAM Sessions Search](/images/pam/session-recording/sessions-page-search.png)
![PAM Individual Session Search](/images/pam/session-recording/individual-session-page-search.png)
## 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>

9
docs/documentation/platform/pki/ca/acme-ca.mdx
View File

@@ -17,7 +17,7 @@ their **ACME Directory URL** such as:
- ZeroSSL: `https://acme.zerossl.com/v2/DV90`.
- SSL.com: `https://acme.ssl.com/sslcom-dv-rsa`.
When Infisical requests a certificate from an ACME-compatible CA, it creates a TXT record at `_acme-challenge.{your-domain}` in your configured DNS provider (e.g. Route53, Cloudflare, etc.); this TXT record contains the challenge token issued by the ACME-compatible CA to validate domain control for the requested certificate.
When Infisical requests a certificate from an ACME-compatible CA, it creates a TXT record at `_acme-challenge.{your-domain}` in your configured DNS provider (e.g. Route53, Cloudflare, DNS Made Easy, etc.); this TXT record contains the challenge token issued by the ACME-compatible CA to validate domain control for the requested certificate.
The ACME provider checks for the existence of this TXT record to verify domain control before issuing the certificate back to Infisical.
After validation completes successfully, Infisical automatically removes the TXT record from your DNS provider.
@@ -120,6 +120,11 @@ In the following steps, we explore how to connect Infisical to an ACME-compatibl
For detailed instructions on setting up a Cloudflare connection, see the [Cloudflare Connection](/integrations/app-connections/cloudflare) documentation.
</Tab>
<Tab title="DNS Made Easy">
Navigate to your Certificate Management Project > App Connections and create a new DNS Made Easy connection.
For detailed instructions on setting up a DNS Made Easy connection, see the [DNS Made Easy Connection](/integrations/app-connections/dns-made-easy) documentation.
</Tab>
</Tabs>
</Step>
<Step title="Register an ACME-compatible CA">
@@ -153,7 +158,7 @@ In the following steps, we explore how to connect Infisical to an ACME-compatibl
### Sample request
```bash Request
curl 'https://app.infisical.com/api/v1/pki/ca/acme' \
curl 'https://app.infisical.com/api/v1/cert-manager/ca/acme' \
-H 'Authorization: Bearer <your-access-token>' \
-H 'Content-Type: application/json' \
--data-raw '{

12
docs/documentation/platform/pki/ca/private-ca.mdx
View File

@@ -122,7 +122,7 @@ consisting of an (optional) root CA and an intermediate CA.
### Sample request
```bash Request
curl --location --request POST 'https://app.infisical.com/api/v1/pki/ca' \
curl --location --request POST 'https://app.infisical.com/api/v1/cert-manager/ca/internal' \
--header 'Authorization: Bearer <access-token>' \
--header 'Content-Type: application/json' \
--data-raw '{
@@ -155,7 +155,7 @@ consisting of an (optional) root CA and an intermediate CA.
### Sample request
```bash Request
curl --location --request POST 'https://app.infisical.com/api/v1/pki/ca' \
curl --location --request POST 'https://app.infisical.com/api/v1/cert-manager/ca/internal' \
--header 'Authorization: Bearer <access-token>' \
--header 'Content-Type: application/json' \
--data-raw '{
@@ -183,7 +183,7 @@ consisting of an (optional) root CA and an intermediate CA.
### Sample request
```bash Request
curl --location --request GET 'https://app.infisical.com/api/v1/pki/ca/<intermediate-ca-id>/csr' \
curl --location --request GET 'https://app.infisical.com/api/v1/cert-manager/ca/internal/<intermediate-ca-id>/csr' \
--header 'Authorization: Bearer <access-token>' \
--data-raw ''
```
@@ -204,7 +204,7 @@ consisting of an (optional) root CA and an intermediate CA.
### Sample request
```bash Request
curl --location --request POST 'https://app.infisical.com/api/v1/pki/ca/<root-ca-id>/sign-intermediate' \
curl --location --request POST 'https://app.infisical.com/api/v1/cert-manager/ca/internal/<root-ca-id>/sign-intermediate' \
--header 'Content-Type: application/json' \
--data-raw '{
"csr": "<csr>",
@@ -234,7 +234,7 @@ consisting of an (optional) root CA and an intermediate CA.
### Sample request
```bash Request
curl --location --request POST 'https://app.infisical.com/api/v1/pki/ca/<intermediate-ca-id>/import-certificate' \
curl --location --request POST 'https://app.infisical.com/api/v1/cert-manager/ca/internal/<intermediate-ca-id>/import-certificate' \
--header 'Authorization: Bearer <access-token>' \
--header 'Content-Type: application/json' \
--data-raw '{
@@ -292,7 +292,7 @@ the certificate back to the intermediate CA.
### Sample request
```bash Request
curl --location --request POST 'https://app.infisical.com/api/v1/pki/ca/<ca-id>/renew' \
curl --location --request POST 'https://app.infisical.com/api/v1/cert-manager/ca/internal/<ca-id>/renew' \
--header 'Authorization: Bearer <access-token>' \
--header 'Content-Type: application/json' \
--data-raw '{

2
docs/documentation/platform/pki/certificate-syncs/aws-certificate-manager.mdx
View File

@@ -70,7 +70,7 @@ These permissions allow Infisical to list, import, tag, and manage certificates
```bash Request
curl --request POST \
--url https://app.infisical.com/api/v1/pki/syncs/aws-certificate-manager \
--url https://app.infisical.com/api/v1/cert-manager/syncs/aws-certificate-manager \
--header 'Authorization: Bearer <access-token>' \
--header 'Content-Type: application/json' \
--data '{

4
docs/documentation/platform/pki/certificate-syncs/aws-secrets-manager.mdx
View File

@@ -102,7 +102,7 @@ Any role with these permissions would work such as a custom policy with **Secret
```bash Request
curl --request POST \
--url https://app.infisical.com/api/v1/pki/syncs/aws-secrets-manager \
--url https://app.infisical.com/api/v1/cert-manager/syncs/aws-secrets-manager \
--header 'Authorization: Bearer <access-token>' \
--header 'Content-Type: application/json' \
--data '{
@@ -140,7 +140,7 @@ Any role with these permissions would work such as a custom policy with **Secret
```bash Request
curl --request POST \
--url https://app.infisical.com/api/v1/pki/syncs/aws-secrets-manager \
--url https://app.infisical.com/api/v1/cert-manager/syncs/aws-secrets-manager \
--header 'Authorization: Bearer <access-token>' \
--header 'Content-Type: application/json' \
--data '{

2
docs/documentation/platform/pki/certificate-syncs/azure-key-vault.mdx
View File

@@ -77,7 +77,7 @@ Any role with these permissions would work such as the **Key Vault Certificates
```bash Request
curl --request POST \
--url https://app.infisical.com/api/v1/pki/syncs/azure-key-vault \
--url https://app.infisical.com/api/v1/cert-manager/syncs/azure-key-vault \
--header 'Authorization: Bearer <access-token>' \
--header 'Content-Type: application/json' \
--data '{

4
docs/documentation/platform/pki/certificate-syncs/chef.mdx
View File

@@ -103,7 +103,7 @@ Any role with these permissions would work such as a custom role with **Data Bag
```bash Request
curl --request POST \
--url https://app.infisical.com/api/v1/pki/syncs/chef \
--url https://app.infisical.com/api/v1/cert-manager/syncs/chef \
--header 'Authorization: Bearer <access-token>' \
--header 'Content-Type: application/json' \
--data '{
@@ -140,7 +140,7 @@ Any role with these permissions would work such as a custom role with **Data Bag
```bash Request
curl --request POST \
--url https://app.infisical.com/api/v1/pki/syncs/chef \
--url https://app.infisical.com/api/v1/cert-manager/syncs/chef \
--header 'Authorization: Bearer <access-token>' \
--header 'Content-Type: application/json' \
--data '{

8
docs/documentation/platform/pki/certificates.mdx
View File

@@ -221,7 +221,7 @@ In the following steps, we explore how to issue a X.509 certificate under a CA.
### Sample request
```bash Request
curl --location --request POST 'https://app.infisical.com/api/v3/pki/certificates/issue-certificate' \
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>",
@@ -260,7 +260,7 @@ In the following steps, we explore how to issue a X.509 certificate under a CA.
### Sample request
```bash Request
curl --location --request POST 'https://app.infisical.com/api/v1/pki/certificates/sign-certificate' \
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>",
@@ -337,7 +337,7 @@ openssl verify -verbose -crl_check -crl_download -CAfile chain.pem cert.pem
### Sample request
```bash Request
curl --location --request POST 'https://app.infisical.com/api/v1/pki/certificates/<cert-serial-number>/revoke' \
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 '{
@@ -362,7 +362,7 @@ openssl verify -verbose -crl_check -crl_download -CAfile chain.pem cert.pem
### Sample request
```bash Request
curl --location --request GET 'https://app.infisical.com/api/v1/pki/ca/<ca-id>/crls' \
curl --location --request GET 'https://app.infisical.com/api/v1/cert-manager/ca/internal/<ca-id>/crls' \
--header 'Authorization: Bearer <access-token>'
```

12
docs/documentation/platform/pki/certificates/certificates.mdx
View File

@@ -19,10 +19,12 @@ where you can manage various aspects of its lifecycle including deployment to cl
## Guide to Issuing Certificates
To issue a certificate, you must first create a [certificate profile](/documentation/platform/pki/certificates/profiles) and a [certificate template](/documentation/platform/pki/certificates/templates) to go along with it.
To [issue a certificate](/documentation/platform/pki/concepts/certificate-lifecycle#enrollment-request-%2F-issuance), you must first create a [certificate profile](/documentation/platform/pki/certificates/profiles) and a [certificate template](/documentation/platform/pki/certificates/templates) to go along with it.
The [enrollment method](/documentation/platform/pki/enrollment-methods/overview) configured on the certificate profile determines how a certificate is issued for it.
Refer to the documentation for each enrollment method to learn more about how to issue certificates using it.
- Self-Signed Certificates: To issue a [self-signed certificate](https://en.wikipedia.org/wiki/Self-signed_certificate), you must configure the certificate profile to use the `Self-Signed` issuer type. You can then use the [API enrollment method](/documentation/platform/pki/enrollment-methods/api) to request a self-signed certificate against it.
- CA-Issued Certificates: To issue a certificate from a certificate authority, you must configure the certificate profile to use the `Certificate Authority` issuer type and select the [issuing CA](/documentation/platform/pki/ca/overview) to use. You can then use one of the [enrollment methods](/documentation/platform/pki/enrollment-methods/overview) to request a certificate against it.
Refer to the documentation for each [enrollment method](/documentation/platform/pki/enrollment-methods/overview) to learn more about how to issue certificates using it.
## Guide to Renewing Certificates
@@ -220,7 +222,7 @@ openssl verify -verbose -crl_check -crl_download -CAfile chain.pem cert.pem
### Sample request
```bash Request
curl --location --request POST 'https://app.infisical.com/api/v1/pki/certificates/<cert-serial-number>/revoke' \
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 '{
@@ -245,7 +247,7 @@ openssl verify -verbose -crl_check -crl_download -CAfile chain.pem cert.pem
### Sample request
```bash Request
curl --location --request GET 'https://app.infisical.com/api/v1/pki/ca/<ca-id>/crls' \
curl --location --request GET 'https://app.infisical.com/api/v1/cert-manager/ca/internal/<ca-id>/crls' \
--header 'Authorization: Bearer <access-token>'
```

3
docs/documentation/platform/pki/certificates/profiles.mdx
View File

@@ -21,7 +21,8 @@ Here's some guidance on each field:
- Name: A slug-friendly name for the profile such as `web-servers`.
- Description: An optional description for the profile.
- Issuing CA: The [issuing CA](/documentation/platform/pki/ca/overview) that should be used to issue certificates for the profile.
- Issuer Type: The type of issuer that should be used to issue certificates for the profile; this can be either `Certificate Authority` or `Self-Signed`. If `Self-Signed` is selected, then the profile will only support the API enrollment method and be used to issue self-signed certificates over REST API.
- Issuing CA: The [issuing CA](/documentation/platform/pki/ca/overview) that should be used to issue certificates for the profile when the **Issuer Type** is set to `Certificate Authority`.
- Certificate Template: The [certificate template](/documentation/platform/pki/certificates/templates) that should be used to validate certificate requests for the profile.
- Enrollment Method: The enrollment method that should be used to enroll certificates for the profile such as ACME, EST, API, etc.

4
docs/documentation/platform/pki/enrollment-methods/acme.mdx
View File

@@ -5,7 +5,7 @@ sidebarTitle: "ACME"
## Concept
The ACME enrollment method allows you to issue and manage certificates against a specific [certificate profile](/documentation/platform/pki/certificates/profiles) using the [ACME protocol](https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment).
The ACME enrollment method allows Infisical to act as an ACME server. It lets you request and manage certificates against a specific [certificate profile](/documentation/platform/pki/certificates/profiles) using the [ACME protocol](https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment).
This method is suitable for web servers, load balancers, and other general-purpose servers that can run an [ACME client](https://letsencrypt.org/docs/client-options/) for automated certificate management.
Infisical's ACME enrollment method is based on [RFC 8555](https://datatracker.ietf.org/doc/html/rfc8555/).
@@ -47,7 +47,7 @@ In the following steps, we explore how to issue a X.509 certificate using the AC
```bash
sudo certbot certonly \
--standalone \
--server "https://your-infisical-instance.com/api/v1/pki/certificate-profiles/{profile-id}/acme/directory" \
--server "https://your-infisical-instance.com/api/v1/cert-manager/certificate-profiles/{profile-id}/acme/directory" \
--eab-kid "your-eab-kid" \
--eab-hmac-key "your-eab-secret" \
-d example.infisical.com \

6
docs/documentation/platform/pki/enrollment-methods/api.mdx
View File

@@ -61,7 +61,7 @@ Here, select the certificate profile from step 1 that will be used to issue the
### Sample request
```bash Request
curl --location --request POST 'https://app.infisical.com/api/v1/pki/certificate-profiles' \
curl --location --request POST 'https://app.infisical.com/api/v1/cert-manager/certificate-profiles' \
--header 'Authorization: Bearer <access-token>' \
--header 'Content-Type: application/json' \
--data-raw '{
@@ -105,7 +105,7 @@ Here, select the certificate profile from step 1 that will be used to issue the
### Sample request
```bash Request
curl --location --request POST 'https://app.infisical.com/api/v3/pki/certificates/issue-certificate' \
curl --location --request POST 'https://app.infisical.com/api/v1/cert-manager/certificates/issue-certificate' \
--header 'Authorization: Bearer <access-token>' \
--header 'Content-Type: application/json' \
--data-raw '{
@@ -151,7 +151,7 @@ Here, select the certificate profile from step 1 that will be used to issue the
### Sample request
```bash Request
curl --location --request POST 'https://app.infisical.com/api/v3/pki/certificates/sign-certificate' \
curl --location --request POST 'https://app.infisical.com/api/v1/cert-manager/certificates/sign-certificate' \
--header 'Authorization: Bearer <access-token>' \
--header 'Content-Type: application/json' \
--data-raw '{

11
docs/documentation/platform/pki/integration-guides/apache-certbot.mdx
View File

@@ -1,9 +1,9 @@
---
title: "Apache Server"
description: "Learn how to issue SSL/TLS certificates from Infisical using ACME enrollment on Apache Server with Certbot"
description: "Learn how to issue TLS certificates from Infisical using ACME enrollment on Apache Server with Certbot"
---
This guide demonstrates how to use Infisical to issue SSL/TLS certificates for your [Apache HTTP Server](https://httpd.apache.org/).
This guide demonstrates how to use Infisical to issue TLS certificates for your [Apache HTTP Server](https://httpd.apache.org/).
It uses [Certbot](https://certbot.eff.org/), an installable [ACME](https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment) client, to request and renew certificates from Infisical using the [ACME enrollment method](/documentation/platform/pki/enrollment-methods/acme) configured on a [certificate profile](/documentation/platform/pki/certificates/profiles). Apache benefits from excellent Certbot integration, allowing both certificate-only mode and automatic SSL configuration.
@@ -29,7 +29,7 @@ Before you begin, make sure you have:
From the ACME configuration, gather the following values:
- ACME Directory URL: The URL that Certbot will use to communicate with Infisical's ACME server. This takes the form `https://your-infisical-instance.com/api/v1/pki/certificate-profiles/{profile-id}/acme/directory`.
- ACME Directory URL: The URL that Certbot will use to communicate with Infisical's ACME server. This takes the form `https://your-infisical-instance.com/api/v1/cert-manager/certificate-profiles/{profile-id}/acme/directory`.
- EAB Key Identifier (KID): A unique identifier that tells Infisical which ACME account is making the request.
- EAB Secret: A secret key that authenticates your ACME client with Infisical.
@@ -56,7 +56,7 @@ Before you begin, make sure you have:
```bash
sudo certbot certonly \
--apache \
--server "https://your-infisical-instance.com/api/v1/pki/certificate-profiles/{profile-id}/acme/directory" \
--server "https://your-infisical-instance.com/api/v1/cert-manager/certificate-profiles/{profile-id}/acme/directory" \
--eab-kid "your-eab-key-identifier" \
--eab-hmac-key "your-eab-secret" \
-d example.infisical.com \
@@ -182,4 +182,5 @@ Before you begin, make sure you have:
</Note>
</Step>
</Steps>
</Steps>

16
docs/documentation/platform/pki/integration-guides/gloo-mesh.mdx
View File

@@ -1,13 +1,13 @@
---
title: "Gloo Mesh"
description: "Learn how to automatically provision and manage Istio intermediate CA certificates for Gloo Mesh using Infisical PKI"
description: "Learn how to automatically provision and manage Istio intermediate CA certificates for Gloo Mesh using Infisical"
---
This guide will provide a high level overview on how you can use Infisical PKI and cert-manager to issue Istio intermediate CA certificates for your Gloo Mesh workload clusters. For more background about Istio certificates, see the [Istio CA overview](https://istio.io/latest/docs/concepts/security/#pki).
This guide will provide a high level overview on how you can use Infisical and [cert-manager](https://cert-manager.io/) to issue Istio intermediate CA certificates for your Gloo Mesh workload clusters. For more background about Istio certificates, see the [Istio CA overview](https://istio.io/latest/docs/concepts/security/#pki).
## Overview
In this setup, we will use Infisical PKI to generate and store your root CA and subordinate CAs that are used to generate Istio intermediate CAs for your Gloo Mesh workload clusters.
In this setup, we will use Infisical to generate and store your root CA and subordinate CAs that are used to generate Istio intermediate CAs for your Gloo Mesh workload clusters.
To manage the lifecycle of Istio intermediate CA certificates, you'll also install [cert-manager](https://cert-manager.io/).
Cert-manager is a Kubernetes controller that helps you automate the process of obtaining and renewing certificates from various PKI providers.
@@ -21,19 +21,19 @@ With this approach, you get the following benefits:
## General Setup
The certificate provisioning workflow begins with setting up your PKI hierarchy in Infisical, where you create root and subordinate certificate authorities.
When you deploy a `Certificate` CRD in your workload cluster, `cert-manager` uses the Infisical PKI Issuer controller to authenticate with Infisical using machine identity credentials and request an intermediate CA certificate.
When you deploy a `Certificate` CRD in your workload cluster, `cert-manager` uses the [ACME enrollment method](/documentation/platform/pki/enrollment-methods/acme) configured on a [certificate profile](/documentation/platform/pki/certificates/profiles) to authenticate using EAB credentials and request an intermediate CA certificate.
Infisical verifies the request against your certificate templates and returns the signed certificate.
From there, Istio's control plane will automatically use this intermediate CA to sign leaf certificates for workloads in the service mesh, enabling secure mTLS communication across your entire Gloo Mesh infrastructure.
Follow the [Infisical PKI Issuer guide](/documentation/platform/pki/pki-issuer) for detailed instructions on how to set up the Infisical PKI Issuer and cert-manager for your Istio intermediate CA certificates in Gloo Mesh clusters.
Follow the [Kubernetes cert-manager guide](/documentation/platform/pki/k8s-cert-manager) for detailed instructions on how to set up the Infisical and cert-manager for your Istio intermediate CA certificates in Gloo Mesh clusters.
For Gloo Mesh-specific configuration, ensure that:
- The Certificate resource targets the `istio-system` namespace with `secretName: cacerts`
- Certificate templates in Infisical PKI are configured for intermediate CA usage with appropriate key usage and constraints
- Multiple workload clusters use the same Infisical PKI root to enable cross-cluster mTLS communication
- Certificate profiles in Infisical are configured for intermediate CA usage with appropriate key usage and constraints
- Multiple workload clusters use the same Infisical root to enable cross-cluster mTLS communication
## Using the certificates
Once the `cacerts` Kubernetes secret is created in the `istio-system` namespace, Istio automatically uses the custom CA certificate instead of the default self-signed certificate.
When you deploy applications to your Gloo Mesh service mesh, the workloads will receive leaf certificates signed by your Infisical PKI intermediate CA, enabling secure mTLS communication across your entire mesh infrastructure.
When you deploy applications to your Gloo Mesh service mesh, the workloads will receive leaf certificates signed by your Infisical intermediate CA, enabling secure mTLS communication across your entire mesh infrastructure.

11
docs/documentation/platform/pki/integration-guides/jboss-certbot.mdx
View File

@@ -1,9 +1,9 @@
---
title: "JBoss/WildFly"
description: "Learn how to issue SSL/TLS certificates from Infisical using ACME enrollment on JBoss/WildFly with Certbot"
description: "Learn how to issue TLS certificates from Infisical using ACME enrollment on JBoss/WildFly with Certbot"
---
This guide demonstrates how to use Infisical to issue SSL/TLS certificates for your [JBoss](https://www.jboss.org/)/[WildFly](https://wildfly.org/) application server.
This guide demonstrates how to use Infisical to issue TLS certificates for your [JBoss](https://www.jboss.org/)/[WildFly](https://wildfly.org/) application server.
It uses [Certbot](https://certbot.eff.org/), an installable [ACME](https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment) client, to request and renew certificates from Infisical using the [ACME enrollment method](/documentation/platform/pki/enrollment-methods/acme) configured on a [certificate profile](/documentation/platform/pki/certificates/profiles). JBoss/WildFly requires certificates in Java keystore format, which this guide addresses through the certificate conversion process.
@@ -30,7 +30,7 @@ Before you begin, make sure you have:
From the ACME configuration, gather the following values:
- ACME Directory URL: The URL that Certbot will use to communicate with Infisical's ACME server. This takes the form `https://your-infisical-instance.com/api/v1/pki/certificate-profiles/{profile-id}/acme/directory`.
- ACME Directory URL: The URL that Certbot will use to communicate with Infisical's ACME server. This takes the form `https://your-infisical-instance.com/api/v1/cert-manager/certificate-profiles/{profile-id}/acme/directory`.
- EAB Key Identifier (KID): A unique identifier that tells Infisical which ACME account is making the request.
- EAB Secret: A secret key that authenticates your ACME client with Infisical.
@@ -67,7 +67,7 @@ Before you begin, make sure you have:
```bash
sudo certbot certonly \
--standalone \
--server "https://your-infisical-instance.com/api/v1/pki/certificate-profiles/{profile-id}/acme/directory" \
--server "https://your-infisical-instance.com/api/v1/cert-manager/certificate-profiles/{profile-id}/acme/directory" \
--eab-kid "your-eab-key-identifier" \
--eab-hmac-key "your-eab-secret" \
-d example.infisical.com \
@@ -223,4 +223,5 @@ Before you begin, make sure you have:
Certbot automatically renews certificates when they are within 30 days of expiration using its built-in systemd timer. The deploy hook above will run after each successful renewal, handling the keystore conversion and service restart automatically. Because JBoss/WildFly requires the standalone authenticator (which stops the service temporarily), plan for brief service interruptions during renewal.
</Note>
</Step>
</Steps>
</Steps>

8
docs/documentation/platform/pki/integration-guides/nginx-certbot.mdx
View File

@@ -1,9 +1,9 @@
---
title: "Nginx"
description: "Learn how to issue SSL/TLS certificates from Infisical using ACME enrollment on Nginx with Certbot"
description: "Learn how to issue TLS certificates from Infisical using ACME enrollment on Nginx with Certbot"
---
This guide demonstrates how to use Infisical to issue SSL/TLS certificates for your [Nginx](https://nginx.org/) server.
This guide demonstrates how to use Infisical to issue TLS certificates for your [Nginx](https://nginx.org/) server.
It uses [Certbot](https://certbot.eff.org/), an installable [ACME](https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment) client, to request and renew certificates from Infisical using the [ACME enrollment method](/documentation/platform/pki/enrollment-methods/acme) configured on a [certificate profile](/documentation/platform/pki/certificates/profiles).
@@ -29,7 +29,7 @@ Before you begin, make sure you have:
From the ACME configuration, gather the following values:
- ACME Directory URL: The URL that Certbot will use to communicate with Infisical's ACME server. This takes the form `https://your-infisical-instance.com/api/v1/pki/certificate-profiles/{profile-id}/acme/directory`.
- ACME Directory URL: The URL that Certbot will use to communicate with Infisical's ACME server. This takes the form `https://your-infisical-instance.com/api/v1/cert-manager/certificate-profiles/{profile-id}/acme/directory`.
- EAB Key Identifier (KID): A unique identifier that tells Infisical which ACME account is making the request.
- EAB Secret: A secret key that authenticates your ACME client with Infisical.
@@ -56,7 +56,7 @@ Before you begin, make sure you have:
```bash
sudo certbot certonly \
--nginx \
--server "https://your-infisical-instance.com/api/v1/pki/certificate-profiles/{profile-id}/acme/directory" \
--server "https://your-infisical-instance.com/api/v1/cert-manager/certificate-profiles/{profile-id}/acme/directory" \
--eab-kid "your-eab-key-identifier" \
--eab-hmac-key "your-eab-secret" \
-d example.infisical.com \

11
docs/documentation/platform/pki/integration-guides/tomcat-certbot.mdx
View File

@@ -1,9 +1,9 @@
---
title: "Tomcat"
description: "Learn how to issue SSL/TLS certificates from Infisical using ACME enrollment on Tomcat with Certbot"
description: "Learn how to issue TLS certificates from Infisical using ACME enrollment on Tomcat with Certbot"
---
This guide demonstrates how to use Infisical to issue SSL/TLS certificates for your [Apache Tomcat](https://tomcat.apache.org/) application server.
This guide demonstrates how to use Infisical to issue TLS certificates for your [Apache Tomcat](https://tomcat.apache.org/) application server.
It uses [Certbot](https://certbot.eff.org/), an installable [ACME](https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment) client, to request and renew certificates from Infisical using the [ACME enrollment method](/documentation/platform/pki/enrollment-methods/acme) configured on a [certificate profile](/documentation/platform/pki/certificates/profiles). Unlike web servers with native Certbot plugins, Tomcat requires certificates to be manually configured after issuance.
@@ -29,7 +29,7 @@ Before you begin, make sure you have:
From the ACME configuration, gather the following values:
- ACME Directory URL: The URL that Certbot will use to communicate with Infisical's ACME server. This takes the form `https://your-infisical-instance.com/api/v1/pki/certificate-profiles/{profile-id}/acme/directory`.
- ACME Directory URL: The URL that Certbot will use to communicate with Infisical's ACME server. This takes the form `https://your-infisical-instance.com/api/v1/cert-manager/certificate-profiles/{profile-id}/acme/directory`.
- EAB Key Identifier (KID): A unique identifier that tells Infisical which ACME account is making the request.
- EAB Secret: A secret key that authenticates your ACME client with Infisical.
@@ -64,7 +64,7 @@ Before you begin, make sure you have:
```bash
sudo certbot certonly \
--standalone \
--server "https://your-infisical-instance.com/api/v1/pki/certificate-profiles/{profile-id}/acme/directory" \
--server "https://your-infisical-instance.com/api/v1/cert-manager/certificate-profiles/{profile-id}/acme/directory" \
--eab-kid "your-eab-key-identifier" \
--eab-hmac-key "your-eab-secret" \
-d example.infisical.com \
@@ -248,4 +248,5 @@ Before you begin, make sure you have:
Since Tomcat reads certificates from the file system on startup, you only need to restart the service after certificate renewal. The certificate file paths in `/etc/letsencrypt/live/` are symbolic links that automatically point to the latest certificates.
</Note>
</Step>
</Steps>
</Steps>

19
docs/documentation/platform/pki/integration-guides/windows-server-acme.mdx
View File

@@ -1,9 +1,9 @@
---
title: "Windows Server"
description: "Learn how to issue SSL/TLS certificates from Infisical using ACME enrollment on Windows Server with win-acme"
description: "Learn how to issue TLS certificates from Infisical using ACME enrollment on Windows Server with win-acme"
---
This guide demonstrates how to use Infisical to issue SSL/TLS certificates for your [Windows Server](https://www.microsoft.com/en-us/windows-server) environments.
This guide demonstrates how to use Infisical to issue TLS certificates for your [Windows Server](https://www.microsoft.com/en-us/windows-server) environments.
It uses [win-acme](https://www.win-acme.com/), a feature-rich [ACME](https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment) client designed specifically for Windows, to request and renew certificates from Infisical using the [ACME enrollment method](/documentation/platform/pki/enrollment-methods/acme) configured on a [certificate profile](/documentation/platform/pki/certificates/profiles). Win-acme offers excellent integration with IIS, Windows Certificate Store, and various certificate storage options.
@@ -28,7 +28,7 @@ Before you begin, make sure you have:
From the ACME configuration, gather the following values:
- ACME Directory URL: The URL that win-acme will use to communicate with Infisical's ACME server. This takes the form `https://your-infisical-instance.com/api/v1/pki/certificate-profiles/{profile-id}/acme/directory`.
- ACME Directory URL: The URL that win-acme will use to communicate with Infisical's ACME server. This takes the form `https://your-infisical-instance.com/api/v1/cert-manager/certificate-profiles/{profile-id}/acme/directory`.
- EAB Key Identifier (KID): A unique identifier that tells Infisical which ACME account is making the request.
- EAB Secret: A secret key that authenticates your ACME client with Infisical.
@@ -67,7 +67,7 @@ Before you begin, make sure you have:
Run the following win-acme command to request a certificate from Infisical:
```powershell
wacs.exe --target manual --host example.infisical.com --baseuri "https://your-infisical-instance.com/api/v1/pki/certificate-profiles/{profile-id}/acme/directory" --eab-key-identifier "your-eab-key-identifier" --eab-key "your-eab-secret" --validation selfhosting --store pemfiles --pemfilespath "C:\certificates" --verbose
wacs.exe --target manual --host example.infisical.com --baseuri "https://your-infisical-instance.com/api/v1/cert-manager/certificate-profiles/{profile-id}/acme/directory" --eab-key-identifier "your-eab-key-identifier" --eab-key "your-eab-secret" --validation selfhosting --store pemfiles --pemfilespath "C:\certificates" --verbose
```
For guidance on each parameter:
@@ -87,7 +87,7 @@ Before you begin, make sure you have:
<Note>
Replace the placeholder values with your actual configuration:
- `example.infisical.com`: Your actual domain name
- `https://your-infisical-instance.com/api/v1/pki/certificate-profiles/{profile-id}/acme/directory`: Your Infisical ACME endpoint from Step 1
- `https://your-infisical-instance.com/api/v1/cert-manager/certificate-profiles/{profile-id}/acme/directory`: Your Infisical ACME endpoint from Step 1
- `your-eab-key-identifier` and `your-eab-secret`: Your External Account Binding credentials from Step 1
- `C:\certificates`: Your desired certificate storage location
</Note>
@@ -101,21 +101,21 @@ Before you begin, make sure you have:
Store certificates directly in the [Windows Certificate Store](https://docs.microsoft.com/en-us/windows-hardware/drivers/install/certificate-stores) for integration with IIS and other Windows services:
```powershell
wacs.exe --target manual --host example.infisical.com --baseuri "https://your-infisical-instance.com/api/v1/pki/certificate-profiles/{profile-id}/acme/directory" --eab-key-identifier "your-eab-key-identifier" --eab-key "your-eab-secret" --validation selfhosting --store certificatestore --verbose
wacs.exe --target manual --host example.infisical.com --baseuri "https://your-infisical-instance.com/api/v1/cert-manager/certificate-profiles/{profile-id}/acme/directory" --eab-key-identifier "your-eab-key-identifier" --eab-key "your-eab-secret" --validation selfhosting --store certificatestore --verbose
```
</Tab>
<Tab title="PFX Files">
Generate [PFX files](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certutil) with password protection for easy deployment across Windows environments:
```powershell
wacs.exe --target manual --host example.infisical.com --baseuri "https://your-infisical-instance.com/api/v1/pki/certificate-profiles/{profile-id}/acme/directory" --eab-key-identifier "your-eab-key-identifier" --eab-key "your-eab-secret" --validation selfhosting --store pfxfile --pfxfilepath "C:\certificates" --pfxpassword "your-secure-password" --verbose
wacs.exe --target manual --host example.infisical.com --baseuri "https://your-infisical-instance.com/api/v1/cert-manager/certificate-profiles/{profile-id}/acme/directory" --eab-key-identifier "your-eab-key-identifier" --eab-key "your-eab-secret" --validation selfhosting --store pfxfile --pfxfilepath "C:\certificates" --pfxpassword "your-secure-password" --verbose
```
</Tab>
<Tab title="IIS Central SSL">
For IIS Central SSL store integration in high-scale environments:
```powershell
wacs.exe --target manual --host example.infisical.com --baseuri "https://your-infisical-instance.com/api/v1/pki/certificate-profiles/{profile-id}/acme/directory" --eab-key-identifier "your-eab-key-identifier" --eab-key "your-eab-secret" --validation selfhosting --store centralssl --centralsslstore "C:\CentralSSL" --verbose
wacs.exe --target manual --host example.infisical.com --baseuri "https://your-infisical-instance.com/api/v1/cert-manager/certificate-profiles/{profile-id}/acme/directory" --eab-key-identifier "your-eab-key-identifier" --eab-key "your-eab-secret" --validation selfhosting --store centralssl --centralsslstore "C:\CentralSSL" --verbose
```
</Tab>
</Tabs>
@@ -129,7 +129,7 @@ Before you begin, make sure you have:
Include the `--setuptaskscheduler` parameter in your initial command to automatically create the renewal task:
```powershell
wacs.exe --target manual --host example.infisical.com --baseuri "https://your-infisical-instance.com/api/v1/pki/certificate-profiles/{profile-id}/acme/directory" --eab-key-identifier "your-eab-key-identifier" --eab-key "your-eab-secret" --validation selfhosting --store pemfiles --pemfilespath "C:\certificates" --setuptaskscheduler --verbose
wacs.exe --target manual --host example.infisical.com --baseuri "https://your-infisical-instance.com/api/v1/cert-manager/certificate-profiles/{profile-id}/acme/directory" --eab-key-identifier "your-eab-key-identifier" --eab-key "your-eab-secret" --validation selfhosting --store pemfiles --pemfilespath "C:\certificates" --setuptaskscheduler --verbose
```
**Option 2: Test manual renewal**
@@ -191,4 +191,5 @@ Before you begin, make sure you have:
</Tab>
</Tabs>
</Step>
</Steps>

267
docs/documentation/platform/pki/k8s-cert-manager.mdx Normal file
View File

@@ -0,0 +1,267 @@
---
title: "Kubernetes cert-manager"
description: "Learn how to automatically provision and manage TLS certificates in Kubernetes using Infisical"
---
## Concept
This guide demonstrates how to use Infisical to issue TLS certificates back to your Kubernetes environment using [cert-manager](https://cert-manager.io/).
It uses the [ACME issuer type](https://cert-manager.io/docs/configuration/acme/) to request and renew certificates automatically from Infisical
using the [ACME enrollment method](/documentation/platform/pki/enrollment-methods/acme) configured on a [certificate profile](/documentation/platform/pki/certificates/profiles). The issuer is perfect at obtaining X.509 certificates for Ingresses and other Kubernetes resources and can automatically renew them before expiration.
The typical workflow involves installing `cert-manager` and configuring resources that represent the connection details to Infisical as well as the certificates you want to issue.
Each issued certificate and its corresponding private key are stored in a Kubernetes `Secret`.
We recommend reading the official [cert-manager documentation](https://cert-manager.io/docs/) for a complete overview.
For the ACME-specific configuration, refer to the [ACME section](https://cert-manager.io/docs/configuration/acme/).
## Workflow
A typical workflow for using cert-manager with Infisical via ACME consists of the following steps:
1. Create a [certificate profile](/documentation/platform/pki/certificates/profiles) in Infisical with the [ACME enrollment method](/documentation/platform/pki/enrollment-methods/acme) configured on it.
2. Install `cert-manager` in your Kubernetes cluster.
3. Create a Kubernetes `Secret` containing the EAB (External Account Binding) credentials for the ACME certificate profile.
4. Create an `Issuer` or `ClusterIssuer` resource that connects to the desired Infisical [certificate profile](/documentation/platform/pki/certificates/profiles).
5. Create a `Certificate` resource defining the certificate you wish to issue and the target `Secret` where the certificate and private key will be stored.
6. Use the resulting Kubernetes `Secret` in your Ingresses or other resources.
## Guide
The following steps show how to install cert-manager (using `kubectl`) and obtain certificates from Infisical.
<Steps>
<Step title="Create a certificate profile with ACME as the enrollment method in Infisical">
Follow the instructions [here](/documentation/platform/pki/enrollment-methods/acme) to create a certificate profile that uses ACME enrollment.
After completion, you will have the following values:
- **ACME Directory URL**
- **EAB Key ID (KID)**
- **EAB Secret**
These will be needed in later steps.
<Note>
Currently, the Infisical ACME enrollment method only supports authentication via dedicated EAB credentials generated per certificate profile.
Support for [Kubernetes Auth](/documentation/platform/identities/kubernetes-auth) is planned for the near future.
</Note>
</Step>
<Step title="Install cert-manager">
Install cert-manager in your Kubernetes cluster by following the official guide [here](https://cert-manager.io/docs/installation/) or by applying the manifest directly:
```bash
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.19.1/cert-manager.yaml
```
</Step>
<Step title="Create a Kubernetes Secret for the Infisical ACME EAB credentials">
Create a Kubernetes `Secret` that contains the **EAB Secret (HMAC key)** obtained in step 1.
The cert-manager uses this secret to authenticate with the Infisical ACME server.
<Tabs>
<Tab title="kubectl command">
```bash
kubectl create secret generic infisical-acme-eab-secret \
--namespace <namespace_you_want_to_issue_certificates_in> \
--from-literal=eabSecret=<eab_secret>
```
</Tab>
<Tab title="Configuration file">
```yaml acme-eab-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: infisical-acme-eab-secret
namespace: <namespace_you_want_to_issue_certificates_in>
data:
eabSecret: <eab_secret>
```
```bash
kubectl apply -f acme-eab-secret.yaml
```
</Tab>
</Tabs>
</Step>
<Step title="Create the cert-manager Issuer connecting to Infisical ACME server">
Next, create a cert-manager `Issuer` (or `ClusterIssuer`) by replacing the placeholders `<acme_server_url>`, `<your_email>`, and `<acme_eab_kid>` in the configuration below and applying it.
This resource configures cert-manager to use your Infisical PKI collection's ACME server for certificate issuance.
```yaml issuer-infisical.yaml
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: issuer-infisical
namespace: <namespace_you_want_to_issue_certificates_in>
spec:
acme:
# ACME server URL from your Infisical certificate profile (Step 1)
server: <acme_server_url>
# Email address for ACME account
# (any valid email works; currently ignored by Infisical)
email: <your_email>
externalAccountBinding:
# EAB Key ID from Step 1
keyID: <acme_eab_kid>
# Reference to the Kubernetes Secret containing the EAB
# HMAC key (created in Step 3)
keySecretRef:
name: infisical-acme-eab-secret
key: eabSecret
privateKeySecretRef:
name: issuer-infisical-account-key
solvers:
- http01:
ingress:
# Replace with your actual ingress class if different
className: nginx
```
```
kubectl apply -f issuer-infisical.yaml
```
You can check that the issuer was created successfully by running the following command:
```bash
kubectl get issuers.cert-manager.io -n <namespace_of_issuer> -o wide
```
```bash
NAME AGE
issuer-infisical 21h
```
<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.
- 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/
</Note>
</Step>
<Step title="Create the Certificate">
Finally, request a certificate from Infisical ACME server by creating a cert-manager `Certificate` resource.
This configuration file specifies the details of the (end-entity/leaf) certificate to be issued.
```yaml certificate-issuer.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: certificate-by-issuer
namespace: <namespace_you_want_to_issue_certificates_in>
spec:
dnsNames:
- certificate-by-issuer.example.com
# name of the resulting Kubernetes Secret
secretName: certificate-by-issuer
# total validity period of the certificate
duration: 48h
# cert-manager will attempt renewal 12 hours before expiry
renewBefore: 12h
privateKey:
algorithm: ECDSA
# uses NIST P-256 curve
size: 256
issuerRef:
name: issuer-infisical
```
The above sample configuration file specifies a certificate to be issued with the dns name `certificate-by-issuer.example.com` and ECDSA private key using the P-256 curve, valid for 48 hours; the certificate will be automatically renewed by `cert-manager` 12 hours before expiry.
The certificate is issued by the issuer `issuer-infisical` created in the previous step and the resulting certificate and private key will be stored in a secret named `certificate-by-issuer`.
Note that the full list of the fields supported on the `Certificate` resource can be found in the API reference documentation [here](https://cert-manager.io/docs/reference/api-docs/#cert-manager.io/v1.CertificateSpec).
You can check that the certificate was created successfully by running the following command:
```bash
kubectl get certificates -n <namespace_of_your_certificate> -o wide
```
```bash
NAME READY SECRET ISSUER STATUS AGE
certificate-by-issuer True certificate-by-issuer issuer-infisical Certificate is up to date and has not expired 20h
```
</Step>
<Step title="Use Certificate in Kubernetes Secret">
Since the actual certificate and private key are stored in a Kubernetes secret, we can check that the secret was created successfully by running the following command:
```bash
kubectl get secret certificate-by-issuer -n <namespace_of_your_certificate>
```
```bash
NAME TYPE DATA AGE
certificate-by-issuer kubernetes.io/tls 2 26h
```
We can `describe` the secret to get more information about it:
```bash
kubectl describe secret certificate-by-issuer -n default
```
```bash
Name: certificate-by-issuer
Namespace: default
Labels: controller.cert-manager.io/fao=true
Annotations: cert-manager.io/alt-names:
cert-manager.io/certificate-name: certificate-by-issuer
cert-manager.io/common-name:
cert-manager.io/alt-names: certificate-by-issuer.example.com
cert-manager.io/ip-sans:
cert-manager.io/issuer-group: cert-manager.io
cert-manager.io/issuer-kind: Issuer
cert-manager.io/issuer-name: issuer-infisical
cert-manager.io/uri-sans:
Type: kubernetes.io/tls
Data
====
ca.crt: 1306 bytes
tls.crt: 2380 bytes
tls.key: 227 bytes
```
Here, `ca.crt` is the Root CA certificate, `tls.crt` is the requested certificate followed by the certificate chain, and `tls.key` is the private key for the certificate.
We can decode the certificate and print it out using `openssl`:
```bash
kubectl get secret certificate-by-issuer -n default -o jsonpath='{.data.tls\.crt}' | base64 --decode | openssl x509 -text -noout
```
In any case, the certificate is ready to be used as Kubernetes Secret by your Kubernetes resources.
</Step>
</Steps>
## FAQ
<AccordionGroup>
<Accordion title="What fields can be configured on the Certificate resource?">
The full list of the fields supported on the `Certificate` resource can be found in the API reference documentation [here](https://cert-manager.io/docs/reference/api-docs/#cert-manager.io/v1.CertificateSpec).
<Note>
Currently, not all fields are supported by the Infisical PKI ACME server.
</Note>
</Accordion>
<Accordion title="Can certificates be renewed automatically?">
Yes. `cert-manager` will automatically renew certificates according to the `renewBefore` threshold of expiry as
specified in the corresponding `Certificate` resource.
You can read more about the `renewBefore` field [here](https://cert-manager.io/docs/reference/api-docs/#cert-manager.io/v1.CertificateSpec).
</Accordion>
</AccordionGroup>

305
docs/documentation/platform/pki/pki-issuer.mdx
View File

@@ -1,305 +0,0 @@
---
title: "Kubernetes Issuer"
description: "Learn how to automatically provision and manage TLS certificates in Kubernetes using Infisical PKI"
---
## Concept
The Infisical PKI Issuer is an installable Kubernetes [cert-manager](https://cert-manager.io/) controller that uses Infisical PKI to sign certificate requests. The issuer is perfect for getting X.509 certificates for ingresses and other Kubernetes resources and capable of automatically renewing certificates as needed.
As part of the workflow, you install `cert-manager`, the Infisical PKI Issuer, and configure resources to represent the connection details to your Infisical PKI and the certificates you wish to issue. Each issued certificate and corresponding private key is made available in a Kubernetes secret.
We recommend reading the [cert-manager documentation](https://cert-manager.io/docs/) for a fuller understanding of all the moving parts.
## Workflow
A typical workflow for using the Infisical PKI Issuer to issue certificates for your Kubernetes resources consists of the following steps:
1. Creating a machine identity in Infisical.
2. Creating a Kubernetes secret to store the credentials of the machine identity.
3. Installing `cert-manager` into your Kubernetes cluster.
4. Installing the Infisical PKI Issuer controller into your Kubernetes cluster.
5. Creating an `Issuer` or `ClusterIssuer` resource in your Kubernetes cluster to represent the Infisical PKI issuer you wish to use.
6. Create the approver policy to accept certificate request.
7. Creating a `Certificate` resource in your Kubernetes cluster to represent a certificate you wish to issue. As part of this step, you specify the Kubernetes `Secret` to create and store the issued certificate and private key.
8. Consuming the issued certificate across your Kubernetes resources from the specified Kubernetes `Secret`.
## Guide
In the following steps, we explore how to install the Infisical PKI Issuer using [kubectl](https://github.com/kubernetes/kubectl) and use it to obtain certificates for your Kubernetes resources.
<Steps>
<Step title="Create an identity in Infisical">
Follow the instructions [here](/documentation/platform/identities/universal-auth) to configure a [machine identity](/documentation/platform/identities/machine-identities) in Infisical with Universal Auth.
By the end of this step, you should have a **Client ID** and **Client Secret** on hand as part of the Universal Auth configuration for the Infisical PKI Issuer to authenticate with Infisical; this will be useful in steps 4 and 5.
<Note>
Currently, the Infisical PKI Issuer only supports authenticating with Infisical via the [Universal Auth](/documentation/platform/identities/universal-auth) authentication method.
We're planning to add support for [Kubernetes Auth](/documentation/platform/identities/kubernetes-auth) in the near future.
</Note>
</Step>
<Step title="Install cert-manager">
Install `cert-manager` into your Kubernetes cluster by following the instructions [here](https://cert-manager.io/docs/installation/) or by running the following command:
```bash
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.15.3/cert-manager.yaml
```
</Step>
<Step title="Install the Issuer Controller">
Install the Infisical PKI Issuer controller into your Kubernetes cluster using one of the following methods:
<Tabs>
<Tab title="Helm">
```bash
helm repo add infisical-helm-charts 'https://dl.cloudsmith.io/public/infisical/helm-charts/helm/charts/'
helm install infisical-pki-issuer infisical-helm-charts/infisical-pki-issuer
```
</Tab>
<Tab title="kubectl">
```bash
kubectl apply -f https://raw.githubusercontent.com/Infisical/infisical-issuer/main/build/install.yaml
```
</Tab>
</Tabs>
</Step>
<Step title="Create Kubernetes Secret for Infisical PKI Issuer">
Start by creating a Kubernetes `Secret` containing the **Client Secret** from step 1. As mentioned previously, this will be used by the Infisical PKI issuer to authenticate with Infisical.
<Tabs>
<Tab title="kubectl command">
```bash
kubectl create secret generic issuer-infisical-client-secret \
--namespace <namespace_you_want_to_issue_certificates_in> \
--from-literal=clientSecret=<client_secret>
```
</Tab>
<Tab title="Configuration file">
```yaml secret-issuer.yaml
apiVersion: v1
kind: Secret
metadata:
name: issuer-infisical-client-secret
namespace: <namespace_you_want_to_issue_certificates_in>
data:
clientSecret: <client_secret>
```
```bash
kubectl apply -f secret-issuer.yaml
```
</Tab>
</Tabs>
</Step>
<Step title="Create Infisical PKI Issuer">
Next, create the Infisical PKI Issuer by filling out `url`, `clientId`, `projectId` or `certificateTemplateName`, and applying the following configuration file for the `Issuer` resource.
This configuration file specifies the connection details to your Infisical PKI CA to be used for issuing certificates.
```yaml infisical-issuer.yaml
apiVersion: infisical-issuer.infisical.com/v1alpha1
kind: Issuer
metadata:
name: issuer-infisical
namespace: <namespace_you_want_to_issue_certificates_in>
spec:
url: "https://app.infisical.com" # the URL of your Infisical instance
projectId: <project_id> # the ID of the project you want to use to issue certificates
certificateTemplateName: <certificate_template_name> # the name of the certificate template you want to use to issue certificates against
authentication:
universalAuth:
clientId: <client_id> # the Client ID from step 1
secretRef: # reference to the Secret created in step 4
name: "issuer-infisical-client-secret"
key: "clientSecret"
```
```
kubectl apply -f infisical-issuer.yaml
```
You can check that the issuer was created successfully by running the following command:
```bash
kubectl get issuers.infisical-issuer.infisical.com -n <namespace_of_issuer> -o wide
```
```bash
NAME AGE
issuer-infisical 21h
```
<Note>
An `Issuer` is a namespaced resource, and it is not possible to issue certificates from an `Issuer` in a different namespace.
This means you will need to create an `Issuer` in each namespace you wish to obtain `Certificates` in.
If you want to create a single `Issuer` that can be consumed in multiple namespaces, you should consider creating a `ClusterIssuer` resource. This is almost identical to the `Issuer` resource, however is non-namespaced so it can be used to issue `Certificates` across all namespaces.
You can read more about the `Issuer` and `ClusterIssuer` resources [here](https://cert-manager.io/docs/configuration/).
</Note>
</Step>
<Step title="Create Approver Policy">
If you create a `CertificateRequest` now, you'll notice it's neither approved nor denied. This is expected because by default cert-manager approver controller requires an approver-policy.
To enable approval, create the following YAML file and apply it:
```yaml infisical-approver-policy.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: infisical-issuer-approver
rules:
# Permission to approve or deny CertificateRequests for signers in cert-manager.io API group
- apiGroups: ['cert-manager.io']
resources: ['signers']
verbs: ['approve']
resourceNames:
# Grant approval permissions for namespaced issuers
- "issuers.infisical-issuer.infisical.com/default.issuer-infisical"
# Grant approval permissions for cluster-scoped issuers
- "clusterissuers.infisical-issuer.infisical.com/clusterissuer-infisical"
---
# Bind the cert-manager service account to the new role
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: infisical-issuer-approver-binding
subjects:
- kind: ServiceAccount
name: cert-manager
namespace: cert-manager
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: infisical-issuer-approver
```
```
kubectl apply -f infisical-approver-policy.yaml
```
This configuration creates a `ClusterRole` named `infisical-issuer-approver` that grants approval permissions for specific Infisical issuer types. It then binds this role to the cert-manager service account, allowing it to approve certificate requests from your Infisical issuers.
For information, check out [cert manager approval policy doc](https://cert-manager.io/docs/policy/approval/approver-policy/).
</Step>
<Step title="Create Certificate">
Finally, create a `Certificate` by applying the following configuration file.
This configuration file specifies the details of the (end-entity/leaf) certificate to be issued.
```yaml certificate-issuer.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: certificate-by-issuer
namespace: <namespace_you_want_to_issue_certificates_in>
spec:
commonName: certificate-by-issuer.example.com # the common name for the certificate
secretName: certificate-by-issuer # the name of the Kubernetes Secret to create and store the certificate and private key in
issuerRef:
name: issuer-infisical
group: infisical-issuer.infisical.com
kind: Issuer
privateKey: # the algorithm and key size to use
algorithm: ECDSA
size: 256
duration: 48h # the ttl for the certificate
renewBefore: 12h # the time before the certificate expiry that the certificate should be automatically renewed
```
The above sample configuration file specifies a certificate to be issued with the common name `certificate-by-issuer.example.com` and ECDSA private key using the P-256 curve, valid for 48 hours; the certificate will be automatically renewed by `cert-manager` 12 hours before expiry.
The certificate is issued by the issuer `issuer-infisical` created in the previous step and the resulting certificate and private key will be stored in a secret named `certificate-by-issuer`.
Note that the full list of the fields supported on the `Certificate` resource can be found in the API reference documentation [here](https://cert-manager.io/docs/reference/api-docs/#cert-manager.io/v1.CertificateSpec).
You can check that the certificate was created successfully by running the following command:
```bash
kubectl get certificates -n <namespace_of_your_certificate> -o wide
```
```bash
NAME READY SECRET ISSUER STATUS AGE
certificate-by-issuer True certificate-by-issuer issuer-infisical Certificate is up to date and has not expired 20h
```
</Step>
<Step title="Use Certificate in Kubernetes Secret">
Since the actual certificate and private key are stored in a Kubernetes secret, we can check that the secret was created successfully by running the following command:
```bash
kubectl get secret certificate-by-issuer -n <namespace_of_your_certificate>
```
```bash
NAME TYPE DATA AGE
certificate-by-issuer kubernetes.io/tls 2 26h
```
We can `describe` the secret to get more information about it:
```bash
kubectl describe secret certificate-by-issuer -n default
```
```bash
Name: certificate-by-issuer
Namespace: default
Labels: controller.cert-manager.io/fao=true
Annotations: cert-manager.io/alt-names:
cert-manager.io/certificate-name: certificate-by-issuer
cert-manager.io/common-name: certificate-by-issuer.example.com
cert-manager.io/ip-sans:
cert-manager.io/issuer-group: infisical-issuer.infisical.com
cert-manager.io/issuer-kind: Issuer
cert-manager.io/issuer-name: issuer-infisical
cert-manager.io/uri-sans:
Type: kubernetes.io/tls
Data
====
ca.crt: 1306 bytes
tls.crt: 2380 bytes
tls.key: 227 bytes
```
Here, `ca.crt` is the Root CA certificate, `tls.crt` is the requested certificate followed by the certificate chain, and `tls.key` is the private key for the certificate.
We can decode the certificate and print it out using `openssl`:
```bash
kubectl get secret certificate-by-issuer -n default -o jsonpath='{.data.tls\.crt}' | base64 --decode | openssl x509 -text -noout
```
In any case, the certificate is ready to be used as Kubernetes Secret by your Kubernetes resources.
</Step>
</Steps>
## FAQ
<AccordionGroup>
<Accordion title="What fields can be configured on the Certificate resource?">
The full list of the fields supported on the `Certificate` resource can be found in the API reference documentation [here](https://cert-manager.io/docs/reference/api-docs/#cert-manager.io/v1.CertificateSpec).
<Note>
Currently, not all fields are supported by the Infisical PKI Issuer.
</Note>
</Accordion>
<Accordion title="Can certificates be renewed automatically?">
Yes. `cert-manager` will automatically renew certificates according to the `renewBefore` threshold of expiry as
specified in the corresponding `Certificate` resource.
You can read more about the `renewBefore` field [here](https://cert-manager.io/docs/reference/api-docs/#cert-manager.io/v1.CertificateSpec).
</Accordion>
<Accordion title="Why is my CertificateRequest not being approved, showing 'CertificateRequest has not been approved yet. Ignoring.'?">
If you see log messages similar to:
```
"CertificateRequest has not been approved yet. Ignoring.","controller":"certificaterequest","controllerGroup":"cert-manager.io","controllerKind":"CertificateRequest","CertificateRequest":{"name":"skynet-infisical-rta-rsa2048-1","namespace":"infisical-system"},"namespace":"infisical-system","name":"skynet-infisical-rta-rsa2048-1","reconcileID":"bfb7cad9-d867-45b5-b3a3-0139e731b7a6"}
```
This indicates that the `CertificateRequest` has been created, but `cert-manager` has not yet approved it. This typically occurs because a necessary approver policy is missing. Refer to the documentation above to create an approver policy.
</Accordion>
</AccordionGroup>