Merge branch 'main' into ENG-2706
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Available"
|
||||
openapi: "GET /api/v1/app-connections/oci/available"
|
||||
---
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
title: "Create"
|
||||
openapi: "POST /api/v1/app-connections/oci"
|
||||
---
|
||||
|
||||
<Note>
|
||||
Check out the configuration docs for [OCI Connections](/integrations/app-connections/oci) to learn how to obtain the required credentials.
|
||||
</Note>
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Delete"
|
||||
openapi: "DELETE /api/v1/app-connections/oci/{connectionId}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Get by ID"
|
||||
openapi: "GET /api/v1/app-connections/oci/{connectionId}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Get by Name"
|
||||
openapi: "GET /api/v1/app-connections/oci/connection-name/{connectionName}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "List"
|
||||
openapi: "GET /api/v1/app-connections/oci"
|
||||
---
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
title: "Update"
|
||||
openapi: "PATCH /api/v1/app-connections/oci/{connectionId}"
|
||||
---
|
||||
|
||||
<Note>
|
||||
Check out the configuration docs for [OCI Connections](/integrations/app-connections/oci) to learn how to obtain the required credentials.
|
||||
</Note>
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Create"
|
||||
openapi: "POST /api/v1/pki/subscribers"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Delete"
|
||||
openapi: "DELETE /api/v1/pki/subscribers/{subscriberName}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Issue Certificate"
|
||||
openapi: "POST /api/v1/pki/subscribers/{subscriberName}/issue-cert"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "List Certificates"
|
||||
openapi: "GET /api/v1/pki/subscribers/{subscriberName}/certificates"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Retrieve"
|
||||
openapi: "GET /api/v1/pki/subscribers/{subscriberName}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Sign Certificate"
|
||||
openapi: "POST /api/v1/pki/subscribers/{subscriberName}/sign-certificate"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Update"
|
||||
openapi: "PATCH /api/v1/pki/subscribers/{subscriberName}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Create"
|
||||
openapi: "POST /api/v1/secret-syncs/oci-vault"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Delete"
|
||||
openapi: "DELETE /api/v1/secret-syncs/oci-vault/{syncId}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Get by ID"
|
||||
openapi: "GET /api/v1/secret-syncs/oci-vault/{syncId}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Get by Name"
|
||||
openapi: "GET /api/v1/secret-syncs/oci-vault/sync-name/{syncName}"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Import Secrets"
|
||||
openapi: "POST /api/v1/secret-syncs/oci-vault/{syncId}/import-secrets"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "List"
|
||||
openapi: "GET /api/v1/secret-syncs/oci-vault"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Remove Secrets"
|
||||
openapi: "POST /api/v1/secret-syncs/oci-vault/{syncId}/remove-secrets"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Sync Secrets"
|
||||
openapi: "POST /api/v1/secret-syncs/oci-vault/{syncId}/sync-secrets"
|
||||
---
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Update"
|
||||
openapi: "PATCH /api/v1/secret-syncs/oci-vault/{syncId}"
|
||||
---
|
||||
@@ -1,4 +1,4 @@
|
||||
---
|
||||
title: "Add Host"
|
||||
openapi: "POST /api/v1/ssh/host-groups/{sshHostGroupId}/hosts"
|
||||
openapi: "POST /api/v1/ssh/host-groups/{sshHostGroupId}/hosts/{hostId}"
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
---
|
||||
title: "Remove Host"
|
||||
openapi: "DELETE /api/v1/ssh/host-groups/{sshHostGroupId}/hosts/{sshHostId}"
|
||||
openapi: "DELETE /api/v1/ssh/host-groups/{sshHostGroupId}/hosts/{hostId}"
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
---
|
||||
title: "List My Hosts"
|
||||
openapi: "GET /api/v1/ssh/hosts/"
|
||||
openapi: "GET /api/v1/ssh/hosts"
|
||||
---
|
||||
|
||||
@@ -13,7 +13,7 @@ To enable and configure GitHub Organization Synchronization, follow these steps:
|
||||
|
||||
<Steps>
|
||||
<Step title="Set up GitHub organization configuration">
|
||||
1. Navigate to **Organization Settings** and select the **Security Tab**.
|
||||
1. Navigate to the **Single Sign-On (SSO)** page and select the **Provisioning** tab.
|
||||

|
||||
2. Click the **Configure** button and provide the name of your GitHub Organization.
|
||||

|
||||
|
||||
@@ -18,7 +18,9 @@ Prerequisites:
|
||||
|
||||
<Steps>
|
||||
<Step title="Prepare the LDAP configuration in Infisical">
|
||||
In Infisical, head to your Organization Settings > Security > LDAP and select **Manage**.
|
||||
In Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Select **Connect** for **LDAP**.
|
||||
|
||||

|
||||
|
||||
Next, input your LDAP server settings.
|
||||
|
||||
|
||||
@@ -27,7 +27,9 @@ Prerequisites:
|
||||

|
||||
</Step>
|
||||
<Step title="Prepare the LDAP configuration in Infisical">
|
||||
In Infisical, head to your Organization Settings > Security > LDAP and select **Manage**.
|
||||
In Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Select **Connect** for **LDAP**.
|
||||
|
||||

