From d25ab57204c3b01b653a20c59b90c82440344359 Mon Sep 17 00:00:00 2001 From: Fang-Pen Lin Date: Mon, 24 Nov 2025 11:17:40 -0800 Subject: [PATCH 01/22] Update docs --- docs/docs.json | 2 +- .../getting-started/concepts/client-integrations.mdx | 2 +- .../platform/pki/integration-guides/gloo-mesh.mdx | 2 +- .../pki/{pki-issuer.mdx => k8s-cert-manager.mdx} | 9 ++++++--- 4 files changed, 9 insertions(+), 6 deletions(-) rename docs/documentation/platform/pki/{pki-issuer.mdx => k8s-cert-manager.mdx} (94%) diff --git a/docs/docs.json b/docs/docs.json index 57f44596f..8da9a2a28 100644 --- a/docs/docs.json +++ b/docs/docs.json @@ -752,7 +752,7 @@ { "group": "Infrastructure Integrations", "pages": [ - "documentation/platform/pki/pki-issuer", + "documentation/platform/pki/k8s-cert-manager", "documentation/platform/pki/integration-guides/gloo-mesh", "documentation/platform/pki/integration-guides/windows-server-acme", "documentation/platform/pki/integration-guides/nginx-certbot", diff --git a/docs/documentation/getting-started/concepts/client-integrations.mdx b/docs/documentation/getting-started/concepts/client-integrations.mdx index bcd935830..2a575039a 100644 --- a/docs/documentation/getting-started/concepts/client-integrations.mdx +++ b/docs/documentation/getting-started/concepts/client-integrations.mdx @@ -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 PKI Issuer](/documentation/platform/pki/k8s-cert-manager): A controller that issues X.509 certificates from Infisical PKI 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. diff --git a/docs/documentation/platform/pki/integration-guides/gloo-mesh.mdx b/docs/documentation/platform/pki/integration-guides/gloo-mesh.mdx index d1f1273fd..0f312af01 100644 --- a/docs/documentation/platform/pki/integration-guides/gloo-mesh.mdx +++ b/docs/documentation/platform/pki/integration-guides/gloo-mesh.mdx @@ -25,7 +25,7 @@ When you deploy a `Certificate` CRD in your workload cluster, `cert-manager` use 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 PKI Issuer and cert-manager for your Istio intermediate CA certificates in Gloo Mesh clusters. For Gloo Mesh-specific configuration, ensure that: diff --git a/docs/documentation/platform/pki/pki-issuer.mdx b/docs/documentation/platform/pki/k8s-cert-manager.mdx similarity index 94% rename from docs/documentation/platform/pki/pki-issuer.mdx rename to docs/documentation/platform/pki/k8s-cert-manager.mdx index a1d07c98b..a5c9f8143 100644 --- a/docs/documentation/platform/pki/pki-issuer.mdx +++ b/docs/documentation/platform/pki/k8s-cert-manager.mdx @@ -1,13 +1,16 @@ --- -title: "Kubernetes Issuer" +title: "Kubernetes cert-manager" 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. +The Infisical PKI provides [ACME (Automated Certificate Management Environment)](https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment) integration for various of ACME clients to issue and renew certificates automatically. +Under Kubernetes environment, [cert-manager](https://cert-manager.io) is the most popular issuer to issue certificates via ACME. +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. +As part of the workflow, you install `cert-manager` 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. From c3fda7d20df7ced629809536d52c0643f2906c04 Mon Sep 17 00:00:00 2001 From: Fang-Pen Lin Date: Mon, 24 Nov 2025 11:28:46 -0800 Subject: [PATCH 02/22] update doc --- .../platform/pki/k8s-cert-manager.mdx | 38 +++++-------------- 1 file changed, 10 insertions(+), 28 deletions(-) diff --git a/docs/documentation/platform/pki/k8s-cert-manager.mdx b/docs/documentation/platform/pki/k8s-cert-manager.mdx index a5c9f8143..02c00dbdd 100644 --- a/docs/documentation/platform/pki/k8s-cert-manager.mdx +++ b/docs/documentation/platform/pki/k8s-cert-manager.mdx @@ -18,28 +18,27 @@ We recommend reading the [cert-manager documentation](https://cert-manager.io/do 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. +1. Creating a certificate profile with ACME as the enrollment method in Infisical. +2. Creating a Kubernetes secret to store the EAB (External Account Binding) credentials of the ACME certificate profile. 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`. +4. Creating an `Issuer` or `ClusterIssuer` resource in your Kubernetes cluster to represent the Infisical PKI issuer you wish to use. +5. Create the approver policy to accept certificate request. +6. 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. +7. 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. - + - Follow the instructions [here](/documentation/platform/identities/universal-auth) to configure a [machine identity](/documentation/platform/identities/machine-identities) in Infisical with Universal Auth. + Follow the instructions [here](/documentation/platform/pki/enrollment-methods/acme) to create a certificate profile with ACME as the enrollment method. - 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. + By the end of this step, you should have a **ACME Directory URL**, **EAB KID** and **EAB Secret** on hand as part of the credentials for the Infisical PKI ACME service to authenticate with Infisical; this will be useful in steps 4 and 5. - Currently, the Infisical PKI Issuer only supports authenticating with Infisical via the [Universal Auth](/documentation/platform/identities/universal-auth) authentication method. + Currently, the Infisical PKI ACME service only supports authenticating with Infisical via the dedicated EAB credentials generated for each certificate profile as the authentication method. We're planning to add support for [Kubernetes Auth](/documentation/platform/identities/kubernetes-auth) in the near future. @@ -51,23 +50,6 @@ In the following steps, we explore how to install the Infisical PKI Issuer using kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.15.3/cert-manager.yaml ``` - - Install the Infisical PKI Issuer controller into your Kubernetes cluster using one of the following methods: - - - - ```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 - ``` - - - ```bash - kubectl apply -f https://raw.githubusercontent.com/Infisical/infisical-issuer/main/build/install.yaml - ``` - - - 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. From 64f7a8321258691b17fbd531721240a962f38aac Mon Sep 17 00:00:00 2001 From: Fang-Pen Lin Date: Mon, 24 Nov 2025 11:38:33 -0800 Subject: [PATCH 03/22] More doc --- .../platform/pki/k8s-cert-manager.mdx | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/documentation/platform/pki/k8s-cert-manager.mdx b/docs/documentation/platform/pki/k8s-cert-manager.mdx index 02c00dbdd..3ef294829 100644 --- a/docs/documentation/platform/pki/k8s-cert-manager.mdx +++ b/docs/documentation/platform/pki/k8s-cert-manager.mdx @@ -21,7 +21,7 @@ A typical workflow for using the Infisical PKI Issuer to issue certificates for 1. Creating a certificate profile with ACME as the enrollment method in Infisical. 2. Creating a Kubernetes secret to store the EAB (External Account Binding) credentials of the ACME certificate profile. 3. Installing `cert-manager` into your Kubernetes cluster. -4. Creating an `Issuer` or `ClusterIssuer` resource in your Kubernetes cluster to represent the Infisical PKI issuer you wish to use. +4. Creating an `Issuer` or `ClusterIssuer` resource in your Kubernetes cluster to connect to the Infisical PKI certificate profile you wish to use. 5. Create the approver policy to accept certificate request. 6. 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. 7. Consuming the issued certificate across your Kubernetes resources from the specified Kubernetes `Secret`. @@ -35,7 +35,7 @@ In the following steps, we explore how to install the Infisical PKI Issuer using Follow the instructions [here](/documentation/platform/pki/enrollment-methods/acme) to create a certificate profile with ACME as the enrollment method. - By the end of this step, you should have a **ACME Directory URL**, **EAB KID** and **EAB Secret** on hand as part of the credentials for the Infisical PKI ACME service to authenticate with Infisical; this will be useful in steps 4 and 5. + By the end of this step, you should have a **ACME Directory URL**, **EAB KID** and **EAB Secret** on hand as part of the credentials for the Infisical PKI ACME server to authenticate with Infisical; this will be useful in steps 4 and 5. Currently, the Infisical PKI ACME service only supports authenticating with Infisical via the dedicated EAB credentials generated for each certificate profile as the authentication method. @@ -50,30 +50,30 @@ In the following steps, we explore how to install the Infisical PKI Issuer using kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.15.3/cert-manager.yaml ``` - + 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. ```bash - kubectl create secret generic issuer-infisical-client-secret \ + kubectl create secret generic infisical-acme-eab-secret \ --namespace \ - --from-literal=clientSecret= + --from-literal=eabSecret= ``` - ```yaml secret-issuer.yaml + ```yaml acme-eab-secret.yaml apiVersion: v1 kind: Secret metadata: - name: issuer-infisical-client-secret + name: infisical-acme-eab-secret namespace: data: - clientSecret: + eabSecret: ``` ```bash - kubectl apply -f secret-issuer.yaml + kubectl apply -f acme-eab-secret.yaml ``` From 5252815b43451802a89ef4bdc82fdf865e3c1456 Mon Sep 17 00:00:00 2001 From: Fang-Pen Lin Date: Mon, 24 Nov 2025 13:45:47 -0800 Subject: [PATCH 04/22] docs --- .../platform/pki/k8s-cert-manager.mdx | 48 ++++++++++++------- 1 file changed, 31 insertions(+), 17 deletions(-) diff --git a/docs/documentation/platform/pki/k8s-cert-manager.mdx b/docs/documentation/platform/pki/k8s-cert-manager.mdx index 3ef294829..1454208d6 100644 --- a/docs/documentation/platform/pki/k8s-cert-manager.mdx +++ b/docs/documentation/platform/pki/k8s-cert-manager.mdx @@ -13,14 +13,15 @@ As part of the workflow, you install `cert-manager` and configure resources to r 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. +For the ACME part, please reference to the [ACME](https://cert-manager.io/docs/configuration/acme/) section. ## 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 certificate profile with ACME as the enrollment method in Infisical. -2. Creating a Kubernetes secret to store the EAB (External Account Binding) credentials of the ACME certificate profile. -3. Installing `cert-manager` into your Kubernetes cluster. +2. Installing `cert-manager` into your Kubernetes cluster. +3. Creating a Kubernetes secret to store the EAB (External Account Binding) credentials of the ACME certificate profile. 4. Creating an `Issuer` or `ClusterIssuer` resource in your Kubernetes cluster to connect to the Infisical PKI certificate profile you wish to use. 5. Create the approver policy to accept certificate request. 6. 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. @@ -38,7 +39,7 @@ In the following steps, we explore how to install the Infisical PKI Issuer using By the end of this step, you should have a **ACME Directory URL**, **EAB KID** and **EAB Secret** on hand as part of the credentials for the Infisical PKI ACME server to authenticate with Infisical; this will be useful in steps 4 and 5. - Currently, the Infisical PKI ACME service only supports authenticating with Infisical via the dedicated EAB credentials generated for each certificate profile as the authentication method. + Currently, the Infisical PKI ACME server only supports authenticating with Infisical via the dedicated EAB credentials generated for each certificate profile as the authentication method. We're planning to add support for [Kubernetes Auth](/documentation/platform/identities/kubernetes-auth) in the near future. @@ -78,26 +79,36 @@ In the following steps, we explore how to install the Infisical PKI Issuer using - - Next, create the Infisical PKI Issuer by filling out `url`, `clientId`, `projectId` or `certificateTemplateName`, and applying the following configuration file for the `Issuer` resource. + + Next, create the cert-manager Issuer or ClusterIssuer by filling out `acme_server_url`, `your_email`, `acme_eab_kid`, 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 + apiVersion: cert-manager.io/v1 kind: Issuer metadata: name: issuer-infisical - namespace: spec: - url: "https://app.infisical.com" # the URL of your Infisical instance - projectId: # the ID of the project you want to use to issue certificates - certificateTemplateName: # the name of the certificate template you want to use to issue certificates against - authentication: - universalAuth: - clientId: # the Client ID from step 1 - secretRef: # reference to the Secret created in step 4 - name: "issuer-infisical-client-secret" - key: "clientSecret" + acme: + # the URL of your Infisical certificate profile with + # ACME enrollment method from step 1 + server: + # your email address, any email could work. + # currently we just ignore the value + email: + externalAccountBinding: + keyID: # the EAB secret value from step 1 + keySecretRef: # reference to the Secret created in step 3 + name: "issuer-infisical-client-secret" + key: "clientSecret" + privateKeySecretRef: + name: issuer-infisical-account-key + solvers: + - http01: + ingress: + # this doesn't need to be nginx, you can use any + # ingressClassName available in your Kubernetes cluster + ingressClassName: nginx ``` ``` @@ -107,7 +118,7 @@ In the following steps, we explore how to install the Infisical PKI Issuer using You can check that the issuer was created successfully by running the following command: ```bash - kubectl get issuers.infisical-issuer.infisical.com -n -o wide + kubectl get issuers.cert-manager.io -n -o wide ``` ```bash @@ -122,6 +133,9 @@ In the following steps, we explore how to install the Infisical PKI Issuer using 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/). + + Also, currently Infisical ACME server only supports HTTP-01 and requires all the certificate orders passing the challenge before issuing certificates. + We will allow users to opt-out challenge in the near future and also provide support DNS-01 as well. From 0d80eb6fae4d7fb10dba63e2ad54b26441a76e48 Mon Sep 17 00:00:00 2001 From: Fang-Pen Lin Date: Mon, 24 Nov 2025 13:54:16 -0800 Subject: [PATCH 05/22] docs --- .../platform/pki/k8s-cert-manager.mdx | 69 ++++--------------- 1 file changed, 15 insertions(+), 54 deletions(-) diff --git a/docs/documentation/platform/pki/k8s-cert-manager.mdx b/docs/documentation/platform/pki/k8s-cert-manager.mdx index 1454208d6..c62dbf97a 100644 --- a/docs/documentation/platform/pki/k8s-cert-manager.mdx +++ b/docs/documentation/platform/pki/k8s-cert-manager.mdx @@ -23,9 +23,8 @@ A typical workflow for using the Infisical PKI Issuer to issue certificates for 2. Installing `cert-manager` into your Kubernetes cluster. 3. Creating a Kubernetes secret to store the EAB (External Account Binding) credentials of the ACME certificate profile. 4. Creating an `Issuer` or `ClusterIssuer` resource in your Kubernetes cluster to connect to the Infisical PKI certificate profile you wish to use. -5. Create the approver policy to accept certificate request. -6. 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. -7. Consuming the issued certificate across your Kubernetes resources from the specified Kubernetes `Secret`. +5. 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. +6. Consuming the issued certificate across your Kubernetes resources from the specified Kubernetes `Secret`. ## Guide @@ -52,7 +51,7 @@ In the following steps, we explore how to install the Infisical PKI Issuer using ``` - 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. + Start by creating a Kubernetes `Secret` containing the **EAB Secret** from step 1. As mentioned previously, this will be used by the Infisical PKI issuer to authenticate with Infisical. @@ -138,50 +137,6 @@ In the following steps, we explore how to install the Infisical PKI Issuer using We will allow users to opt-out challenge in the near future and also provide support DNS-01 as well. - - 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/). - Finally, create a `Certificate` by applying the following configuration file. @@ -194,17 +149,23 @@ In the following steps, we explore how to install the Infisical PKI Issuer using name: certificate-by-issuer namespace: 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 + # the common name for the certificate + commonName: certificate-by-issuer.example.com + # the name of the Kubernetes Secret to create and store + # the certificate and private key in + secretName: certificate-by-issuer issuerRef: name: issuer-infisical - group: infisical-issuer.infisical.com + group: issuers.cert-manager.io kind: Issuer - privateKey: # the algorithm and key size to use + # the algorithm and key size to use + privateKey: 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 ttl for the certificate + duration: 48h + # the time before the certificate expiry that the certificate should be automatically renewed + renewBefore: 12h ``` 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. From 747820c7dd97de022d3f9790ccd8909ecb6029f0 Mon Sep 17 00:00:00 2001 From: Fang-Pen Lin Date: Mon, 24 Nov 2025 13:57:01 -0800 Subject: [PATCH 06/22] k8s doc --- docs/documentation/platform/pki/k8s-cert-manager.mdx | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/docs/documentation/platform/pki/k8s-cert-manager.mdx b/docs/documentation/platform/pki/k8s-cert-manager.mdx index c62dbf97a..652ef7cb6 100644 --- a/docs/documentation/platform/pki/k8s-cert-manager.mdx +++ b/docs/documentation/platform/pki/k8s-cert-manager.mdx @@ -164,7 +164,8 @@ In the following steps, we explore how to install the Infisical PKI Issuer using size: 256 # the ttl for the certificate duration: 48h - # the time before the certificate expiry that the certificate should be automatically renewed + # the time before the certificate expiry that the certificate should + # be automatically renewed renewBefore: 12h ``` @@ -210,7 +211,7 @@ In the following steps, we explore how to install the Infisical PKI Issuer using 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-group: issuers.cert-manager.io cert-manager.io/issuer-kind: Issuer cert-manager.io/issuer-name: issuer-infisical cert-manager.io/uri-sans: @@ -255,11 +256,4 @@ In the following steps, we explore how to install the Infisical PKI Issuer using You can read more about the `renewBefore` field [here](https://cert-manager.io/docs/reference/api-docs/#cert-manager.io/v1.CertificateSpec). - - 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. - From 7bfb4b2969355931b8d781dd8b16f64a08bab168 Mon Sep 17 00:00:00 2001 From: Fang-Pen Lin Date: Mon, 24 Nov 2025 14:03:52 -0800 Subject: [PATCH 07/22] typo --- docs/documentation/platform/pki/k8s-cert-manager.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/documentation/platform/pki/k8s-cert-manager.mdx b/docs/documentation/platform/pki/k8s-cert-manager.mdx index 652ef7cb6..53e0188ed 100644 --- a/docs/documentation/platform/pki/k8s-cert-manager.mdx +++ b/docs/documentation/platform/pki/k8s-cert-manager.mdx @@ -35,7 +35,7 @@ In the following steps, we explore how to install the Infisical PKI Issuer using Follow the instructions [here](/documentation/platform/pki/enrollment-methods/acme) to create a certificate profile with ACME as the enrollment method. - By the end of this step, you should have a **ACME Directory URL**, **EAB KID** and **EAB Secret** on hand as part of the credentials for the Infisical PKI ACME server to authenticate with Infisical; this will be useful in steps 4 and 5. + By the end of this step, you should have a **ACME Directory URL**, **EAB KID** and **EAB Secret** on hand as part of the credentials for the Infisical PKI ACME server to authenticate with Infisical; this will be useful in step 4. Currently, the Infisical PKI ACME server only supports authenticating with Infisical via the dedicated EAB credentials generated for each certificate profile as the authentication method. From a8354f0859341cf348ec04315b3502bad3b69191 Mon Sep 17 00:00:00 2001 From: Fang-Pen Lin Date: Mon, 24 Nov 2025 14:09:38 -0800 Subject: [PATCH 08/22] docs --- docs/documentation/platform/pki/k8s-cert-manager.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/documentation/platform/pki/k8s-cert-manager.mdx b/docs/documentation/platform/pki/k8s-cert-manager.mdx index 53e0188ed..97de5e877 100644 --- a/docs/documentation/platform/pki/k8s-cert-manager.mdx +++ b/docs/documentation/platform/pki/k8s-cert-manager.mdx @@ -17,7 +17,7 @@ For the ACME part, please reference to the [ACME](https://cert-manager.io/docs/c ## Workflow -A typical workflow for using the Infisical PKI Issuer to issue certificates for your Kubernetes resources consists of the following steps: +A typical workflow for using cert-manager with Infisical PKI via ACME to issue certificates for your Kubernetes resources consists of the following steps: 1. Creating a certificate profile with ACME as the enrollment method in Infisical. 2. Installing `cert-manager` into your Kubernetes cluster. @@ -28,7 +28,7 @@ A typical workflow for using the Infisical PKI Issuer to issue certificates for ## 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. +In the following steps, we explore how to install the cert-manager using [kubectl](https://github.com/kubernetes/kubectl) and use it to obtain certificates for your Kubernetes resources. From 681f7995cf52e51d07d9b88c9af27628581e2431 Mon Sep 17 00:00:00 2001 From: Fang-Pen Lin Date: Mon, 24 Nov 2025 14:15:23 -0800 Subject: [PATCH 09/22] Proofread --- .../platform/pki/k8s-cert-manager.mdx | 52 +++++++++++-------- 1 file changed, 29 insertions(+), 23 deletions(-) diff --git a/docs/documentation/platform/pki/k8s-cert-manager.mdx b/docs/documentation/platform/pki/k8s-cert-manager.mdx index 97de5e877..980a16973 100644 --- a/docs/documentation/platform/pki/k8s-cert-manager.mdx +++ b/docs/documentation/platform/pki/k8s-cert-manager.mdx @@ -5,44 +5,50 @@ description: "Learn how to automatically provision and manage TLS certificates i ## Concept -The Infisical PKI provides [ACME (Automated Certificate Management Environment)](https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment) integration for various of ACME clients to issue and renew certificates automatically. -Under Kubernetes environment, [cert-manager](https://cert-manager.io) is the most popular issuer to issue certificates via ACME. -The issuer is perfect for getting X.509 certificates for ingresses and other Kubernetes resources and capable of automatically renewing certificates as needed. +The Infisical PKI provides ACME (Automated Certificate Management Environment) integration, enabling various ACME clients to issue and renew certificates automatically. +In Kubernetes environments, [cert-manager](https://cert-manager.io) is the most popular tool for issuing certificates via ACME. +The issuer is perfect at obtaining X.509 certificates for Ingresses and other Kubernetes resources and can automatically renew them before expiration. -As part of the workflow, you install `cert-manager` 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. +The typical workflow involves installing `cert-manager` and configuring resources that represent the connection details to your Infisical PKI 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 [cert-manager documentation](https://cert-manager.io/docs/) for a fuller understanding of all the moving parts. -For the ACME part, please reference to the [ACME](https://cert-manager.io/docs/configuration/acme/) section. +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 PKI via ACME to issue certificates for your Kubernetes resources consists of the following steps: +A typical workflow for using cert-manager with Infisical PKI via ACME consists of the following steps: -1. Creating a certificate profile with ACME as the enrollment method in Infisical. -2. Installing `cert-manager` into your Kubernetes cluster. -3. Creating a Kubernetes secret to store the EAB (External Account Binding) credentials of the ACME certificate profile. -4. Creating an `Issuer` or `ClusterIssuer` resource in your Kubernetes cluster to connect to the Infisical PKI certificate profile you wish to use. -5. 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. -6. Consuming the issued certificate across your Kubernetes resources from the specified Kubernetes `Secret`. +1. Create a certificate profile in Infisical with ACME as the enrollment method. +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 PKI certificate profile. +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 -In the following steps, we explore how to install the cert-manager using [kubectl](https://github.com/kubernetes/kubectl) and use it to obtain certificates for your Kubernetes resources. +The following steps show how to install cert-manager (using `kubectl`) and obtain certificates from Infisical PKI. - + - Follow the instructions [here](/documentation/platform/pki/enrollment-methods/acme) to create a certificate profile with ACME as the enrollment method. + Follow the instructions [here](/documentation/platform/pki/enrollment-methods/acme) to create a certificate profile that uses ACME enrollment. - By the end of this step, you should have a **ACME Directory URL**, **EAB KID** and **EAB Secret** on hand as part of the credentials for the Infisical PKI ACME server to authenticate with Infisical; this will be useful in step 4. + After completion, you will have the following values: + - **ACME Directory URL** + - **EAB Key ID (KID)** + - **EAB Secret** - - Currently, the Infisical PKI ACME server only supports authenticating with Infisical via the dedicated EAB credentials generated for each certificate profile as the authentication method. + These will be needed in later steps. - We're planning to add support for [Kubernetes Auth](/documentation/platform/identities/kubernetes-auth) in the near future. - - + + Currently, the Infisical PKI ACME server 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. + + + Install `cert-manager` into your Kubernetes cluster by following the instructions [here](https://cert-manager.io/docs/installation/) or by running the following command: From cdc1e7cc16cf259423335d535444b8c9e0653b66 Mon Sep 17 00:00:00 2001 From: Fang-Pen Lin Date: Mon, 24 Nov 2025 14:26:23 -0800 Subject: [PATCH 10/22] doc --- .../platform/pki/k8s-cert-manager.mdx | 345 +++++++++--------- 1 file changed, 176 insertions(+), 169 deletions(-) diff --git a/docs/documentation/platform/pki/k8s-cert-manager.mdx b/docs/documentation/platform/pki/k8s-cert-manager.mdx index 980a16973..7bbf183cb 100644 --- a/docs/documentation/platform/pki/k8s-cert-manager.mdx +++ b/docs/documentation/platform/pki/k8s-cert-manager.mdx @@ -49,198 +49,205 @@ The following steps show how to install cert-manager (using `kubectl`) and obtai - - 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 - ``` - - - Start by creating a Kubernetes `Secret` containing the **EAB Secret** from step 1. As mentioned previously, this will be used by the Infisical PKI issuer to authenticate with Infisical. + 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 create secret generic infisical-acme-eab-secret \ - --namespace \ - --from-literal=eabSecret= - ``` - - - ```yaml acme-eab-secret.yaml - apiVersion: v1 - kind: Secret - metadata: - name: infisical-acme-eab-secret - namespace: - data: - eabSecret: - ``` + ```bash + kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.15.3/cert-manager.yaml + ``` - ```bash - kubectl apply -f acme-eab-secret.yaml - ``` - - - - - Next, create the cert-manager Issuer or ClusterIssuer by filling out `acme_server_url`, `your_email`, `acme_eab_kid`, 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. + + + Create a Kubernetes `Secret` that contains the **EAB Secret (HMAC key)** obtained in step 1. + cert-manager uses this secret to authenticate with the Infisical ACME server via External Account Binding (EAB). - ```yaml infisical-issuer.yaml - apiVersion: cert-manager.io/v1 - kind: Issuer - metadata: + + + ```bash + kubectl create secret generic infisical-acme-eab-secret \ + --namespace \ + --from-literal=eabSecret= + ``` + + + ```yaml acme-eab-secret.yaml + apiVersion: v1 + kind: Secret + metadata: + name: infisical-acme-eab-secret + namespace: + data: + eabSecret: + ``` + + ```bash + kubectl apply -f acme-eab-secret.yaml + ``` + + + + + + Next, create the cert-manager Issuer or ClusterIssuer by filling out `acme_server_url`, `your_email`, `acme_eab_kid`, 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: cert-manager.io/v1 + kind: Issuer + metadata: + name: issuer-infisical + spec: + acme: + # the URL of your Infisical certificate profile with + # ACME enrollment method from step 1 + server: + # your email address, any email could work. + # currently we just ignore the value + email: + externalAccountBinding: + keyID: # the EAB secret value from step 1 + keySecretRef: # reference to the Secret created in step 3 + name: "issuer-infisical-client-secret" + key: "clientSecret" + privateKeySecretRef: + name: issuer-infisical-account-key + solvers: + - http01: + ingress: + # this doesn't need to be nginx, you can use any + # ingressClassName available in your Kubernetes cluster + ingressClassName: nginx + ``` + + ``` + kubectl apply -f infisical-issuer.yaml + ``` + + You can check that the issuer was created successfully by running the following command: + + ```bash + kubectl get issuers.cert-manager.io -n -o wide + ``` + + ```bash + NAME AGE + issuer-infisical 21h + ``` + + + 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/). + + Also, currently Infisical ACME server only supports HTTP-01 and requires all the certificate orders passing the challenge before issuing certificates. + We will allow users to opt-out challenge in the near future and also provide support DNS-01 as well. + + + + + + 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: + spec: + # the common name for the certificate + commonName: certificate-by-issuer.example.com + # the name of the Kubernetes Secret to create and store + # the certificate and private key in + secretName: certificate-by-issuer + issuerRef: name: issuer-infisical - spec: - acme: - # the URL of your Infisical certificate profile with - # ACME enrollment method from step 1 - server: - # your email address, any email could work. - # currently we just ignore the value - email: - externalAccountBinding: - keyID: # the EAB secret value from step 1 - keySecretRef: # reference to the Secret created in step 3 - name: "issuer-infisical-client-secret" - key: "clientSecret" - privateKeySecretRef: - name: issuer-infisical-account-key - solvers: - - http01: - ingress: - # this doesn't need to be nginx, you can use any - # ingressClassName available in your Kubernetes cluster - ingressClassName: nginx - ``` + group: issuers.cert-manager.io + kind: Issuer + # the algorithm and key size to use + privateKey: + algorithm: ECDSA + size: 256 + # the ttl for the certificate + duration: 48h + # the time before the certificate expiry that the certificate should + # be automatically renewed + renewBefore: 12h + ``` - ``` - kubectl apply -f infisical-issuer.yaml - ``` + 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`. - You can check that the issuer was created successfully by running the following command: + 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). - ```bash - kubectl get issuers.cert-manager.io -n -o wide - ``` + You can check that the certificate was created successfully by running the following command: - ```bash - NAME AGE - issuer-infisical 21h - ``` + ```bash + kubectl get certificates -n -o wide + ``` - - 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. + ```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 + ``` - 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. + + + 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: - You can read more about the `Issuer` and `ClusterIssuer` resources [here](https://cert-manager.io/docs/configuration/). + ```bash + kubectl get secret certificate-by-issuer -n + ``` - Also, currently Infisical ACME server only supports HTTP-01 and requires all the certificate orders passing the challenge before issuing certificates. - We will allow users to opt-out challenge in the near future and also provide support DNS-01 as well. - - - + ```bash + NAME TYPE DATA AGE + certificate-by-issuer kubernetes.io/tls 2 26h + ``` - 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. + We can `describe` the secret to get more information about it: - ```yaml certificate-issuer.yaml - apiVersion: cert-manager.io/v1 - kind: Certificate - metadata: - name: certificate-by-issuer - namespace: - spec: - # the common name for the certificate - commonName: certificate-by-issuer.example.com - # the name of the Kubernetes Secret to create and store - # the certificate and private key in - secretName: certificate-by-issuer - issuerRef: - name: issuer-infisical - group: issuers.cert-manager.io - kind: Issuer - # the algorithm and key size to use - privateKey: - algorithm: ECDSA - size: 256 - # the ttl for the certificate - duration: 48h - # the time before the certificate expiry that the certificate should - # be automatically renewed - renewBefore: 12h - ``` + ```bash + kubectl describe secret certificate-by-issuer -n default + ``` - 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`. + ```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: issuers.cert-manager.io + cert-manager.io/issuer-kind: Issuer + cert-manager.io/issuer-name: issuer-infisical + cert-manager.io/uri-sans: - 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). + Type: kubernetes.io/tls - You can check that the certificate was created successfully by running the following command: + Data + ==== + ca.crt: 1306 bytes + tls.crt: 2380 bytes + tls.key: 227 bytes + ``` - ```bash - kubectl get certificates -n -o wide - ``` + 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. - ```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 - ``` - - - 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: + We can decode the certificate and print it out using `openssl`: - ```bash - kubectl get secret certificate-by-issuer -n - ``` + ```bash + kubectl get secret certificate-by-issuer -n default -o jsonpath='{.data.tls\.crt}' | base64 --decode | openssl x509 -text -noout + ``` - ```bash - NAME TYPE DATA AGE - certificate-by-issuer kubernetes.io/tls 2 26h - ``` + In any case, the certificate is ready to be used as Kubernetes Secret by your Kubernetes resources. - 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: issuers.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. - + From 17c4a204f49d11f7b0cb774fbb40a6e837c9aa0b Mon Sep 17 00:00:00 2001 From: Fang-Pen Lin Date: Mon, 24 Nov 2025 14:31:40 -0800 Subject: [PATCH 11/22] docs --- .../platform/pki/k8s-cert-manager.mdx | 41 ++++++++----------- 1 file changed, 18 insertions(+), 23 deletions(-) diff --git a/docs/documentation/platform/pki/k8s-cert-manager.mdx b/docs/documentation/platform/pki/k8s-cert-manager.mdx index 7bbf183cb..89bae475d 100644 --- a/docs/documentation/platform/pki/k8s-cert-manager.mdx +++ b/docs/documentation/platform/pki/k8s-cert-manager.mdx @@ -89,35 +89,35 @@ The following steps show how to install cert-manager (using `kubectl`) and obtai - Next, create the cert-manager Issuer or ClusterIssuer by filling out `acme_server_url`, `your_email`, `acme_eab_kid`, 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. + Next, create a cert-manager `Issuer` (or `ClusterIssuer`) by replacing the placeholders ``, ``, and `` 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 infisical-issuer.yaml apiVersion: cert-manager.io/v1 kind: Issuer metadata: name: issuer-infisical + namespace: spec: acme: - # the URL of your Infisical certificate profile with - # ACME enrollment method from step 1 + # ACME server URL from your Infisical certificate profile (Step 1) server: - # your email address, any email could work. - # currently we just ignore the value + # Email address for ACME account (any valid email works; currently ignored by Infisical) email: externalAccountBinding: - keyID: # the EAB secret value from step 1 - keySecretRef: # reference to the Secret created in step 3 - name: "issuer-infisical-client-secret" - key: "clientSecret" + # EAB Key ID from Step 1 + keyID: + # Reference to the Kubernetes Secret containing the EAB HMAC key (created in Step 3) + keySecretRef: + name: issuer-infisical-client-secret + key: clientSecret privateKeySecretRef: - name: issuer-infisical-account-key + name: issuer-infisical-account-key solvers: - http01: ingress: - # this doesn't need to be nginx, you can use any - # ingressClassName available in your Kubernetes cluster - ingressClassName: nginx + # Replace with your actual ingress class if different + className: nginx ``` ``` @@ -136,15 +136,10 @@ The following steps show how to install cert-manager (using `kubectl`) and obtai ``` - 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/). - - Also, currently Infisical ACME server only supports HTTP-01 and requires all the certificate orders passing the challenge before issuing certificates. - We will allow users to opt-out challenge in the near future and also provide support DNS-01 as well. + - 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/ From 6716c5cb278ecfd8175e975ebc5b26beae2be0f4 Mon Sep 17 00:00:00 2001 From: Fang-Pen Lin Date: Mon, 24 Nov 2025 14:33:39 -0800 Subject: [PATCH 12/22] proofread --- .../platform/pki/k8s-cert-manager.mdx | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/docs/documentation/platform/pki/k8s-cert-manager.mdx b/docs/documentation/platform/pki/k8s-cert-manager.mdx index 89bae475d..1218b0f2a 100644 --- a/docs/documentation/platform/pki/k8s-cert-manager.mdx +++ b/docs/documentation/platform/pki/k8s-cert-manager.mdx @@ -102,17 +102,19 @@ The following steps show how to install cert-manager (using `kubectl`) and obtai acme: # ACME server URL from your Infisical certificate profile (Step 1) server: - # Email address for ACME account (any valid email works; currently ignored by Infisical) + # Email address for ACME account + # (any valid email works; currently ignored by Infisical) email: externalAccountBinding: - # EAB Key ID from Step 1 - keyID: - # Reference to the Kubernetes Secret containing the EAB HMAC key (created in Step 3) - keySecretRef: - name: issuer-infisical-client-secret - key: clientSecret + # EAB Key ID from Step 1 + keyID: + # 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 + name: issuer-infisical-account-key solvers: - http01: ingress: From a497b05d88c6aa6ac5d42c2f2715c77f0450d059 Mon Sep 17 00:00:00 2001 From: Fang-Pen Lin Date: Mon, 24 Nov 2025 14:38:07 -0800 Subject: [PATCH 13/22] doc --- .../platform/pki/k8s-cert-manager.mdx | 30 +++++++++---------- 1 file changed, 14 insertions(+), 16 deletions(-) diff --git a/docs/documentation/platform/pki/k8s-cert-manager.mdx b/docs/documentation/platform/pki/k8s-cert-manager.mdx index 1218b0f2a..f9049cb0b 100644 --- a/docs/documentation/platform/pki/k8s-cert-manager.mdx +++ b/docs/documentation/platform/pki/k8s-cert-manager.mdx @@ -145,9 +145,9 @@ The following steps show how to install cert-manager (using `kubectl`) and obtai - + - Finally, create a `Certificate` by applying the following configuration file. + 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 @@ -157,24 +157,22 @@ The following steps show how to install cert-manager (using `kubectl`) and obtai name: certificate-by-issuer namespace: spec: - # the common name for the certificate commonName: certificate-by-issuer.example.com - # the name of the Kubernetes Secret to create and store - # the certificate and private key in - secretName: certificate-by-issuer - issuerRef: - name: issuer-infisical - group: issuers.cert-manager.io - kind: Issuer - # the algorithm and key size to use + # name of the resulting Kubernetes Secret + secretName: certificate-by-issuer-tls + # 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 - # the ttl for the certificate - duration: 48h - # the time before the certificate expiry that the certificate should - # be automatically renewed - renewBefore: 12h + issuerRef: + name: issuer-infisical + # use ClusterIssuer if you created a ClusterIssuer instead + kind: Issuer + group: cert-manager.io ``` 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. From 9fdce60708ec11fc0805fcecfe7f85f264d3a944 Mon Sep 17 00:00:00 2001 From: Fang-Pen Lin Date: Mon, 24 Nov 2025 16:39:44 -0800 Subject: [PATCH 14/22] k8s doc --- .../platform/pki/k8s-cert-manager.mdx | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/docs/documentation/platform/pki/k8s-cert-manager.mdx b/docs/documentation/platform/pki/k8s-cert-manager.mdx index f9049cb0b..67fa25696 100644 --- a/docs/documentation/platform/pki/k8s-cert-manager.mdx +++ b/docs/documentation/platform/pki/k8s-cert-manager.mdx @@ -5,7 +5,7 @@ description: "Learn how to automatically provision and manage TLS certificates i ## Concept -The Infisical PKI provides ACME (Automated Certificate Management Environment) integration, enabling various ACME clients to issue and renew certificates automatically. +The Infisical PKI provides [ACME (Automated Certificate Management Environment)](https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment) integration, enabling various ACME clients to issue and renew certificates automatically. In Kubernetes environments, [cert-manager](https://cert-manager.io) is the most popular tool for issuing certificates via ACME. The issuer is perfect at obtaining X.509 certificates for Ingresses and other Kubernetes resources and can automatically renew them before expiration. @@ -54,13 +54,13 @@ The following steps show how to install cert-manager (using `kubectl`) and obtai 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.15.3/cert-manager.yaml + kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.19.1/cert-manager.yaml ``` Create a Kubernetes `Secret` that contains the **EAB Secret (HMAC key)** obtained in step 1. - cert-manager uses this secret to authenticate with the Infisical ACME server via External Account Binding (EAB). + The cert-manager uses this secret to authenticate with the Infisical ACME server. @@ -92,7 +92,7 @@ The following steps show how to install cert-manager (using `kubectl`) and obtai Next, create a cert-manager `Issuer` (or `ClusterIssuer`) by replacing the placeholders ``, ``, and `` 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 infisical-issuer.yaml + ```yaml issuer-infisical.yaml apiVersion: cert-manager.io/v1 kind: Issuer metadata: @@ -123,7 +123,7 @@ The following steps show how to install cert-manager (using `kubectl`) and obtai ``` ``` - kubectl apply -f infisical-issuer.yaml + kubectl apply -f issuer-infisical.yaml ``` You can check that the issuer was created successfully by running the following command: @@ -157,7 +157,8 @@ The following steps show how to install cert-manager (using `kubectl`) and obtai name: certificate-by-issuer namespace: spec: - commonName: certificate-by-issuer.example.com + dnsNames: + - certificate-by-issuer.example.com # name of the resulting Kubernetes Secret secretName: certificate-by-issuer-tls # total validity period of the certificate @@ -170,9 +171,6 @@ The following steps show how to install cert-manager (using `kubectl`) and obtai size: 256 issuerRef: name: issuer-infisical - # use ClusterIssuer if you created a ClusterIssuer instead - kind: Issuer - group: cert-manager.io ``` 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. From 740573daabacc57e64c0f3b495fadbc87e4bdcb8 Mon Sep 17 00:00:00 2001 From: Fang-Pen Lin Date: Mon, 24 Nov 2025 16:41:45 -0800 Subject: [PATCH 15/22] doc --- docs/documentation/platform/pki/k8s-cert-manager.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/documentation/platform/pki/k8s-cert-manager.mdx b/docs/documentation/platform/pki/k8s-cert-manager.mdx index 67fa25696..cf6edc3d5 100644 --- a/docs/documentation/platform/pki/k8s-cert-manager.mdx +++ b/docs/documentation/platform/pki/k8s-cert-manager.mdx @@ -173,7 +173,7 @@ The following steps show how to install cert-manager (using `kubectl`) and obtai name: issuer-infisical ``` - 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 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). From a5516e4214a0d4c74c4eb15f0b4d251b52be1873 Mon Sep 17 00:00:00 2001 From: Fang-Pen Lin Date: Mon, 24 Nov 2025 16:45:44 -0800 Subject: [PATCH 16/22] doc --- docs/documentation/platform/pki/k8s-cert-manager.mdx | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/documentation/platform/pki/k8s-cert-manager.mdx b/docs/documentation/platform/pki/k8s-cert-manager.mdx index cf6edc3d5..8423ca2ca 100644 --- a/docs/documentation/platform/pki/k8s-cert-manager.mdx +++ b/docs/documentation/platform/pki/k8s-cert-manager.mdx @@ -214,9 +214,10 @@ The following steps show how to install cert-manager (using `kubectl`) and obtai 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/common-name: + cert-manager.io/alt-names: certificate-by-issuer.example.com cert-manager.io/ip-sans: - cert-manager.io/issuer-group: issuers.cert-manager.io + 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: From 05f4d4bbfa620d2b598a5b97ffacf40a63b58771 Mon Sep 17 00:00:00 2001 From: Fang-Pen Lin Date: Mon, 24 Nov 2025 16:54:15 -0800 Subject: [PATCH 17/22] Update gloo mesh doc as well --- .../platform/pki/integration-guides/gloo-mesh.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/documentation/platform/pki/integration-guides/gloo-mesh.mdx b/docs/documentation/platform/pki/integration-guides/gloo-mesh.mdx index 0f312af01..96f4c96cd 100644 --- a/docs/documentation/platform/pki/integration-guides/gloo-mesh.mdx +++ b/docs/documentation/platform/pki/integration-guides/gloo-mesh.mdx @@ -21,11 +21,11 @@ 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 Infisical PKI ACME server to authenticate with Infisical 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 [Kubernetes Cert Manager guide](/documentation/platform/pki/k8s-cert-manager) 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 PKI Issuer and cert-manager for your Istio intermediate CA certificates in Gloo Mesh clusters. For Gloo Mesh-specific configuration, ensure that: From c272c0552c7b3fd05959ef0915fc2e3aded19525 Mon Sep 17 00:00:00 2001 From: Fang-Pen Lin Date: Mon, 24 Nov 2025 16:55:51 -0800 Subject: [PATCH 18/22] ACME --- .../getting-started/concepts/client-integrations.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/documentation/getting-started/concepts/client-integrations.mdx b/docs/documentation/getting-started/concepts/client-integrations.mdx index 2a575039a..b74d68f74 100644 --- a/docs/documentation/getting-started/concepts/client-integrations.mdx +++ b/docs/documentation/getting-started/concepts/client-integrations.mdx @@ -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/k8s-cert-manager): 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 PKI ACME server 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. From 44fc9d1f1828ee2fcd7c070a7239e3e0e9f017c6 Mon Sep 17 00:00:00 2001 From: Fang-Pen Lin Date: Mon, 24 Nov 2025 16:57:37 -0800 Subject: [PATCH 19/22] More docs --- .../documentation/platform/pki/integration-guides/gloo-mesh.mdx | 2 +- docs/documentation/platform/pki/k8s-cert-manager.mdx | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/documentation/platform/pki/integration-guides/gloo-mesh.mdx b/docs/documentation/platform/pki/integration-guides/gloo-mesh.mdx index 96f4c96cd..c23bac676 100644 --- a/docs/documentation/platform/pki/integration-guides/gloo-mesh.mdx +++ b/docs/documentation/platform/pki/integration-guides/gloo-mesh.mdx @@ -25,7 +25,7 @@ When you deploy a `Certificate` CRD in your workload cluster, `cert-manager` use 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 [Kubernetes cert-manager guide](/documentation/platform/pki/k8s-cert-manager) 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 PKI ACME certificate profile and cert-manager for your Istio intermediate CA certificates in Gloo Mesh clusters. For Gloo Mesh-specific configuration, ensure that: diff --git a/docs/documentation/platform/pki/k8s-cert-manager.mdx b/docs/documentation/platform/pki/k8s-cert-manager.mdx index 8423ca2ca..e4f293cd7 100644 --- a/docs/documentation/platform/pki/k8s-cert-manager.mdx +++ b/docs/documentation/platform/pki/k8s-cert-manager.mdx @@ -252,7 +252,7 @@ The following steps show how to install cert-manager (using `kubectl`) and obtai 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). - Currently, not all fields are supported by the Infisical PKI Issuer. + Currently, not all fields are supported by the Infisical PKI ACME server. From 5bb59625fc32470b605cc2ddf14bccb718f32c02 Mon Sep 17 00:00:00 2001 From: Fang-Pen Lin Date: Mon, 24 Nov 2025 19:13:30 -0800 Subject: [PATCH 20/22] inconsistency name --- docs/documentation/platform/pki/k8s-cert-manager.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/documentation/platform/pki/k8s-cert-manager.mdx b/docs/documentation/platform/pki/k8s-cert-manager.mdx index e4f293cd7..2776759ce 100644 --- a/docs/documentation/platform/pki/k8s-cert-manager.mdx +++ b/docs/documentation/platform/pki/k8s-cert-manager.mdx @@ -160,7 +160,7 @@ The following steps show how to install cert-manager (using `kubectl`) and obtai dnsNames: - certificate-by-issuer.example.com # name of the resulting Kubernetes Secret - secretName: certificate-by-issuer-tls + secretName: certificate-by-issuer # total validity period of the certificate duration: 48h # cert-manager will attempt renewal 12 hours before expiry From 12c9c4054eaecf5ec5735252e12468b95a167c14 Mon Sep 17 00:00:00 2001 From: Tuan Dang Date: Tue, 25 Nov 2025 00:02:25 -0500 Subject: [PATCH 21/22] Revise pki k8s docs --- .../platform/pki/enrollment-methods/acme.mdx | 2 +- .../pki/integration-guides/apache-certbot.mdx | 7 ++++--- .../pki/integration-guides/gloo-mesh.mdx | 16 +++++++------- .../pki/integration-guides/jboss-certbot.mdx | 7 ++++--- .../pki/integration-guides/nginx-certbot.mdx | 4 ++-- .../pki/integration-guides/tomcat-certbot.mdx | 7 ++++--- .../windows-server-acme.mdx | 5 +++-- .../platform/pki/k8s-cert-manager.mdx | 21 ++++++++++--------- 8 files changed, 37 insertions(+), 32 deletions(-) diff --git a/docs/documentation/platform/pki/enrollment-methods/acme.mdx b/docs/documentation/platform/pki/enrollment-methods/acme.mdx index 12c4779b5..50a4a615c 100644 --- a/docs/documentation/platform/pki/enrollment-methods/acme.mdx +++ b/docs/documentation/platform/pki/enrollment-methods/acme.mdx @@ -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/). diff --git a/docs/documentation/platform/pki/integration-guides/apache-certbot.mdx b/docs/documentation/platform/pki/integration-guides/apache-certbot.mdx index 78f0301e1..f7e066d7b 100644 --- a/docs/documentation/platform/pki/integration-guides/apache-certbot.mdx +++ b/docs/documentation/platform/pki/integration-guides/apache-certbot.mdx @@ -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. @@ -182,4 +182,5 @@ Before you begin, make sure you have: - \ No newline at end of file + + diff --git a/docs/documentation/platform/pki/integration-guides/gloo-mesh.mdx b/docs/documentation/platform/pki/integration-guides/gloo-mesh.mdx index c23bac676..d83e062fa 100644 --- a/docs/documentation/platform/pki/integration-guides/gloo-mesh.mdx +++ b/docs/documentation/platform/pki/integration-guides/gloo-mesh.mdx @@ -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 ACME server to authenticate with Infisical using EAB 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 [Kubernetes cert-manager guide](/documentation/platform/pki/k8s-cert-manager) for detailed instructions on how to set up the Infisical PKI ACME certificate profile 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. diff --git a/docs/documentation/platform/pki/integration-guides/jboss-certbot.mdx b/docs/documentation/platform/pki/integration-guides/jboss-certbot.mdx index c0e1c896b..f666e8be6 100644 --- a/docs/documentation/platform/pki/integration-guides/jboss-certbot.mdx +++ b/docs/documentation/platform/pki/integration-guides/jboss-certbot.mdx @@ -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. @@ -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. - \ No newline at end of file + + diff --git a/docs/documentation/platform/pki/integration-guides/nginx-certbot.mdx b/docs/documentation/platform/pki/integration-guides/nginx-certbot.mdx index f28e5ee09..4e0cdba1d 100644 --- a/docs/documentation/platform/pki/integration-guides/nginx-certbot.mdx +++ b/docs/documentation/platform/pki/integration-guides/nginx-certbot.mdx @@ -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). diff --git a/docs/documentation/platform/pki/integration-guides/tomcat-certbot.mdx b/docs/documentation/platform/pki/integration-guides/tomcat-certbot.mdx index ffb07bf1b..3b8727748 100644 --- a/docs/documentation/platform/pki/integration-guides/tomcat-certbot.mdx +++ b/docs/documentation/platform/pki/integration-guides/tomcat-certbot.mdx @@ -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. @@ -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. - \ No newline at end of file + + diff --git a/docs/documentation/platform/pki/integration-guides/windows-server-acme.mdx b/docs/documentation/platform/pki/integration-guides/windows-server-acme.mdx index 2aab0870d..0a630a10a 100644 --- a/docs/documentation/platform/pki/integration-guides/windows-server-acme.mdx +++ b/docs/documentation/platform/pki/integration-guides/windows-server-acme.mdx @@ -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. @@ -191,4 +191,5 @@ Before you begin, make sure you have: + diff --git a/docs/documentation/platform/pki/k8s-cert-manager.mdx b/docs/documentation/platform/pki/k8s-cert-manager.mdx index 2776759ce..b0f696ba9 100644 --- a/docs/documentation/platform/pki/k8s-cert-manager.mdx +++ b/docs/documentation/platform/pki/k8s-cert-manager.mdx @@ -1,15 +1,16 @@ --- title: "Kubernetes cert-manager" -description: "Learn how to automatically provision and manage TLS certificates in Kubernetes using Infisical PKI" +description: "Learn how to automatically provision and manage TLS certificates in Kubernetes using Infisical" --- ## Concept -The Infisical PKI provides [ACME (Automated Certificate Management Environment)](https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment) integration, enabling various ACME clients to issue and renew certificates automatically. -In Kubernetes environments, [cert-manager](https://cert-manager.io) is the most popular tool for issuing certificates via ACME. -The issuer is perfect at obtaining X.509 certificates for Ingresses and other Kubernetes resources and can automatically renew them before expiration. +This guide demonstrates how to use Infisical to issue TLS certificates back to your Kubernetes environment using [cert-manager](https://cert-manager.io/). -The typical workflow involves installing `cert-manager` and configuring resources that represent the connection details to your Infisical PKI as well as the certificates you want to issue. +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. @@ -17,18 +18,18 @@ For the ACME-specific configuration, refer to the [ACME section](https://cert-ma ## Workflow -A typical workflow for using cert-manager with Infisical PKI via ACME consists of the following steps: +A typical workflow for using cert-manager with Infisical via ACME consists of the following steps: -1. Create a certificate profile in Infisical with ACME as the enrollment method. +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 PKI 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 PKI. +The following steps show how to install cert-manager (using `kubectl`) and obtain certificates from Infisical. @@ -43,7 +44,7 @@ The following steps show how to install cert-manager (using `kubectl`) and obtai These will be needed in later steps. - Currently, the Infisical PKI ACME server only supports authentication via dedicated EAB credentials generated per certificate profile. + 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. From ae948fcde0cf8357c727a97c4db0467f9a56ecd3 Mon Sep 17 00:00:00 2001 From: Tuan Dang Date: Tue, 25 Nov 2025 00:03:30 -0500 Subject: [PATCH 22/22] add link --- .../getting-started/concepts/client-integrations.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/documentation/getting-started/concepts/client-integrations.mdx b/docs/documentation/getting-started/concepts/client-integrations.mdx index b74d68f74..aa7b37d4a 100644 --- a/docs/documentation/getting-started/concepts/client-integrations.mdx +++ b/docs/documentation/getting-started/concepts/client-integrations.mdx @@ -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 cert-manager](/documentation/platform/pki/k8s-cert-manager): A controller that issues X.509 certificates from Infisical PKI ACME server 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.