|
||||
|
||||
Next, input your JumpCloud LDAP server settings.
|
||||
|
||||
|
||||
@@ -75,8 +75,8 @@ In the following steps, we explore how to issue a X.509 certificate under a CA.
|
||||
Here's some guidance on each field:
|
||||
|
||||
- Friendly Name: A friendly name for the certificate; this is only for display and defaults to the common name of the certificate if left empty.
|
||||
- Common Name (CN): The (common) name for the certificate like `service.acme.com`.
|
||||
- Alternative Names (SANs): A comma-delimited list of Subject Alternative Names (SANs) for the certificate; these can be host names or email addresses like `app1.acme.com, app2.acme.com`.
|
||||
- Common Name (CN): The common name for the certificate like `service.acme.com`.
|
||||
- Alternative Names (SANs): A comma-delimited list of Subject Alternative Names (SANs) for the certificate; these can be hostnames or email addresses like `app1.acme.com, app2.acme.com`.
|
||||
- TTL: The lifetime of the certificate in seconds.
|
||||
- Key Usage: The key usage extension of the certificate.
|
||||
- Extended Key Usage: The extended key usage extension of the certificate.
|
||||
@@ -240,7 +240,7 @@ openssl verify -crl_check -CAfile chain.pem -CRLfile crl.pem cert.pem
|
||||
```
|
||||
|
||||
Note that you can also obtain the CRL from the certificate itself by
|
||||
referencing the CRL distribution point extension on the certificate itself.
|
||||
referencing the CRL distribution point extension on the certificate.
|
||||
|
||||
To check a certificate against the CRL distribution point specified within it with OpenSSL, you can use the following command:
|
||||
|
||||
|
||||
@@ -4,9 +4,10 @@ sidebarTitle: "Overview"
|
||||
description: "Learn how to create a Private CA hierarchy and issue X.509 certificates."
|
||||
---
|
||||
|
||||
Infisical can be used to create a Private Certificate Authority (CA) hierarchy and issue X.509 certificates for internal use. This allows you to manage your own PKI infrastructure and issue digital certificates for services, applications, and devices.
|
||||
Infisical can be used to create a Private Certificate Authority (CA) hierarchy and issue X.509 certificates for internal use. This allows you to manage your own PKI infrastructure and issue digital certificates for subscribers such as services, applications, and devices.
|
||||
|
||||
Infisical's internal PKI offering is split into two modules:
|
||||
Infisical's PKI offering is split into three components:
|
||||
|
||||
- [Private CA](/documentation/platform/pki/private-ca): Infisical lets you create private CAs, including root and intermediary CAs.
|
||||
- [Certificates](/documentation/platform/pki/certificates): Infisical allows you to issue X.509 certificates using the private CAs you create.
|
||||
- [Certificate Authorities](/documentation/platform/pki/private-ca): Create and manage private CAs, including root and intermediate CAs.
|
||||
- [Subscribers](/documentation/platform/pki/subscribers): Define and manage entities that will request X.509 certificates from CAs. This module provides a centralized view of all subscribers, enabling you to issue certificates and monitor their status.
|
||||
- [Certificates](/documentation/platform/pki/certificates): Track and monitor issued X.509 certificates, maintaining a comprehensive inventory of all active and expired certificates.
|
||||
|
||||
@@ -7,7 +7,7 @@ description: "Learn how to create a Private CA hierarchy with Infisical."
|
||||
## Concept
|
||||
|
||||
The first step to creating your Internal PKI is to create a Private Certificate Authority (CA) hierarchy that is a structure of entities
|
||||
used to issue digital certificates for services, applications, and devices.
|
||||
used to issue digital certificates for your [subscribers](/documentation/platform/pki/subscribers).
|
||||
|
||||
<div align="center">
|
||||
|
||||
@@ -24,7 +24,7 @@ graph TD
|
||||
|
||||
A typical workflow for setting up a Private CA hierarchy consists of the following steps:
|
||||
|
||||
1. Configuring an Infisical root CA with details like name, validity period, and path length — This step is optional if you wish to use an external root CA.
|
||||
1. Configuring an Infisical root CA with details like name, validity period, and path length — This step is optional if you wish to use an external root CA with Infisical only serving the intermediate CAs.
|
||||
2. Configuring and chaining intermediate CA(s) with details like name, validity period, path length, and imported certificate to your Root CA.
|
||||
3. Managing the CA lifecycle events such as CA succession.
|
||||
|
||||
@@ -99,7 +99,7 @@ consisting of an (optional) root CA and an intermediate CA.
|
||||

|
||||
|
||||
Great! You've successfully created a Private CA hierarchy with a root CA and an intermediate CA.
|
||||
Now check out the [Certificates](/documentation/platform/pki/certificates) page to learn more about how to issue X.509 certificates using the intermediate CA.
|
||||
Now check out the [Subscribers](/documentation/platform/pki/subscribers) page to learn more about how to issue X.509 certificates using the intermediate CA.
|
||||
|
||||
2.3b. If you have an external root CA, select **External CA** for the **Parent CA Type** field.
|
||||
|
||||
@@ -110,7 +110,7 @@ consisting of an (optional) root CA and an intermediate CA.
|
||||
Finally, press **Install** to import the certificate and certificate chain as part of the installation step for the intermediate CA
|
||||
|
||||
Great! You've successfully created a Private CA hierarchy with an intermediate CA chained to an external root CA.
|
||||
Now check out the [Certificates](/documentation/platform/pki/certificates) page to learn more about how to issue X.509 certificates using the intermediate CA.
|
||||
Now check out the [Subscribers](/documentation/platform/pki/subscribers) page to learn more about how to issue X.509 certificates using the intermediate CA.
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
@@ -255,7 +255,7 @@ consisting of an (optional) root CA and an intermediate CA.
|
||||
}
|
||||
```
|
||||
|
||||
Great! You’ve successfully created a Private CA hierarchy with a root CA and an intermediate CA. Now check out the Certificates page to learn more about how to issue X.509 certificates using the intermediate CA.
|
||||
Great! You’ve successfully created a Private CA hierarchy with a root CA and an intermediate CA. Now check out the [Subscribers](/documentation/platform/pki/subscribers) page to learn more about how to issue X.509 certificates using the intermediate CA.
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
@@ -0,0 +1,130 @@
|
||||
---
|
||||
title: "Subscribers"
|
||||
sidebarTitle: "Subscribers"
|
||||
description: "Learn how to manage PKI subscribers and issue X.509 certificates for them."
|
||||
---
|
||||
|
||||
## Concept
|
||||
|
||||
In Infisical PKI, subscribers are logical representations of entities such as devices, servers, applications that request and receive certificates from Certificate Authorities (CAs).
|
||||
|
||||
<div align="center">
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Issuing CA] --> C1[Certificate]
|
||||
C1 --> S1[Subscriber]
|
||||
A --> C2[Certificate]
|
||||
C2 --> S2[Subscriber]
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
## Workflow
|
||||
|
||||
The typical workflow for managing subscribers consists of the following steps:
|
||||
|
||||
1. Creating a subscriber and defining which (issuing) CA will issue X.509 certificates for it as well as attributes to be included on the certificates including common name, subject alternative names, TLL, etc.
|
||||
2. Requesting for a certificate against the subscriber with or without a certificate signing request (CSR).
|
||||
3. Managing certificate lifecycle events such as certificate renewal and revocation. As part of the certificate revocation flow,
|
||||
you can also query for a Certificate Revocation List [CRL](https://en.wikipedia.org/wiki/Certificate_revocation_list), a time-stamped, signed
|
||||
data structure issued by a CA containing a list of revoked certificates to check if a certificate has been revoked.
|
||||
|
||||
<Note>
|
||||
Note that this workflow can be executed via the Infisical UI or manually such
|
||||
as via API.
|
||||
</Note>
|
||||
|
||||
## Guide to Issuing Certificates with Subscribers
|
||||
|
||||
In the following steps, we explore how to issue a X.509 certificate for a subscriber.
|
||||
|
||||
<Steps>
|
||||
<Step title="Creating a subscriber">
|
||||
A subscriber is the logical representation of an entity that requests and
|
||||
receives certificates from a CA. With a subscriber, you can specify the
|
||||
attributes that must be present on the X.509 certificates issued for it.
|
||||
|
||||
Head to your Infisical PKI Project > Subscribers to create a subscriber.
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
Here's some guidance on each field.
|
||||
|
||||
- Subscriber Name: A slug-friendly name for the subscriber such as `web-service`.
|
||||
- Issuing CA: The Certificate Authority (CA) that will issue X.509 certificates for the subscriber.
|
||||
- Common Name (CN): The common name to be included on certificates to be issued to the subscriber.
|
||||
- Subject Alternative Names (SANs): A comma-delimited list of Subject Alternative Names (SANs) to be included on certificates; these can be hostnames or email addresses like `app1.acme.com, app2.acme.com`.
|
||||
- TTL: The lifetime of the certificate.
|
||||
- Key Usage: The key usage extension of the certificate.
|
||||
- Extended Key Usage: The extended key usage extension of the certificate.
|
||||
|
||||
<Note>
|
||||
It's possible to issue certificates for a subscriber with or without a certificate signing request (CSR).
|
||||
- If requesting without a CSR, the attributes specified on the subscriber will be used to issue a certificate for the subscriber.
|
||||
- If requesting with a CSR, the attributes on it will be validated against the attributes specified on the subscriber
|
||||
and a certificate is only issued if they comply.
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
<Step title="Requesting a certificate">
|
||||
Once you have created a subscriber from step 1, you can issue a certificate for it.
|
||||
|
||||
Press on the subscriber you want to issue a certificate for and click on the **Issue Certificate** button on that subscriber's page.
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Guide to Revoking Certificates
|
||||
|
||||
In the following steps, we explore how to revoke a X.509 certificate and obtain a Certificate Revocation List (CRL) for a CA.
|
||||
|
||||
<Steps>
|
||||
<Step title="Revoking a Certificate">
|
||||
Assuming that you've issued a certificate for a subscriber, you can revoke it by
|
||||
selecting the **Revoke Certificate** option on the certificate you wish to revoke
|
||||
on the subscriber's page.
|
||||
|
||||

|
||||
|
||||
</Step>
|
||||
<Step title="Obtaining a CRL">
|
||||
In order to check the revocation status of a certificate, you can check it
|
||||
against the CRL of a CA by heading to its Issuing CA and downloading the CRL.
|
||||
|
||||

|
||||
|
||||
To verify a certificate against the
|
||||
downloaded CRL with OpenSSL, you can use the following command:
|
||||
|
||||
```bash
|
||||
openssl verify -crl_check -CAfile chain.pem -CRLfile crl.pem cert.pem
|
||||
```
|
||||
|
||||
Note that you can also obtain the CRL from the certificate itself by
|
||||
referencing the CRL distribution point extension on the certificate.
|
||||
|
||||
To check a certificate against the CRL distribution point specified within it with OpenSSL, you can use the following command:
|
||||
|
||||
```bash
|
||||
openssl verify -verbose -crl_check -crl_download -CAfile chain.pem cert.pem
|
||||
```
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## FAQ
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="What is the workflow for renewing a certificate?">
|
||||
To renew a certificate, you have to issue a new certificate for the same
|
||||
subscriber. The original certificate will continue to be valid through its
|
||||
original TTL unless explicitly revoked.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
@@ -5,23 +5,23 @@ description: "Learn how to enable a set of policies to manage changes to sensiti
|
||||
|
||||
<Info>
|
||||
Approval Workflows is a paid feature.
|
||||
|
||||
If you're using Infisical Cloud, then it is available under the **Pro Tier** and **Enterprise Tire**.
|
||||
|
||||
If you're using Infisical Cloud, then it is available under the **Pro Tier** and **Enterprise Tier**.
|
||||
If you're self-hosting Infisical, then you should contact [email protected] to purchase an enterprise license to use it.
|
||||
</Info>
|
||||
|
||||
## Problem at hand
|
||||
|
||||
Updating secrets in high-stakes environments (e.g., production) can have a number of problematic issues:
|
||||
- Most developers should not have access to secrets in production environments. Yet, they are the ones who often need to add new secrets or change the existing ones. Many organizations have in-house policies with regards to what person should be contacted in the case of needing to make changes to secrets. This slows down software development lifecycle and distracts engineers from working on things that matter the most.
|
||||
- As a general rule, before making changes in production environments, those changes have to be looked over by at least another person. An extra pair of eyes can help reduce the risk of human error and make sure that the change will not affect the application in an unintended way.
|
||||
- After making updates to secrets, the corresponding applications need to be redeployed with the right set of secrets and configurations. This process is often not automated and hence prone to human error.
|
||||
Updating secrets in high-stakes environments (e.g., production) can have a number of problematic issues:
|
||||
- Most developers should not have access to secrets in production environments. Yet, they are the ones who often need to add new secrets or change the existing ones. Many organizations have in-house policies with regards to what person should be contacted in the case of needing to make changes to secrets. This slows down software development lifecycle and distracts engineers from working on things that matter the most.
|
||||
- As a general rule, before making changes in production environments, those changes have to be looked over by at least another person. An extra pair of eyes can help reduce the risk of human error and make sure that the change will not affect the application in an unintended way.
|
||||
- After making updates to secrets, the corresponding applications need to be redeployed with the right set of secrets and configurations. This process is often not automated and hence prone to human error.
|
||||
|
||||
## Solution
|
||||
|
||||
As a wide-spread software engineering practice, developers have to submit their code as a PR that needs to be approved before the code is merged into the main branch.
|
||||
As a wide-spread software engineering practice, developers have to submit their code as a PR that needs to be approved before the code is merged into the main branch.
|
||||
|
||||
In a similar way, to solve the above-mentioned issues, Infisical provides a feature called `Approval Workflows` for secret management. This is a set of policies and workflows that help advance access controls, compliance procedures, and stability of a particular environment. In other words, **Approval Workflows** help you secure, stabilize, and streamline the change of secrets in high-stakes environments.
|
||||
In a similar way, to solve the above-mentioned issues, Infisical provides a feature called `Approval Workflows` for secret management. This is a set of policies and workflows that help advance access controls, compliance procedures, and stability of a particular environment. In other words, **Approval Workflows** help you secure, stabilize, and streamline the change of secrets in high-stakes environments.
|
||||
|
||||
### Setting a policy
|
||||
|
||||
@@ -33,6 +33,10 @@ First, you would need to create a set of policies for a certain environment. In
|
||||
|
||||
The enforcement level determines how strict the policy is. A **Hard** enforcement level means that any change that matches the policy will need full approval prior merging. A **Soft** enforcement level allows for break glass functionality on the request. If a change request is bypassed, the approvers will be notified via email.
|
||||
|
||||
### Self approvals
|
||||
|
||||
If the **Self Approvals** option is enabled, users who are designated as approvers on the policy can approve requests that they themselves have submitted.
|
||||
|
||||
### Example of creating a change policy
|
||||
|
||||
When creating a policy, you can choose the type of policy you want to create. In this case, we will be creating a `Change Policy`. Other types of policies include `Access Policy` that creates policies for **[Access Requests](/documentation/platform/access-controls/access-requests)**.
|
||||
@@ -41,10 +45,18 @@ When creating a policy, you can choose the type of policy you want to create. In
|
||||
|
||||
### Example of updating secrets with Approval workflows
|
||||
|
||||
When a user submits a change to an enviropnment that is under a particular policy, a corresponsing change request will go to a predefined approver (or multiple approvers).
|
||||
When a user submits a change to an environment that is under a particular policy, a corresponding change request will go to a predefined approver (or multiple approvers).
|
||||
|
||||

|
||||
|
||||
Approvers are notified by email and/or Slack as soon as the request is initiated. In the Infisical Dashboard, they will be able to `approve` and `merge` (or `deny`) a request for a change in a particular environment. After that, depending on the workflows setup, the change will be automatically propagated to the right applications (e.g., using [Infisical Kubernetes Operator](https://infisical.com/docs/integrations/platforms/kubernetes)).
|
||||
|
||||

|
||||
|
||||
## FAQ
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Is it possible to disable self-approval for policies?">
|
||||
Yes, if you'd like to require an approval from an approver other than the one who created the request, then you can disable the **Self Approvals** feature inside of your target policy.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
@@ -15,7 +15,7 @@ Prerequisites:
|
||||
|
||||
<Steps>
|
||||
<Step title="Create a SCIM token in Infisical">
|
||||
In Infisical, head to your Organization Settings > Security > SCIM Configuration and
|
||||
In Infisical, head to the **Single Sign-On (SSO)** page and select the **Provisioning** tab. Under SCIM Configuration,
|
||||
press the **Enable SCIM provisioning** toggle to allow Azure to provision/deprovision users for your organization.
|
||||
|
||||

|
||||
|
||||
@@ -15,7 +15,7 @@ Prerequisites:
|
||||
|
||||
<Steps>
|
||||
<Step title="Create a SCIM token in Infisical">
|
||||
In Infisical, head to your Organization Settings > Security > SCIM Configuration and
|
||||
In Infisical, head to the **Single Sign-On (SSO)** page and select the **Provisioning** tab. Under SCIM Configuration,
|
||||
press the **Enable SCIM provisioning** toggle to allow JumpCloud to provision/deprovision users and user groups for your organization.
|
||||
|
||||

|
||||
|
||||
@@ -15,7 +15,7 @@ Prerequisites:
|
||||
|
||||
<Steps>
|
||||
<Step title="Create a SCIM token in Infisical">
|
||||
In Infisical, head to your Organization Settings > Security > SCIM Configuration and
|
||||
In Infisical, head to the **Single Sign-On (SSO)** page and select the **Provisioning** tab. Under SCIM Configuration,
|
||||
press the **Enable SCIM provisioning** toggle to allow Okta to provision/deprovision users and user groups for your organization.
|
||||
|
||||

|
||||
|
||||
@@ -39,8 +39,8 @@ description: "Learn how to configure Auth0 OIDC for Infisical SSO."
|
||||
|
||||
</Step>
|
||||
<Step title="Finish configuring OIDC in Infisical">
|
||||
3.1. Back in Infisical, in the Organization settings > Security > OIDC, click **Connect**.
|
||||

|
||||
3.1. Back in Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Click **Connect** for **OIDC**.
|
||||

|
||||
|
||||
3.2. For configuration type, select **Discovery URL**. Then, set **Discovery Document URL**, **JWT Signature Algorithm**, **Client ID**, and **Client Secret** from step 2.1 and 2.2.
|
||||

|
||||
|
||||
@@ -12,7 +12,9 @@ description: "Learn how to configure Auth0 SAML for Infisical SSO."
|
||||
|
||||
<Steps>
|
||||
<Step title="Prepare the SAML SSO configuration in Infisical">
|
||||
In Infisical, head to Organization Settings > Security and click **Connect** for SAML under the Connect to an Identity Provider section. Select Auth0, then click **Connect** again.
|
||||
In Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Click **Connect** for **SAML** under the Connect to an Identity Provider section. Select **Auth0**, then click **Connect** again.
|
||||
|
||||

|
||||
|
||||
Next, note the **Application Callback URL** and **Audience** to use when configuring the Auth0 SAML application.
|
||||
|
||||
|
||||
@@ -12,7 +12,9 @@ description: "Learn how to configure Microsoft Entra ID for Infisical SSO."
|
||||
|
||||
<Steps>
|
||||
<Step title="Prepare the SAML SSO configuration in Infisical">
|
||||
In Infisical, head to Organization Settings > Security and click **Connect** for SAML under the Connect to an Identity Provider section. Select Azure / Entra, then click **Connect** again.
|
||||
In Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Click **Connect** for **SAML** under the Connect to an Identity Provider section. Select **Azure / Entra**, then click **Connect** again.
|
||||
|
||||

|
||||
|
||||
Next, copy the **Reply URL (Assertion Consumer Service URL)** and **Identifier (Entity ID)** to use when configuring the Azure SAML application.
|
||||
|
||||
|
||||
@@ -28,8 +28,8 @@ Prerequisites:
|
||||
1.4. Access the IdP’s OIDC discovery document (usually located at `https://<idp-domain>/.well-known/openid-configuration`). This document contains important endpoints such as authorization, token, userinfo, and keys.
|
||||
</Step>
|
||||
<Step title="Finish configuring OIDC in Infisical">
|
||||
2.1. Back in Infisical, in the Organization settings > Security > OIDC, click Connect.
|
||||

|
||||
2.1. Back in Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Select **Connect** for **OIDC**.
|
||||

|
||||
|
||||
2.2. You can configure OIDC either through the Discovery URL (Recommended) or by inputting custom endpoints.
|
||||
|
||||
|
||||
@@ -12,7 +12,9 @@ description: "Learn how to configure Google SAML for Infisical SSO."
|
||||
|
||||
<Steps>
|
||||
<Step title="Prepare the SAML SSO configuration in Infisical">
|
||||
In Infisical, head to Organization Settings > Security and click **Connect** for SAML under the Connect to an Identity Provider section. Select Google, then click **Connect** again.
|
||||
In Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Click **Connect** for **SAML** under the Connect to an Identity Provider section. Select **Google**, then click **Connect** again.
|
||||
|
||||

|
||||
|
||||
Next, note the **ACS URL** and **SP Entity ID** to use when configuring the Google SAML application.
|
||||
|
||||
|
||||
@@ -12,7 +12,9 @@ description: "Learn how to configure JumpCloud SAML for Infisical SSO."
|
||||
|
||||
<Steps>
|
||||
<Step title="Prepare the SAML SSO configuration in Infisical">
|
||||
In Infisical, head to Organization Settings > Security and click **Connect** for SAML under the Connect to an Identity Provider section. Select JumpCloud, then click **Connect** again.
|
||||
In Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Click **Connect** for **SAML** under the Connect to an Identity Provider section. Select **JumpCloud**, then click **Connect** again.
|
||||
|
||||

|
||||
|
||||
Next, copy the **ACS URL** and **SP Entity ID** to use when configuring the JumpCloud SAML application.
|
||||
|
||||
|
||||
@@ -53,7 +53,7 @@ Infisical groups not present in their groups claim.
|
||||
2.1. In Infisical, create any groups you would like to sync users to. Make sure the name of the Infisical group is an exact match of the Keycloak group name.
|
||||

|
||||
|
||||
2.2. Next, enable **OIDC Group Membership Mapping** in Organization Settings > Security.
|
||||
2.2. Next, enable **OIDC Group Membership Mapping** on the **Single Sign-On (SSO)** page under the **General** tab.
|
||||

|
||||
|
||||
2.3. The next time a user logs in they will be synced to their matching Keycloak groups.
|
||||
|
||||
@@ -66,8 +66,8 @@ description: "Learn how to configure Keycloak OIDC for Infisical SSO."
|
||||
|
||||
</Step>
|
||||
<Step title="Finish configuring OIDC in Infisical">
|
||||
3.1. Back in Infisical, in the Organization settings > Security > OIDC, click Connect.
|
||||

|
||||
3.1. Back in Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Click **Connect** for **OIDC**.
|
||||

|
||||
|
||||
3.2. For configuration type, select Discovery URL. Then, set the appropriate values for **Discovery Document URL**, **JWT Signature Algorithm**, **Client ID**, and **Client Secret**.
|
||||

|
||||
|
||||
@@ -12,9 +12,9 @@ description: "Learn how to configure Keycloak SAML for Infisical SSO."
|
||||
|
||||
<Steps>
|
||||
<Step title="Prepare the SAML SSO configuration in Infisical">
|
||||
In Infisical, head to Organization Settings > Security and click **Connect** for SAML under the Connect to an Identity Provider section. Select Keycloak, then click **Connect** again.
|
||||
In Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Click **Connect** for **SAML** under the Connect to an Identity Provider section. Select **Keycloak**, then click **Connect** again.
|
||||
|
||||

|
||||

|
||||
|
||||
Next, copy the **Valid redirect URI** and **SP Entity ID** to use when configuring the Keycloak SAML application.
|
||||
|
||||
|
||||
@@ -12,8 +12,10 @@ description: "Learn how to configure Okta SAML 2.0 for Infisical SSO."
|
||||
|
||||
<Steps>
|
||||
<Step title="Prepare the SAML SSO configuration in Infisical">
|
||||
In Infisical, head to Organization Settings > Security and click **Connect** for SAML under the Connect to an Identity Provider section. Select Okta, then click **Connect** again.
|
||||
|
||||
In Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Click **Connect** for **SAML** under the Connect to an Identity Provider section. Select **Okta**, then click **Connect** again.
|
||||
|
||||

|
||||
|
||||
Next, copy the **Single sign-on URL** and **Audience URI (SP Entity ID)** to use when configuring the Okta SAML 2.0 application.
|
||||

|
||||
</Step>
|
||||
|
||||
|
After Width: | Height: | Size: 1.1 MiB |
|
After Width: | Height: | Size: 952 KiB |
|
After Width: | Height: | Size: 738 KiB |
|
After Width: | Height: | Size: 765 KiB |
|
After Width: | Height: | Size: 2.6 MiB |
|
After Width: | Height: | Size: 2.0 MiB |
|
After Width: | Height: | Size: 1.4 MiB |
|
After Width: | Height: | Size: 299 KiB |
|
After Width: | Height: | Size: 1.4 MiB |
|
After Width: | Height: | Size: 715 KiB |
|
After Width: | Height: | Size: 2.0 MiB |
|
After Width: | Height: | Size: 1.7 MiB |
|
After Width: | Height: | Size: 1.9 MiB |
|
After Width: | Height: | Size: 1.9 MiB |
|
After Width: | Height: | Size: 1.9 MiB |
|
After Width: | Height: | Size: 1.2 MiB |
|
Before Width: | Height: | Size: 450 KiB After Width: | Height: | Size: 1.3 MiB |
|
Before Width: | Height: | Size: 485 KiB After Width: | Height: | Size: 766 KiB |
|
Before Width: | Height: | Size: 452 KiB After Width: | Height: | Size: 1.3 MiB |
|
After Width: | Height: | Size: 1.2 MiB |
|
After Width: | Height: | Size: 550 KiB |
|
After Width: | Height: | Size: 1.0 MiB |
|
After Width: | Height: | Size: 904 KiB |
|
After Width: | Height: | Size: 1.1 MiB |
|
After Width: | Height: | Size: 1.1 MiB |
|
Before Width: | Height: | Size: 43 KiB After Width: | Height: | Size: 133 KiB |
|
Before Width: | Height: | Size: 618 KiB After Width: | Height: | Size: 1.3 MiB |
|
Before Width: | Height: | Size: 1.0 MiB After Width: | Height: | Size: 1.3 MiB |
|
After Width: | Height: | Size: 682 KiB |
|
After Width: | Height: | Size: 654 KiB |
|
After Width: | Height: | Size: 643 KiB |
|
After Width: | Height: | Size: 670 KiB |
|
After Width: | Height: | Size: 2.1 MiB |
|
After Width: | Height: | Size: 739 KiB |
|
After Width: | Height: | Size: 683 KiB |
|
After Width: | Height: | Size: 653 KiB |
|
After Width: | Height: | Size: 639 KiB |
|
After Width: | Height: | Size: 1.1 MiB |
|
Before Width: | Height: | Size: 780 KiB |
|
After Width: | Height: | Size: 1.2 MiB |
|
After Width: | Height: | Size: 1.2 MiB |
|
After Width: | Height: | Size: 1.2 MiB |
|
Before Width: | Height: | Size: 780 KiB |
|
Before Width: | Height: | Size: 1.3 MiB After Width: | Height: | Size: 1.2 MiB |
|
Before Width: | Height: | Size: 780 KiB |
@@ -0,0 +1,189 @@
|
||||
---
|
||||
title: "OCI Connection"
|
||||
description: "Learn how to configure an Oracle Cloud Infrastructure Connection for Infisical."
|
||||
---
|
||||
|
||||
Infisical supports the use of [API Signing Key Authentication](https://docs.oracle.com/en-us/iaas/Content/API/Concepts/apisigningkey.htm) to connect with OCI.
|
||||
|
||||
## Create OCI User
|
||||
|
||||
<Steps>
|
||||
<Step title="Search for 'Domains' and click as shown">
|
||||

|
||||
</Step>
|
||||
<Step title="Select domain">
|
||||
Select the domain in which you want to create the Infisical user account.
|
||||
|
||||

|
||||
</Step>
|
||||
<Step title="Navigate to 'Users'">
|
||||

|
||||
</Step>
|
||||
<Step title="Click 'Create user'">
|
||||

|
||||
</Step>
|
||||
<Step title="Create user">
|
||||
The name, email, and username can be anything.
|
||||
|
||||

|
||||
</Step>
|
||||
<Step title="Navigate to 'API keys'">
|
||||
After you've created a user, you'll be redirected to the user's page. Navigate to 'API keys'.
|
||||
|
||||

|
||||
</Step>
|
||||
<Step title="Add API key">
|
||||
Click on 'Add API key' and then download or import the private key. After you've obtained the private key, click 'Add'.
|
||||
|
||||

|
||||
</Step>
|
||||
<Step title="Store configuration">
|
||||
After creating the API key, you'll be shown a modal with relevant information. Save the highlighted values (and the private key) for later steps.
|
||||
|
||||

|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Create OCI Group
|
||||
|
||||
<Steps>
|
||||
<Step title="Search for 'Domains' and click as shown">
|
||||

|
||||
</Step>
|
||||
<Step title="Select domain">
|
||||
Select the domain in which you want to create the Infisical user account.
|
||||
|
||||

|
||||
</Step>
|
||||
<Step title="Navigate to 'Groups'">
|
||||

|
||||
</Step>
|
||||
<Step title="Create group">
|
||||
The name and description can be anything. **Ensure that you assign the user created in earlier steps to this group**.
|
||||
|
||||

|
||||
</Step>
|
||||
<Step title="Store group name">
|
||||
After creating the group, take note of its name. It will be used in later steps.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Create OCI Policy
|
||||
|
||||
<Steps>
|
||||
<Step title="Search for 'Policies' and click as shown">
|
||||

|
||||
</Step>
|
||||
<Step title="Click 'Create Policy'">
|
||||

|
||||
</Step>
|
||||
<Step title="Create policy">
|
||||
The name and description can be anything. Click 'Show manual editor' and paste in the policy rules relevant to your task:
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Secret Sync">
|
||||
```
|
||||
Allow group <group name> to manage secret-family in compartment <compartment name>
|
||||
Allow group <group name> to use keys in compartment <compartment name>
|
||||
Allow group <group name> to use vaults in compartment <compartment name>
|
||||
Allow group <group name> to inspect compartments in tenancy
|
||||
```
|
||||
|
||||
- **Group Name:** The name of the group you created in earlier steps.
|
||||
- **Compartment Name:** The name of the compartment which has your secrets vault.
|
||||
|
||||
If you'd like to grant Infisical access to all compartments, replace instances of `compartment <compartment name>` with `tenancy`.
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||

|
||||
|
||||
<Note>
|
||||
**You must create this policy on the root compartment**, otherwise some functionality may not work.
|
||||
</Note>
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Create OCI Connection in Infisical
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Infisical UI">
|
||||
<Steps>
|
||||
<Step title="Navigate to App Connections">
|
||||
In your Infisical dashboard, go to **Organization Settings** and select the [**App Connections**](https://app.infisical.com/organization/app-connections) tab.
|
||||
|
||||

|
||||
</Step>
|
||||
<Step title="Select OCI Connection">
|
||||
Click the **+ Add Connection** button and select the **OCI Connection** option from the available integrations.
|
||||
|
||||

|
||||
</Step>
|
||||
<Step title="Fill out the OCI Connection Modal">
|
||||
Complete the OCI Connection form by entering:
|
||||
- A descriptive name for the connection
|
||||
- An optional description for future reference
|
||||
- The User OCID from [earlier steps](https://infisical.com/docs/integrations/app-connections/oci#create-oci-user)
|
||||
- The Tenancy OCID from [earlier steps](https://infisical.com/docs/integrations/app-connections/oci#create-oci-user)
|
||||
- The Region from [earlier steps](https://infisical.com/docs/integrations/app-connections/oci#create-oci-user)
|
||||
- The Fingerprint from [earlier steps](https://infisical.com/docs/integrations/app-connections/oci#create-oci-user)
|
||||
- The Private Key PEM from [earlier steps](https://infisical.com/docs/integrations/app-connections/oci#create-oci-user)
|
||||
|
||||

|
||||
</Step>
|
||||
<Step title="Connection Created">
|
||||
After clicking Create, your **OCI Connection** is established and ready to use with your Infisical projects.
|
||||
|
||||

|
||||
</Step>
|
||||
</Steps>
|
||||
</Tab>
|
||||
<Tab title="API">
|
||||
To create an OCI Connection, make an API request to the [Create OCI Connection](/api-reference/endpoints/app-connections/oci/create) API endpoint.
|
||||
|
||||
### Sample request
|
||||
|
||||
```bash Request
|
||||
curl --request POST \
|
||||
--url https://app.infisical.com/api/v1/app-connections/oci \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data '{
|
||||
"name": "my-oci-connection",
|
||||
"method": "access-key",
|
||||
"credentials": {
|
||||
"userOcid": "ocid1.user.oc1..aaaaaaaagrp35tbkvvad4y2j7sug7xonua7dl2gfp4at2u5i5xj4ghnitg3a",
|
||||
"tenancyOcid": "ocid1.tenancy.oc1..aaaaaaaaotfma465m4zumfe2ua64mj2m5dwmlw2llh4g4dnfttnakiifonta",
|
||||
"region": "us-ashburn-1",
|
||||
"fingerprint": "9c:f6:18:23:92:73:f8:e1:85:2c:6a:e3:2c:7d:ec:8f",
|
||||
"privateKey": "[PRIVATE KEY PEM]"
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
### Sample response
|
||||
|
||||
```bash Response
|
||||
{
|
||||
"appConnection": {
|
||||
"id": "e5d18aca-86f7-4026-a95e-efb8aeb0d8e6",
|
||||
"name": "my-oci-connection",
|
||||
"description": null,
|
||||
"version": 1,
|
||||
"orgId": "6f03caa1-a5de-43ce-b127-95a145d3464c",
|
||||
"createdAt": "2025-04-23T19:46:34.831Z",
|
||||
"updatedAt": "2025-04-23T19:46:34.831Z",
|
||||
"isPlatformManagedCredentials": false,
|
||||
"credentialsHash": "7c2d371dec195f82a6a0d5b41c970a229cfcaf88e894a5b6395e2dbd0280661f",
|
||||
"app": "oci",
|
||||
"method": "access-key",
|
||||
"credentials": {
|
||||
"userOcid": "ocid1.user.oc1..aaaaaaaagrp35tbkvvad4y2j7sug7xonua7dl2gfp4at2u5i5xj4ghnitg3a",
|
||||
"tenancyOcid": "ocid1.tenancy.oc1..aaaaaaaaotfma465m4zumfe2ua64mj2m5dwmlw2llh4g4dnfttnakiifonta",
|
||||
"region": "us-ashburn-1",
|
||||
"fingerprint": "9c:f6:18:23:92:73:f8:e1:85:2c:6a:e3:2c:7d:ec:8f"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: "Pulumi"
|
||||
description: "Using Infisical with Pulumi via the Terraform Bridge"
|
||||
---
|
||||
|
||||
Infisical can be integrated with Pulumi by leveraging Pulumi’s [Terraform Bridge](https://www.pulumi.com/blog/any-terraform-provider/),
|
||||
which allows Terraform providers to be used seamlessly within Pulumi projects. This enables infrastructure and platform teams to manage Infisical secrets and resources
|
||||
using Pulumi’s familiar programming languages (including TypeScript, Python, Go, and C#), without any change to existing workflows.
|
||||
|
||||
The Terraform Bridge wraps the [Infisical Terraform provider](/integrations/frameworks/terraform) and exposes its resources (such as `infisical_secret`, `infisical_project`, and `infisical_service_token`)
|
||||
in a Pulumi-compatible interface. This makes it easy to integrate secret management directly into Pulumi-based IaC pipelines, ensuring secrets stay in sync with
|
||||
the rest of your cloud infrastructure. Authentication is handled through the same methods as Terraform: using environment variables such as `INFISICAL_TOKEN` and `INFISICAL_SITE_URL`.
|
||||
|
||||
By bridging the Infisical provider, teams using Pulumi can adopt secure, centralized secrets management without compromising on their toolchain or language preferences.
|
||||
@@ -0,0 +1,177 @@
|
||||
---
|
||||
title: "OCI Vault Sync"
|
||||
description: "Learn how to configure an Oracle Cloud Infrastructure Vault Sync for Infisical."
|
||||
---
|
||||
|
||||
**Prerequisites:**
|
||||
- Create an [OCI Connection](/integrations/app-connections/oci) with the required **Secret Sync** permissions
|
||||
- [Create](https://docs.oracle.com/en-us/iaas/Content/Identity/compartments/To_create_a_compartment.htm) or use an existing OCI Compartment (which the OCI Connection is authorized to access)
|
||||
- [Create](https://docs.oracle.com/en-us/iaas/Content/KeyManagement/Tasks/managingvaults_topic-To_create_a_new_vault.htm#createnewvault) or use an existing OCI Vault
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Infisical UI">
|
||||
<Steps>
|
||||
<Step title="Add Sync">
|
||||
Navigate to **Project** > **Integrations** and select the **Secret Syncs** tab. Click on the **Add Sync** button.
|
||||
|
||||

|
||||
</Step>
|
||||
<Step title="Select 'OCI Vault'">
|
||||

|
||||
</Step>
|
||||
<Step title="Configure source">
|
||||
Configure the **Source** from where secrets should be retrieved, then click **Next**.
|
||||
|
||||

|
||||
|
||||
- **Environment**: The project environment to retrieve secrets from.
|
||||
- **Secret Path**: The folder path to retrieve secrets from.
|
||||
|
||||
<Tip>
|
||||
If you need to sync secrets from multiple folder locations, check out [secret imports](/documentation/platform/secret-reference#secret-imports).
|
||||
</Tip>
|
||||
</Step>
|
||||
<Step title="Configure destination">
|
||||
Configure the **Destination** to where secrets should be deployed, then click **Next**.
|
||||
|
||||

|
||||
|
||||
- **OCI Connection**: The OCI Connection to authenticate with.
|
||||
- **Compartment**: The compartment where the vault is located.
|
||||
- **Vault**: The vault to sync secrets to.
|
||||
- **Encryption Key**: The encryption key to use when creating secrets in the vault.
|
||||
</Step>
|
||||
<Step title="Configure sync options">
|
||||
Configure the **Sync Options** to specify how secrets should be synced, then click **Next**.
|
||||
|
||||

|
||||
|
||||
- **Initial Sync Behavior**: Determines how Infisical should resolve the initial sync.
|
||||
- **Overwrite Destination Secrets**: Removes any secrets at the destination endpoint not present in Infisical.
|
||||
- **Import Secrets (Prioritize Infisical)**: Imports secrets from the destination endpoint before syncing, prioritizing values from Infisical over OCI Vault when keys conflict.
|
||||
- **Import Secrets (Prioritize OCI Vault)**: Imports secrets from the destination endpoint before syncing, prioritizing values from OCI Vault over Infisical when keys conflict.
|
||||
|
||||
- **Auto-Sync Enabled**: If enabled, secrets will automatically be synced from the source location when changes occur. Disable to enforce manual syncing only.
|
||||
- **Disable Secret Deletion**: If enabled, Infisical will not remove secrets from the sync destination. Enable this option if you intend to manage some secrets manually outside of Infisical.
|
||||
</Step>
|
||||
<Step title="Configure details">
|
||||
Configure the **Details** of your OCI Vault Sync, then click **Next**.
|
||||
|
||||

|
||||
|
||||
- **Name**: The name of your sync. Must be slug-friendly.
|
||||
- **Description**: An optional description for your sync.
|
||||
</Step>
|
||||
<Step title="Review configuration">
|
||||
Review your OCI Vault Sync configuration, then click **Create Sync**.
|
||||
|
||||

|
||||
</Step>
|
||||
<Step title="Sync created">
|
||||
If enabled, your OCI Vault Sync will begin syncing your secrets to the destination endpoint.
|
||||
|
||||

|
||||
</Step>
|
||||
</Steps>
|
||||
</Tab>
|
||||
<Tab title="API">
|
||||
To create an **OCI Vault Sync**, make an API request to the [Create OCI Vault Sync](/api-reference/endpoints/secret-syncs/oci-vault/create) API endpoint.
|
||||
|
||||
### Sample request
|
||||
|
||||
```bash Request
|
||||
curl --request POST \
|
||||
--url https://app.infisical.com/api/v1/secret-syncs/oci-vault \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data '{
|
||||
"name": "my-oci-vault-sync",
|
||||
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"description": "an example sync",
|
||||
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"environment": "dev",
|
||||
"secretPath": "/my-secrets",
|
||||
"isEnabled": true,
|
||||
"syncOptions": {
|
||||
"initialSyncBehavior": "overwrite-destination"
|
||||
},
|
||||
"destinationConfig": {
|
||||
"compartmentOcid": "...",
|
||||
"vaultOcid": "...",
|
||||
"keyOcid": "..."
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
### Sample response
|
||||
|
||||
```bash Response
|
||||
{
|
||||
"secretSync": {
|
||||
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"name": "my-oci-vault-sync",
|
||||
"description": "an example sync",
|
||||
"isEnabled": true,
|
||||
"version": 1,
|
||||
"folderId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"createdAt": "2023-11-07T05:31:56Z",
|
||||
"updatedAt": "2023-11-07T05:31:56Z",
|
||||
"syncStatus": "succeeded",
|
||||
"lastSyncJobId": "123",
|
||||
"lastSyncMessage": null,
|
||||
"lastSyncedAt": "2023-11-07T05:31:56Z",
|
||||
"importStatus": null,
|
||||
"lastImportJobId": null,
|
||||
"lastImportMessage": null,
|
||||
"lastImportedAt": null,
|
||||
"removeStatus": null,
|
||||
"lastRemoveJobId": null,
|
||||
"lastRemoveMessage": null,
|
||||
"lastRemovedAt": null,
|
||||
"syncOptions": {
|
||||
"initialSyncBehavior": "overwrite-destination"
|
||||
},
|
||||
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"connection": {
|
||||
"app": "oci",
|
||||
"name": "my-oci-connection",
|
||||
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a"
|
||||
},
|
||||
"environment": {
|
||||
"slug": "dev",
|
||||
"name": "Development",
|
||||
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a"
|
||||
},
|
||||
"folder": {
|
||||
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"path": "/my-secrets"
|
||||
},
|
||||
"destination": "oci-vault",
|
||||
"destinationConfig": {
|
||||
"compartmentOcid": "...",
|
||||
"vaultOcid": "...",
|
||||
"keyOcid": "..."
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## FAQ
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="How are non-active lifecycle states treated?">
|
||||
When Infisical attempts to sync secrets, the sync will fail and attempt to re-sync if **any secret** has one of the following lifecycle states:
|
||||
- SchedulingDeletion
|
||||
- CancellingDeletion
|
||||
- Deleting
|
||||
- Creating
|
||||
- Updating
|
||||
|
||||
We do this to prevent any desync issues.
|
||||
</Accordion>
|
||||
<Accordion title="What happens if I create / update a variable that's scheduled for deletion in OCI Vault?">
|
||||
In the case that a variable is created or updated while it's scheduled for deletion in OCI Vault, we cancel the deletion and update the variable. This action may take up to a minute since Infisical must wait for OCI to completely cancel the deletion and then update the variable.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
@@ -112,6 +112,7 @@
|
||||
"pages": [
|
||||
"documentation/platform/pki/overview",
|
||||
"documentation/platform/pki/private-ca",
|
||||
"documentation/platform/pki/subscribers",
|
||||
"documentation/platform/pki/certificates",
|
||||
"documentation/platform/pki/pki-issuer",
|
||||
"documentation/platform/pki/est",
|
||||
@@ -349,7 +350,8 @@
|
||||
"group": "Linux Package",
|
||||
"pages": [
|
||||
"self-hosting/deployment-options/native/linux-package/installation",
|
||||
"self-hosting/deployment-options/native/linux-package/commands-configuration"
|
||||
"self-hosting/deployment-options/native/linux-package/commands-configuration",
|
||||
"self-hosting/deployment-options/linux-upgrade"
|
||||
]
|
||||
},
|
||||
"self-hosting/guides/upgrading-infisical",
|
||||
@@ -444,6 +446,7 @@
|
||||
]
|
||||
},
|
||||
"integrations/frameworks/terraform",
|
||||
"integrations/frameworks/pulumi",
|
||||
"integrations/platforms/ansible",
|
||||
"integrations/platforms/apache-airflow"
|
||||
]
|
||||
@@ -468,6 +471,7 @@
|
||||
"integrations/app-connections/humanitec",
|
||||
"integrations/app-connections/ldap",
|
||||
"integrations/app-connections/mssql",
|
||||
"integrations/app-connections/oci",
|
||||
"integrations/app-connections/postgres",
|
||||
"integrations/app-connections/teamcity",
|
||||
"integrations/app-connections/terraform-cloud",
|
||||
@@ -494,6 +498,7 @@
|
||||
"integrations/secret-syncs/github",
|
||||
"integrations/secret-syncs/hashicorp-vault",
|
||||
"integrations/secret-syncs/humanitec",
|
||||
"integrations/secret-syncs/oci-vault",
|
||||
"integrations/secret-syncs/teamcity",
|
||||
"integrations/secret-syncs/terraform-cloud",
|
||||
"integrations/secret-syncs/vercel",
|
||||
@@ -1180,6 +1185,18 @@
|
||||
"api-reference/endpoints/app-connections/mssql/delete"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "OCI",
|
||||
"pages": [
|
||||
"api-reference/endpoints/app-connections/oci/list",
|
||||
"api-reference/endpoints/app-connections/oci/available",
|
||||
"api-reference/endpoints/app-connections/oci/get-by-id",
|
||||
"api-reference/endpoints/app-connections/oci/get-by-name",
|
||||
"api-reference/endpoints/app-connections/oci/create",
|
||||
"api-reference/endpoints/app-connections/oci/update",
|
||||
"api-reference/endpoints/app-connections/oci/delete"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "PostgreSQL",
|
||||
"pages": [
|
||||
@@ -1383,6 +1400,20 @@
|
||||
"api-reference/endpoints/secret-syncs/humanitec/remove-secrets"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "OCI",
|
||||
"pages": [
|
||||
"api-reference/endpoints/secret-syncs/oci-vault/list",
|
||||
"api-reference/endpoints/secret-syncs/oci-vault/get-by-id",
|
||||
"api-reference/endpoints/secret-syncs/oci-vault/get-by-name",
|
||||
"api-reference/endpoints/secret-syncs/oci-vault/create",
|
||||
"api-reference/endpoints/secret-syncs/oci-vault/update",
|
||||
"api-reference/endpoints/secret-syncs/oci-vault/delete",
|
||||
"api-reference/endpoints/secret-syncs/oci-vault/sync-secrets",
|
||||
"api-reference/endpoints/secret-syncs/oci-vault/import-secrets",
|
||||
"api-reference/endpoints/secret-syncs/oci-vault/remove-secrets"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "TeamCity",
|
||||
"pages": [
|
||||
@@ -1467,6 +1498,18 @@
|
||||
{
|
||||
"group": "Infisical PKI",
|
||||
"pages": [
|
||||
{
|
||||
"group": "Subscribers",
|
||||
"pages": [
|
||||
"api-reference/endpoints/pki/subscribers/list-certs",
|
||||
"api-reference/endpoints/pki/subscribers/create",
|
||||
"api-reference/endpoints/pki/subscribers/read",
|
||||
"api-reference/endpoints/pki/subscribers/update",
|
||||
"api-reference/endpoints/pki/subscribers/delete",
|
||||
"api-reference/endpoints/pki/subscribers/issue-cert",
|
||||
"api-reference/endpoints/pki/subscribers/sign-cert"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Certificate Authorities",
|
||||
"pages": [
|
||||
|
||||
@@ -0,0 +1,390 @@
|
||||
---
|
||||
title: "Upgrading"
|
||||
description: "How to upgrade Infisical deployment using linux package"
|
||||
---
|
||||
|
||||
This guide explains how to upgrade Infisical Linux package installations to newer versions.
|
||||
The Infisical Linux package includes only the Infisical service component itself, as PostgreSQL and Redis databases are managed separately.
|
||||
Upgrades for PostgreSQL and Redis are not covered in this guide as they depend on your specific database deployment method.
|
||||
|
||||
## Upgrade Options
|
||||
|
||||
There are two primary methods to upgrade Infisical:
|
||||
|
||||
1. **Standard Upgrade (with brief downtime)**: The simplest approach that briefly takes Infisical offline during the upgrade.
|
||||
2. **Minimal-Downtime Upgrade**: For multi-node deployments where high availability is required.
|
||||
|
||||
## Before You Begin
|
||||
|
||||
### Checking Your Current Version
|
||||
|
||||
Before upgrading, note your current Infisical version:
|
||||
|
||||
```bash
|
||||
cat /opt/infisical-core/version-manifest.txt
|
||||
```
|
||||
|
||||
Look for `infisical` component. This will be the version of Infisical currently installed.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- Verify that your PostgreSQL and Redis instances are up and running
|
||||
- Back up your PostgreSQL database before proceeding with any upgrade
|
||||
- Review release notes for the version you're upgrading to
|
||||
|
||||
### Creating a Database Backup
|
||||
|
||||
We strongly recommend backing up your database before upgrading.
|
||||
Your backup approach may look different depending on how you configured PostgreSQL and whether it's self-managed or using a managed service.
|
||||
Here is a sample of how you would perform a manual backup:
|
||||
|
||||
```bash
|
||||
# Example PostgreSQL backup command (adjust parameters as needed)
|
||||
pg_dump -U <username> -h <db-host> -d <db-name> > infisical_backup.sql
|
||||
```
|
||||
|
||||
### Database Migrations During Upgrade
|
||||
|
||||
By default, Infisical runs database migrations automatically on startup.
|
||||
|
||||
- It uses database locks to ensure only one instance runs migrations at a time
|
||||
- Other instances will wait for the lock to be released before continuing startup
|
||||
- This prevents race conditions and database conflicts
|
||||
|
||||
## Standard Upgrade (with Downtime)
|
||||
|
||||
This method is suitable for single-node deployments or situations where a brief downtime is acceptable.
|
||||
|
||||
<Steps>
|
||||
<Step title="Stop the Infisical service">
|
||||
```bash
|
||||
infisical-ctl stop
|
||||
```
|
||||
</Step>
|
||||
<Step title="Upgrade the Infisical package">
|
||||
To upgrade to the latest version:
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Debian/Ubuntu">
|
||||
```bash
|
||||
sudo apt-get update && sudo apt-get install -y infisical-core
|
||||
```
|
||||
</Tab>
|
||||
<Tab title="RHEL/CentOS/Amazon Linux">
|
||||
```bash
|
||||
sudo yum update infisical-core
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
To upgrade to a specific version:
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Debian/Ubuntu">
|
||||
```bash
|
||||
sudo apt-get install -y infisical-core=<version>
|
||||
```
|
||||
</Tab>
|
||||
<Tab title="RHEL/CentOS/Amazon Linux">
|
||||
```bash
|
||||
sudo yum install infisical-core-<version>
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
</Step>
|
||||
<Step title="Apply configuration changes">
|
||||
```bash
|
||||
infisical-ctl reconfigure
|
||||
```
|
||||
</Step>
|
||||
|
||||
<Step title="Start Infisical">
|
||||
```bash
|
||||
infisical-ctl start
|
||||
```
|
||||
</Step>
|
||||
|
||||
<Step title="Verify the upgrade">
|
||||
```bash
|
||||
infisical-ctl status
|
||||
```
|
||||
|
||||
Check the logs for any issues:
|
||||
```bash
|
||||
infisical-ctl tail
|
||||
```
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Minimal-Downtime Upgrade
|
||||
|
||||
For multi-node setups where you need to maintain availability during upgrades, follow this procedure. This approach requires at least two Infisical nodes behind a load balancer.
|
||||
|
||||
### Understanding Traffic Draining
|
||||
|
||||
"Draining" a server means gracefully removing it from the pool of active servers without disrupting existing connections. When you drain a server:
|
||||
|
||||
1. The load balancer stops sending new requests to the server
|
||||
2. Existing connections are allowed to complete naturally
|
||||
3. Once all connections finish, the server can be safely taken offline for maintenance
|
||||
|
||||
This approach ensures users/machines do not experience sudden connection errors during the upgrade process.
|
||||
|
||||
### Preparing for the Upgrade
|
||||
|
||||
1. **Designate a deploy node**: Choose any single node that will run migrations. This node will be upgraded first.
|
||||
|
||||
2. **Configure your load balancer**: Ensure your load balancer can perform health checks against Infisical's `api/status` endpoint.
|
||||
|
||||
### Upgrade Process
|
||||
|
||||
#### On the deploy node:
|
||||
|
||||
<Steps>
|
||||
<Step title="Drain traffic from the node">
|
||||
|
||||
Drain the traffic on this node gracefully. You can do this in a number of ways depending on the load balancer you have configured.
|
||||
Approaches for some common load balancers are provided below:
|
||||
|
||||
<Tabs>
|
||||
<Tab title="NGINX">
|
||||
If using NGINX as a load balancer, you can remove the server from the upstream pool temporarily:
|
||||
```bash
|
||||
# Edit your NGINX configuration to comment out or remove the server
|
||||
sudo nano /path/to/your/nginx-config.conf
|
||||
|
||||
# Reload NGINX to apply changes
|
||||
sudo nginx -s reload
|
||||
```
|
||||
</Tab>
|
||||
<Tab title="HAProxy">
|
||||
If using HAProxy, you can put the server in maintenance mode:
|
||||
```bash
|
||||
# Using the HAProxy socket command
|
||||
echo "disable server infisical_backend/infisical-node1" | socat stdio /var/lib/haproxy/stats
|
||||
```
|
||||
</Tab>
|
||||
<Tab title="AWS ALB/ELB">
|
||||
Deregister the instance from the load balancer using the AWS console or CLI
|
||||
</Tab>
|
||||
<Tab title="Other load balancers">
|
||||
Follow your load balancer's documentation for instructions on draining procedure
|
||||
</Tab>
|
||||
</Tabs>
|
||||
</Step>
|
||||
|
||||
<Step title="Verify no new traffic is arriving">
|
||||
Verify no new traffic is arriving before proceeding with the upgrade.
|
||||
</Step>
|
||||
|
||||
<Step title="Stop Infisical on this node">
|
||||
```bash
|
||||
infisical-ctl stop
|
||||
```
|
||||
</Step>
|
||||
|
||||
<Step title="Upgrade the Infisical package">
|
||||
|
||||
To upgrade to the latest version:
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Debian/Ubuntu">
|
||||
```bash
|
||||
sudo apt-get update && sudo apt-get install -y infisical-core
|
||||
```
|
||||
</Tab>
|
||||
<Tab title="RHEL/CentOS/Amazon Linux">
|
||||
```bash
|
||||
sudo yum update infisical-core
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
To upgrade to a specific version:
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Debian/Ubuntu">
|
||||
```bash
|
||||
sudo apt-get install -y infisical-core=<version>
|
||||
```
|
||||
</Tab>
|
||||
<Tab title="RHEL/CentOS/Amazon Linux">
|
||||
```bash
|
||||
sudo yum install infisical-core-<version>
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
</Step>
|
||||
|
||||
<Step title="Apply configuration and start the service">
|
||||
```bash
|
||||
infisical-ctl reconfigure
|
||||
```
|
||||
</Step>
|
||||
|
||||
<Step title="Verify the upgrade and migration success">
|
||||
```bash
|
||||
infisical-ctl tail
|
||||
```
|
||||
Look for successful migration messages in the logs.
|
||||
</Step>
|
||||
|
||||
<Step title="Return this node to load balancer pool">
|
||||
Re-enable the server in your load balancer using the same method you used to remove it.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
#### On all remaining nodes (one at a time):
|
||||
|
||||
<Steps>
|
||||
<Step title="Drain traffic from the node">
|
||||
Follow the same draining procedure as described for the deploy node:
|
||||
|
||||
- Remove the server from your load balancer's active pool
|
||||
- Wait for existing connections to complete
|
||||
- Verify the node is no longer receiving traffic
|
||||
</Step>
|
||||
|
||||
<Step title="Stop Infisical on this node">
|
||||
```bash
|
||||
infisical-ctl stop
|
||||
```
|
||||
</Step>
|
||||
|
||||
<Step title="Upgrade the Infisical package">
|
||||
To upgrade to the latest version:
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Debian/Ubuntu">
|
||||
```bash
|
||||
sudo apt-get update && sudo apt-get install -y infisical-core
|
||||
```
|
||||
</Tab>
|
||||
<Tab title="RHEL/CentOS/Amazon Linux">
|
||||
```bash
|
||||
sudo yum update infisical-core
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
To upgrade to a specific version:
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Debian/Ubuntu">
|
||||
```bash
|
||||
sudo apt-get install -y infisical-core=<version>
|
||||
```
|
||||
</Tab>
|
||||
<Tab title="RHEL/CentOS/Amazon Linux">
|
||||
```bash
|
||||
sudo yum install infisical-core-<version>
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
</Step>
|
||||
|
||||
<Step title="Apply configuration and start the service">
|
||||
```bash
|
||||
infisical-ctl reconfigure
|
||||
```
|
||||
</Step>
|
||||
|
||||
<Step title="Verify the upgrade success">
|
||||
```bash
|
||||
infisical-ctl status
|
||||
infisical-ctl tail
|
||||
```
|
||||
</Step>
|
||||
|
||||
<Step title="Wait for service to be fully operational">
|
||||
- Check logs to ensure the service has started successfully
|
||||
- Verify it can connect to the database and Redis
|
||||
</Step>
|
||||
|
||||
<Step title="Return the node to service">
|
||||
Re-enable the server in your load balancer using the same method you used to remove it.
|
||||
</Step>
|
||||
|
||||
<Step title="Verify traffic is flowing correctly">
|
||||
Check logs and monitoring to ensure traffic is flowing correctly.
|
||||
</Step>
|
||||
|
||||
<Step title="Repeat for each remaining node">
|
||||
Repeat steps 1-7 for each remaining node, one at a time.
|
||||
</Step>
|
||||
|
||||
<Step title="Verify application functionality">
|
||||
After all nodes are upgraded, verify that the application is functioning correctly:
|
||||
- Test core functionality
|
||||
- Check logs for any errors
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Rolling Back
|
||||
|
||||
If you need to roll back to a previous version of Infisical, follow steps below.
|
||||
|
||||
<Steps>
|
||||
<Step title="Stop the Infisical service">
|
||||
```bash
|
||||
infisical-ctl stop
|
||||
```
|
||||
</Step>
|
||||
|
||||
<Step title="Install the previous version">
|
||||
For Debian/Ubuntu:
|
||||
```bash
|
||||
sudo apt-get install -y infisical-core=<previous-version>
|
||||
```
|
||||
|
||||
For RHEL/CentOS/Amazon Linux:
|
||||
```bash
|
||||
sudo yum downgrade infisical-core-<previous-version>
|
||||
```
|
||||
</Step>
|
||||
|
||||
<Step title="Restore your database from backup">
|
||||
Restore your Postgres/Redis database from backup.
|
||||
</Step>
|
||||
|
||||
<Step title="Start the service">
|
||||
```bash
|
||||
infisical-ctl reconfigure
|
||||
```
|
||||
</Step>
|
||||
|
||||
<Step title="Verify the rollback">
|
||||
```bash
|
||||
infisical-ctl status
|
||||
```
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Migration Issues">
|
||||
If you encounter database migration issues:
|
||||
|
||||
1. Check the logs:
|
||||
```bash
|
||||
infisical-ctl tail
|
||||
```
|
||||
|
||||
2. Ensure the database user has sufficient privileges to create/modify tables.
|
||||
|
||||
3. If migrations fail repeatedly, consider restoring from the backup you took prior to upgrading.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Service Won't Start After Upgrade">
|
||||
1. Check for configuration errors:
|
||||
```bash
|
||||
infisical-ctl tail
|
||||
infisical-ctl status
|
||||
```
|
||||
|
||||
2. Verify all required environment variables are set in your `/etc/infisical/infisical.rb` file.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
@@ -4,19 +4,19 @@ description: "Learn how to configure Infisical with custom certificates"
|
||||
---
|
||||
|
||||
By default, the Infisical Docker image includes certificates from well-known public certificate authorities.
|
||||
However, some integrations with Infisical may need to communicate with your internal services that use private certificate authorities.
|
||||
However, some integrations with Infisical may need to communicate with your internal services that use private certificate authorities.
|
||||
To configure trust for custom certificates, follow these steps. This is particularly useful for connecting Infisical with self-hosted services like GitLab.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Docker
|
||||
- Standalone [Infisical image](https://hub.docker.com/r/infisical/infisical)
|
||||
- Certificate public key `.pem` files
|
||||
- Certificate public key `.crt` files
|
||||
|
||||
## Setup
|
||||
|
||||
1. Place all your public key `.pem` files into a single directory.
|
||||
2. Mount the directory containing the `.pem` files to the `usr/local/share/ca-certificates/` path in the Infisical container.
|
||||
1. Place all your public key `.crt` files into a single directory.
|
||||
2. Mount the directory containing the `.crt` files to the `/usr/local/share/ca-certificates/` path in the Infisical container.
|
||||
3. Set the following environment variable on your Infisical container:
|
||||
```
|
||||
NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-certificates.crt
|
||||
|
||||