mirror of
https://github.com/awatertrevi/infisical.git
synced 2026-09-22 13:39:35 +00:00
merge main
This commit is contained in:
Scott Wilson
@@ -3,10 +3,10 @@ title: "Access Requests"
|
||||
description: "Learn how to request access to sensitive resources in Infisical."
|
||||
---
|
||||
|
||||
In certain situations, developers need to expand their access to a certain new project or a sensitive environment. For those use cases, it is helpful to utilize Infisical's **Access Requests** functionality.
|
||||
In certain situations, developers need to expand their access to a certain new project or a sensitive environment. For those use cases, it is helpful to utilize Infisical's **Access Requests** functionality.
|
||||
|
||||
This functionality works in the following way:
|
||||
1. A project administrator sets up an access policy that assigns access managers (also known as eligible approvers) to a certain sensitive folder or environment.
|
||||
This functionality works in the following way:
|
||||
1. A project administrator sets up an access policy that assigns access managers (also known as eligible approvers) to a certain sensitive folder or environment.
|
||||
|
||||
|
||||
|
||||
@@ -19,9 +19,8 @@ This functionality works in the following way:
|
||||
|
||||
|
||||
<Info>
|
||||
If the access request matches with a policy that has a **Soft** enforcement level, the requester may bypass the policy and get access to the resource without full approval.
|
||||
If the access request matches with a policy that allows break-glass approval bypasses, the requester may bypass the policy and get access to the resource without full approval.
|
||||
</Info>
|
||||
|
||||
5. As soon as the request is approved, developer is able to access the sought resources.
|
||||
5. As soon as the request is approved, developer is able to access the sought resources.
|
||||
|
||||
|
||||
|
||||
@@ -60,7 +60,7 @@ The Infisical AWS ElastiCache dynamic secret allows you to generate AWS ElastiCa
|
||||
<Step title="Click on the 'Add Dynamic Secret' button">
|
||||
|
||||
</Step>
|
||||
<Step title="Select 'AWS ElastiCache'">
|
||||
<Step title="Select AWS ElastiCache">
|
||||
|
||||
</Step>
|
||||
<Step title="Provide the inputs for dynamic secret parameters">
|
||||
@@ -94,21 +94,29 @@ The Infisical AWS ElastiCache dynamic secret allows you to generate AWS ElastiCa
|
||||
|
||||
</Step>
|
||||
<Step title="(Optional) Modify ElastiCache Statements">
|
||||
If you want to provide specific privileges for the generated dynamic credentials, you can modify the ElastiCache statement to your needs. This is useful if you want to only give access to a specific table(s).
|
||||
|
||||
<ParamField path="Username Template" type="string" default="{{randomUsername}}">
|
||||
Specifies a template for generating usernames. This field allows customization of how usernames are automatically created.
|
||||
|
||||
|
||||
Allowed template variables are
|
||||
- `{{randomUsername}}`: Random username string
|
||||
- `{{unixTimestamp}}`: Current Unix timestamp
|
||||
</ParamField>
|
||||
<ParamField path="Customize ElastiCache Statement" type="string">
|
||||
If you want to provide specific privileges for the generated dynamic credentials, you can modify the ElastiCache statement to your needs. This is useful if you want to only give access to a specific resource.
|
||||
</ParamField>
|
||||
</Step>
|
||||
<Step title="Click `Submit`">
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
|
||||
<Note>
|
||||
If this step fails, you may have to add the CA certificate.
|
||||
If this step fails, you may have to add the CA certificate.
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
<Step title="Generate dynamic secrets">
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Alternatively, you can initiate the creation of a new lease by selecting 'New Lease' from the dynamic secret lease list section.
|
||||
|
||||
|
||||
@@ -123,14 +131,14 @@ The Infisical AWS ElastiCache dynamic secret allows you to generate AWS ElastiCa
|
||||
</Tip>
|
||||
|
||||
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials from it will be shown to you.
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials from it will be shown to you.
|
||||
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Audit or Revoke Leases
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
This will allow you to see the expiration time of the lease or delete a lease before it's set time to live.
|
||||
|
||||
|
||||
@@ -141,4 +149,4 @@ To extend the life of the generated dynamic secret leases past its initial time
|
||||
|
||||
<Warning>
|
||||
Lease renewals cannot exceed the maximum TTL set when configuring the dynamic secret
|
||||
</Warning>
|
||||
</Warning>
|
||||
|
||||
@@ -40,7 +40,7 @@ Infisical needs an initial AWS IAM user with the required permissions to create
|
||||
}
|
||||
```
|
||||
|
||||
To minimize managing user access you can attach a resource in format
|
||||
To minimize managing user access you can attach a resource in format
|
||||
|
||||
> arn:aws:iam::\<account-id\>:user/\<aws-scope-path\>
|
||||
|
||||
@@ -94,28 +94,36 @@ Replace **\<account id\>** with your AWS account id and **\<aws-scope-path\>** w
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="AWS IAM Groups" type="string">
|
||||
The AWS IAM groups that should be assigned to the created users. Multiple values can be provided by separating them with commas
|
||||
The AWS IAM groups that should be assigned to the created users. Multiple values can be provided by separating them with commas
|
||||
</ParamField>
|
||||
|
||||
|
||||
<ParamField path="AWS Policy ARNs" type="string">
|
||||
The AWS IAM managed policies that should be attached to the created users. Multiple values can be provided by separating them with commas
|
||||
The AWS IAM managed policies that should be attached to the created users. Multiple values can be provided by separating them with commas
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="AWS IAM Policy Document" type="string">
|
||||
The AWS IAM inline policy that should be attached to the created users. Multiple values can be provided by separating them with commas
|
||||
The AWS IAM inline policy that should be attached to the created users. Multiple values can be provided by separating them with commas
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Username Template" type="string" default="{{randomUsername}}">
|
||||
Specifies a template for generating usernames. This field allows customization of how usernames are automatically created.
|
||||
|
||||
Allowed template variables are
|
||||
- `{{randomUsername}}`: Random username string
|
||||
- `{{unixTimestamp}}`: Current Unix timestamp
|
||||
</ParamField>
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Click 'Submit'">
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Generate dynamic secrets">
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Alternatively, you can initiate the creation of a new lease by selecting 'New Lease' from the dynamic secret lease list section.
|
||||
|
||||
|
||||
@@ -130,14 +138,14 @@ Replace **\<account id\>** with your AWS account id and **\<aws-scope-path\>** w
|
||||
</Tip>
|
||||
|
||||
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials for it will be shown to you.
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials for it will be shown to you.
|
||||
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Audit or Revoke Leases
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
This will allow you to see the lease details and delete the lease ahead of its expiration time.
|
||||
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ The Infisical Cassandra dynamic secret allows you to generate Cassandra database
|
||||
|
||||
## Prerequisite
|
||||
|
||||
Infisical requires a Cassandra user in your instance with the necessary permissions. This user will facilitate the creation of new accounts as needed.
|
||||
Infisical requires a Cassandra user in your instance with the necessary permissions. This user will facilitate the creation of new accounts as needed.
|
||||
Ensure the user possesses privileges for creating, dropping, and granting permissions to roles for it to be able to create dynamic secrets.
|
||||
|
||||
<Tip>
|
||||
@@ -19,7 +19,7 @@ authorizer: CassandraAuthorizer
|
||||
```
|
||||
</Tip>
|
||||
|
||||
The above configuration allows user creation and granting permissions.
|
||||
The above configuration allows user creation and granting permissions.
|
||||
|
||||
## Set up Dynamic Secrets with Cassandra
|
||||
|
||||
@@ -69,31 +69,39 @@ The above configuration allows user creation and granting permissions.
|
||||
<ParamField path="Keyspace" type="string">
|
||||
Keyspace name where you want to create dynamic secrets. This ensures that the user is limited to that keyspace.
|
||||
</ParamField>
|
||||
|
||||
|
||||
<ParamField path="CA(SSL)" type="string">
|
||||
A CA may be required if your cassandra requires it for incoming connections.
|
||||
A CA may be required if your cassandra requires it for incoming connections.
|
||||
</ParamField>
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="(Optional) Modify CQL Statements">
|
||||
If you want to provide specific privileges for the generated dynamic credentials, you can modify the CQL statement to your needs. This is useful if you want to only give access to a specific key-space(s).
|
||||
|
||||
<ParamField path="Username Template" type="string" default="{{randomUsername}}">
|
||||
Specifies a template for generating usernames. This field allows customization of how usernames are automatically created.
|
||||
|
||||
|
||||
Allowed template variables are
|
||||
- `{{randomUsername}}`: Random username string
|
||||
- `{{unixTimestamp}}`: Current Unix timestamp
|
||||
</ParamField>
|
||||
<ParamField path="Customize CQL Statement" type="string">
|
||||
If you want to provide specific privileges for the generated dynamic credentials, you can modify the CQL statement to your needs. This is useful if you want to only give access to a specific key-space(s).
|
||||
</ParamField>
|
||||
</Step>
|
||||
<Step title="Click 'Submit'">
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
|
||||
<Note>
|
||||
If this step fails, you may have to add the CA certficate.
|
||||
If this step fails, you may have to add the CA certificate.
|
||||
</Note>
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Generate dynamic secrets">
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Alternatively, you can initiate the creation of a new lease by selecting 'New Lease' from the dynamic secret lease list section.
|
||||
|
||||
|
||||
@@ -108,14 +116,14 @@ The above configuration allows user creation and granting permissions.
|
||||
</Tip>
|
||||
|
||||
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials for it will be shown to you.
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials for it will be shown to you.
|
||||
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Audit or Revoke Leases
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
This will allow you to see the lease details and delete the lease ahead of its expiration time.
|
||||
|
||||
|
||||
|
||||
@@ -7,13 +7,14 @@ The Infisical Elasticsearch dynamic secret allows you to generate Elasticsearch
|
||||
|
||||
## Prerequisites
|
||||
|
||||
|
||||
|
||||
1. Create a role with at least `manage_security` and `monitor` permissions.
|
||||
2. Assign the newly created role to your API key or user that you'll use later in the dynamic secret configuration.
|
||||
|
||||
<Note>
|
||||
For testing purposes, you can also use a highly privileged role like `superuser`, that will have full control over the cluster. This is not recommended in production environments following the principle of least privilege.
|
||||
For testing purposes, you can also use a highly privileged role like
|
||||
`superuser`, that will have full control over the cluster. This is not
|
||||
recommended in production environments following the principle of least
|
||||
privilege.
|
||||
</Note>
|
||||
|
||||
## Set up Dynamic Secrets with Elasticsearch
|
||||
@@ -33,95 +34,115 @@ The Infisical Elasticsearch dynamic secret allows you to generate Elasticsearch
|
||||
Name by which you want the secret to be referenced
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Default TTL" type="string" required>
|
||||
Default time-to-live for a generated secret (it is possible to modify this value after a secret is generated)
|
||||
</ParamField>
|
||||
<ParamField path="Default TTL" type="string" required>
|
||||
Default time-to-live for a generated secret (it is possible to modify this value after a secret is generated)
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Max TTL" type="string" required>
|
||||
Maximum time-to-live for a generated secret.
|
||||
</ParamField>
|
||||
<ParamField path="Max TTL" type="string" required>
|
||||
Maximum time-to-live for a generated secret.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Host" type="string" required>
|
||||
<ParamField path="Host" type="string" required>
|
||||
Your Elasticsearch host. This is the endpoint that your instance runs on. _(Example: https://your-cluster-ip)_
|
||||
</ParamField>
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Port" type="string" required>
|
||||
The port that your Elasticsearch instance is running on. _(Example: 9200)_
|
||||
</ParamField>
|
||||
<ParamField path="Port" type="string" required>
|
||||
|
||||
<ParamField path="Roles" type="string[]" required>
|
||||
The roles that the new user that is created when a lease is provisioned will be assigned to. This is a required field. This defaults to `superuser`, which is highly privileged. It is recommended to create a new role with the least privileges required for the lease.
|
||||
</ParamField>
|
||||
The port that your Elasticsearch instance is running on. _(Example: 9200)_
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Authentication Method" type="API Key | Username/Password" required>
|
||||
<ParamField path="Roles" type="string[]" required>
|
||||
The roles that the new user that is created when a lease is provisioned will
|
||||
be assigned to. This is a required field. This defaults to `superuser`, which
|
||||
is highly privileged. It is recommended to create a new role with the least
|
||||
privileges required for the lease.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Authentication Method" type="API Key | Username/Password" required>
|
||||
Select the authentication method you want to use to connect to your Elasticsearch instance.
|
||||
</ParamField>
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Username" type="string" required>
|
||||
The username of the user that will be used to provision new dynamic secret leases. Only required if you selected the `Username/Password` authentication method.
|
||||
</ParamField>
|
||||
<ParamField path="Username" type="string" required>
|
||||
The username of the user that will be used to provision new dynamic secret
|
||||
leases. Only required if you selected the `Username/Password` authentication
|
||||
method.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Password" type="string" required>
|
||||
The password of the user that will be used to provision new dynamic secret leases. Only required if you selected the `Username/Password` authentication method.
|
||||
</ParamField>
|
||||
<ParamField path="Password" type="string" required>
|
||||
The password of the user that will be used to provision new dynamic secret
|
||||
leases. Only required if you selected the `Username/Password` authentication
|
||||
method.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="API Key ID" required>
|
||||
The ID of the API key that will be used to provision new dynamic secret leases. Only required if you selected the `API Key` authentication method.
|
||||
</ParamField>
|
||||
<ParamField path="API Key ID" required>
|
||||
The ID of the API key that will be used to provision new dynamic secret
|
||||
leases. Only required if you selected the `API Key` authentication method.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="API Key" required>
|
||||
The API key that will be used to provision new dynamic secret leases. Only required if you selected the `API Key` authentication method.
|
||||
</ParamField>
|
||||
<ParamField path="API Key" required>
|
||||
The API key that will be used to provision new dynamic secret leases. Only
|
||||
required if you selected the `API Key` authentication method.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="CA(SSL)" type="string">
|
||||
A CA may be required if your DB requires it for incoming connections. This is often the case when connecting to a managed service.
|
||||
</ParamField>
|
||||
<ParamField path="CA(SSL)" type="string">
|
||||
A CA may be required if your DB requires it for incoming connections. This is often the case when connecting to a managed service.
|
||||
</ParamField>
|
||||
<ParamField path="Username Template" type="string" default="{{randomUsername}}">
|
||||
Specifies a template for generating usernames. This field allows customization of how usernames are automatically created.
|
||||
|
||||
|
||||
Allowed template variables are
|
||||
- `{{randomUsername}}`: Random username string
|
||||
- `{{unixTimestamp}}`: Current Unix timestamp
|
||||
</ParamField>
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Click `Submit`">
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
|
||||
<Note>
|
||||
If this step fails, you may have to add the CA certificate.
|
||||
</Note>
|
||||
<Note>
|
||||
If this step fails, you may have to add the CA certificate.
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
<Step title="Generate dynamic secrets">
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Alternatively, you can initiate the creation of a new lease by selecting 'New Lease' from the dynamic secret lease list section.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
|
||||
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
|
||||
|
||||
|
||||
|
||||
|
||||
<Tip>
|
||||
Ensure that the TTL for the lease fall within the maximum TTL defined when configuring the dynamic secret.
|
||||
</Tip>
|
||||
<Tip>
|
||||
Ensure that the TTL for the lease fall within the maximum TTL defined when configuring the dynamic secret.
|
||||
</Tip>
|
||||
|
||||
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials from it will be shown to you.
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials from it will be shown to you.
|
||||
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Audit or Revoke Leases
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
This will allow you to see the expiration time of the lease or delete a lease before it's set time to live.
|
||||
|
||||
|
||||
|
||||
## Renew Leases
|
||||
|
||||
To extend the life of the generated dynamic secret leases past its initial time to live, simply click on the **Renew** button as illustrated below.
|
||||
|
||||
|
||||
<Warning>
|
||||
Lease renewals cannot exceed the maximum TTL set when configuring the dynamic secret
|
||||
Lease renewals cannot exceed the maximum TTL set when configuring the dynamic
|
||||
secret
|
||||
</Warning>
|
||||
|
||||
243
docs/documentation/platform/dynamic-secrets/kubernetes.mdx
Normal file
243
docs/documentation/platform/dynamic-secrets/kubernetes.mdx
Normal file
@@ -0,0 +1,243 @@
|
||||
---
|
||||
title: "Kubernetes"
|
||||
description: "Learn how to dynamically generate Kubernetes service account tokens."
|
||||
---
|
||||
|
||||
The Infisical Kubernetes dynamic secret allows you to generate short-lived service account tokens on demand.
|
||||
|
||||
## Overview
|
||||
|
||||
The Kubernetes dynamic secret feature enables you to generate short-lived service account tokens for your Kubernetes clusters. This is particularly useful for:
|
||||
|
||||
- **Secure Access Management**: Instead of using long-lived service account tokens, you can generate short-lived tokens that automatically expire, reducing the risk of token exposure.
|
||||
- **Temporary Access**: Generate tokens with specific TTLs (Time To Live) for temporary access to your Kubernetes clusters.
|
||||
- **Audit Trail**: Each token generation is tracked, providing better visibility into who accessed your cluster and when.
|
||||
- **Integration with Private Clusters**: Seamlessly work with private Kubernetes clusters using Infisical's Gateway feature.
|
||||
|
||||
<Note>
|
||||
Kubernetes service account tokens cannot be revoked once issued. This is why
|
||||
it's important to use short TTLs and carefully manage token generation. The
|
||||
tokens will automatically expire after their TTL period.
|
||||
</Note>
|
||||
|
||||
<Note>
|
||||
Kubernetes service account tokens are JWTs (JSON Web Tokens) with a fixed
|
||||
expiration time. Once a token is generated, its lifetime cannot be extended.
|
||||
If you need longer access, you'll need to generate a new token.
|
||||
</Note>
|
||||
|
||||
This feature is ideal for scenarios where you need to:
|
||||
|
||||
- Provide temporary access to developers or CI/CD pipelines
|
||||
- Rotate service account tokens frequently
|
||||
- Maintain a secure audit trail of cluster access
|
||||
- Manage access to multiple Kubernetes clusters
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- A Kubernetes cluster with a service account
|
||||
- Cluster access token with permissions to create service account tokens
|
||||
- (Optional) [Gateway](/documentation/platform/gateways/overview) for private cluster access
|
||||
|
||||
## RBAC Configuration
|
||||
|
||||
Before you can start generating dynamic service account tokens, you'll need to configure the appropriate permissions in your Kubernetes cluster. This involves setting up Role-Based Access Control (RBAC) to allow the creation and management of service account tokens.
|
||||
|
||||
The RBAC configuration serves a crucial security purpose: it creates a dedicated service account with minimal permissions that can only create and manage service account tokens. This follows the principle of least privilege, ensuring that the token generation process is secure and controlled.
|
||||
|
||||
The following RBAC configuration creates the necessary permissions for generating service account tokens:
|
||||
|
||||
```yaml rbac.yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: tokenrequest
|
||||
rules:
|
||||
- apiGroups: [""]
|
||||
resources:
|
||||
- "serviceaccounts/token"
|
||||
- "serviceaccounts"
|
||||
verbs:
|
||||
- "create"
|
||||
- "get"
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
name: tokenrequest
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: tokenrequest
|
||||
subjects:
|
||||
- kind: ServiceAccount
|
||||
name: infisical-token-requester
|
||||
namespace: default
|
||||
```
|
||||
|
||||
```bash
|
||||
kubectl apply -f rbac.yaml
|
||||
```
|
||||
|
||||
This configuration:
|
||||
|
||||
1. Creates a `ClusterRole` named `tokenrequest` that allows:
|
||||
- Creating and getting service account tokens
|
||||
- Getting service account information
|
||||
2. Creates a `ClusterRoleBinding` that binds the role to a service account named `infisical-token-requester` in the `default` namespace
|
||||
|
||||
You can customize the service account name and namespace according to your needs.
|
||||
|
||||
## Obtaining the Cluster Token
|
||||
|
||||
After setting up the RBAC configuration, you need to obtain a token for the service account that will be used to create dynamic secrets. Here's how to get the token:
|
||||
|
||||
1. Create a service account in your Kubernetes cluster that will be used to create service account tokens:
|
||||
|
||||
```yaml infisical-service-account.yaml
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: infisical-token-requester
|
||||
namespace: default
|
||||
```
|
||||
|
||||
```bash
|
||||
kubectl apply -f infisical-service-account.yaml
|
||||
```
|
||||
|
||||
2. Create a long-lived service account token using this configuration file:
|
||||
|
||||
```yaml service-account-token.yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
type: kubernetes.io/service-account-token
|
||||
metadata:
|
||||
name: infisical-token-requester-token
|
||||
annotations:
|
||||
kubernetes.io/service-account.name: "infisical-token-requester"
|
||||
```
|
||||
|
||||
```bash
|
||||
kubectl apply -f service-account-token.yaml
|
||||
```
|
||||
|
||||
3. Link the secret to the service account:
|
||||
|
||||
```bash
|
||||
kubectl patch serviceaccount infisical-token-requester -p '{"secrets": [{"name": "infisical-token-requester-token"}]}' -n default
|
||||
```
|
||||
|
||||
4. Retrieve the token:
|
||||
|
||||
```bash
|
||||
kubectl get secret infisical-token-requester-token -n default -o=jsonpath='{.data.token}' | base64 --decode
|
||||
```
|
||||
|
||||
This token will be used as the "Cluster Token" in the dynamic secret configuration.
|
||||
|
||||
## Obtaining the Cluster URL
|
||||
|
||||
The cluster URL is the address of your Kubernetes API server. The simplest way to find it is to use the `kubectl cluster-info` command:
|
||||
|
||||
```bash
|
||||
kubectl cluster-info
|
||||
```
|
||||
|
||||
This command works for all Kubernetes environments (managed services like GKE, EKS, AKS, or self-hosted clusters) and will show you the Kubernetes control plane address, which is your cluster URL.
|
||||
|
||||
<Note>
|
||||
Make sure the cluster URL is accessible from where you're running Infisical.
|
||||
If you're using a private cluster, you'll need to configure a [Gateway](/documentation/platform/gateways/overview) to
|
||||
access it.
|
||||
</Note>
|
||||
|
||||
## Set up Dynamic Secrets with Kubernetes
|
||||
|
||||
<Steps>
|
||||
<Step title="Open Secret Overview Dashboard">
|
||||
Open the Secret Overview dashboard and select the environment in which you would like to add a dynamic secret.
|
||||
</Step>
|
||||
<Step title="Click on the 'Add Dynamic Secret' button">
|
||||
|
||||
</Step>
|
||||
<Step title="Select Kubernetes">
|
||||
|
||||
</Step>
|
||||
<Step title="Provide the inputs for dynamic secret parameters">
|
||||
<ParamField path="Secret Name" type="string" required>
|
||||
Name by which you want the secret to be referenced
|
||||
</ParamField>
|
||||
<ParamField path="Default TTL" type="string" required>
|
||||
Default time-to-live for a generated secret (it is possible to modify this value after a secret is generated)
|
||||
</ParamField>
|
||||
<ParamField path="Max TTL" type="string" required>
|
||||
Maximum time-to-live for a generated secret
|
||||
</ParamField>
|
||||
<ParamField path="Gateway" type="string">
|
||||
Select a gateway for private cluster access. If not specified, the Internet Gateway will be used.
|
||||
</ParamField>
|
||||
<ParamField path="Cluster URL" type="string" required>
|
||||
Kubernetes API server URL (e.g., https://kubernetes.default.svc)
|
||||
</ParamField>
|
||||
<ParamField path="Enable SSL" type="boolean">
|
||||
Whether to enable SSL verification for the Kubernetes API server connection.
|
||||
</ParamField>
|
||||
<ParamField path="CA" type="string">
|
||||
Custom CA certificate for the Kubernetes API server. Leave blank to use the system/public CA.
|
||||
</ParamField>
|
||||
<ParamField path="Cluster Token" type="string" required>
|
||||
Token with permissions to create service account tokens
|
||||
</ParamField>
|
||||
<ParamField path="Service Account Name" type="string" required>
|
||||
Name of the service account to generate tokens for
|
||||
</ParamField>
|
||||
<ParamField path="Namespace" type="string" required>
|
||||
Kubernetes namespace where the service account exists
|
||||
</ParamField>
|
||||
<ParamField path="Audiences" type="array">
|
||||
Optional list of audiences to include in the generated token
|
||||
</ParamField>
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Click 'Submit'">
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
</Step>
|
||||
<Step title="Generate dynamic secrets">
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand service account tokens.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Alternatively, you can initiate the creation of a new lease by selecting 'New Lease' from the dynamic secret lease list section.
|
||||
|
||||
|
||||
|
||||
|
||||
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
|
||||
|
||||
|
||||
|
||||
<Tip>
|
||||
Ensure that the TTL for the lease fall within the maximum TTL defined when configuring the dynamic secret.
|
||||
</Tip>
|
||||
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the service account token will be shown to you.
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Audit or Revoke Leases
|
||||
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
This will allow you to see the lease details and delete the lease ahead of its expiration time.
|
||||
|
||||
<Note>
|
||||
While you can delete the lease from Infisical, the actual Kubernetes service
|
||||
account token cannot be revoked. The token will remain valid until its TTL
|
||||
expires. This is why it's crucial to use appropriate TTL values when
|
||||
generating tokens.
|
||||
</Note>
|
||||
|
||||
|
||||
@@ -123,6 +123,13 @@ The Infisical LDAP dynamic secret allows you to generate user credentials on dem
|
||||
changetype: delete
|
||||
```
|
||||
</ParamField>
|
||||
<ParamField path="Username Template" type="string" default="{{randomUsername}}">
|
||||
Specifies a template for generating usernames. This field allows customization of how usernames are automatically created.
|
||||
|
||||
Allowed template variables are
|
||||
- `{{randomUsername}}`: Random username string
|
||||
- `{{unixTimestamp}}`: Current Unix timestamp
|
||||
</ParamField>
|
||||
</Step>
|
||||
|
||||
<Step title="Click `Submit`">
|
||||
|
||||
@@ -6,11 +6,10 @@ description: "Learn how to dynamically generate Mongo Atlas Database user creden
|
||||
The Infisical Mongo Atlas dynamic secret allows you to generate Mongo Atlas Database credentials on demand based on configured role.
|
||||
|
||||
## Prerequisite
|
||||
Create a project scopped API Key with the required permission in your Mongo Atlas following the [official doc](https://www.mongodb.com/docs/atlas/configure-api-access/#grant-programmatic-access-to-a-project).
|
||||
|
||||
<Info>
|
||||
The API Key must have permission to manage users in the project.
|
||||
</Info>
|
||||
Create a project scoped API Key with the required permission in your Mongo Atlas following the [official doc](https://www.mongodb.com/docs/atlas/configure-api-access/#grant-programmatic-access-to-a-project).
|
||||
|
||||
<Info>The API Key must have permission to manage users in the project.</Info>
|
||||
|
||||
## Set up Dynamic Secrets with Mongo Atlas
|
||||
|
||||
@@ -29,86 +28,104 @@ Create a project scopped API Key with the required permission in your Mongo Atla
|
||||
Name by which you want the secret to be referenced
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Default TTL" type="string" required>
|
||||
Default time-to-live for a generated secret (it is possible to modify this value after a secret is generated)
|
||||
</ParamField>
|
||||
<ParamField path="Default TTL" type="string" required>
|
||||
Default time-to-live for a generated secret (it is possible to modify this value after a secret is generated)
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Max TTL" type="string" required>
|
||||
Maximum time-to-live for a generated secret
|
||||
</ParamField>
|
||||
<ParamField path="Max TTL" type="string" required>
|
||||
Maximum time-to-live for a generated secret
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Admin public key" type="string" required>
|
||||
The public key of your generated Atlas API Key. This acts as a username.
|
||||
</ParamField>
|
||||
<ParamField path="Admin public key" type="string" required>
|
||||
The public key of your generated Atlas API Key. This acts as a username.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Admin private key" type="string" required>
|
||||
The private key of your generated Atlas API Key. This acts as a password.
|
||||
</ParamField>
|
||||
<ParamField path="Admin private key" type="string" required>
|
||||
The private key of your generated Atlas API Key. This acts as a password.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Group ID" type="number" required>
|
||||
Unique 24-hexadecimal digit string that identifies your project. This is same as project id
|
||||
</ParamField>
|
||||
<ParamField path="Group ID" type="number" required>
|
||||
Unique 24-hexadecimal digit string that identifies your project. This is same as project id
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Roles" type="string" required>
|
||||
List that provides the pairings of one role with one applicable database.
|
||||
- **Database Name**: Database to which the user is granted access privileges.
|
||||
- **Collection**: Collection on which this role applies.
|
||||
- **Role Name**: Human-readable label that identifies a group of privileges assigned to a database user. This value can either be a built-in role or a custom role.
|
||||
- Enum: `atlasAdmin` `backup` `clusterMonitor` `dbAdmin` `dbAdminAnyDatabase` `enableSharding` `read` `readAnyDatabase` `readWrite` `readWriteAnyDatabase` `<a custom role name>`.
|
||||
</ParamField>
|
||||
<ParamField path="Roles" type="string" required>
|
||||
List that provides the pairings of one role with one applicable database.
|
||||
- **Database Name**: Database to which the user is granted access privileges.
|
||||
- **Collection**: Collection on which this role applies.
|
||||
- **Role Name**: Human-readable label that identifies a group of privileges assigned to a database user. This value can either be a built-in role or a custom role.
|
||||
- Enum: `atlasAdmin` `backup` `clusterMonitor` `dbAdmin` `dbAdminAnyDatabase` `enableSharding` `read` `readAnyDatabase` `readWrite` `readWriteAnyDatabase` `<a custom role name>`.
|
||||
</ParamField>
|
||||
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="(Optional) Modify Access Scope">
|
||||
List that contains clusters, MongoDB Atlas Data Lakes, and MongoDB Atlas Streams Instances that this database user can access. If omitted, MongoDB Cloud grants the database user access to all the clusters, MongoDB Atlas Data Lakes, and MongoDB Atlas Streams Instances in the project.
|
||||
|
||||
|
||||
- **Label**: Human-readable label that identifies the cluster or MongoDB Atlas Data Lake that this database user can access.
|
||||
- **Type**: Category of resource that this database user can access.
|
||||
|
||||
|
||||
<ParamField path="Username Template" type="string" default="{{randomUsername}}">
|
||||
Specifies a template for generating usernames. This field allows customization of how usernames are automatically created.
|
||||
|
||||
Allowed template variables are
|
||||
- `{{randomUsername}}`: Random username string
|
||||
- `{{unixTimestamp}}`: Current Unix timestamp
|
||||
</ParamField>
|
||||
<ParamField path="Customize Scope" type="string">
|
||||
|
||||
List that contains clusters, MongoDB Atlas Data Lakes, and MongoDB Atlas Streams Instances that this database user can access. If omitted, MongoDB Cloud grants the database user access to all the clusters, MongoDB Atlas Data Lakes, and MongoDB Atlas Streams Instances in the project.
|
||||
- **Label**: Human-readable label that identifies the cluster or MongoDB Atlas Data Lake that this database user can access.
|
||||
- **Type**: Category of resource that this database user can access.
|
||||
|
||||
</ParamField>
|
||||
</Step>
|
||||
|
||||
<Step title="Click 'Submit'">
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
|
||||
<Note>
|
||||
If this step fails, you may have to add the CA certficate.
|
||||
</Note>
|
||||
<Note>
|
||||
If this step fails, you may have to add the CA certificate.
|
||||
</Note>
|
||||
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Generate dynamic secrets">
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Alternatively, you can initiate the creation of a new lease by selecting 'New Lease' from the dynamic secret lease list section.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
|
||||
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
|
||||
|
||||
|
||||
|
||||
|
||||
<Tip>
|
||||
Ensure that the TTL for the lease fall within the maximum TTL defined when configuring the dynamic secret.
|
||||
</Tip>
|
||||
<Tip>
|
||||
Ensure that the TTL for the lease falls within the maximum TTL defined when configuring the dynamic secret.
|
||||
</Tip>
|
||||
|
||||
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials for it will be shown to you.
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials for it will be shown to you.
|
||||
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Audit or Revoke Leases
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
This will allow you to see the expiration time of the lease or delete a lease before it's set time to live.
|
||||
|
||||
|
||||
|
||||
## Renew Leases
|
||||
|
||||
To extend the life of the generated dynamic secret leases past its initial time to live, simply click on the **Renew** button as illustrated below.
|
||||
|
||||
|
||||
<Warning>
|
||||
Lease renewals cannot exceed the maximum TTL set when configuring the dynamic secret
|
||||
Lease renewals cannot exceed the maximum TTL set when configuring the dynamic
|
||||
secret
|
||||
</Warning>
|
||||
|
||||
@@ -62,25 +62,32 @@ Create a user with the required permission in your MongoDB instance. This user w
|
||||
Human-readable label that identifies a group of privileges assigned to a database user. This value can either be a built-in role or a custom role.
|
||||
- Enum: `atlasAdmin` `backup` `clusterMonitor` `dbAdmin` `dbAdminAnyDatabase` `enableSharding` `read` `readAnyDatabase` `readWrite` `readWriteAnyDatabase` `<a custom role name>`.
|
||||
</ParamField>
|
||||
|
||||
|
||||
<ParamField path="CA(SSL)" type="string">
|
||||
A CA may be required if your DB requires it for incoming connections.
|
||||
</ParamField>
|
||||
<ParamField path="Username Template" type="string" default="{{randomUsername}}">
|
||||
Specifies a template for generating usernames. This field allows customization of how usernames are automatically created.
|
||||
|
||||
Allowed template variables are
|
||||
- `{{randomUsername}}`: Random username string
|
||||
- `{{unixTimestamp}}`: Current Unix timestamp
|
||||
</ParamField>
|
||||
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Click `Submit`">
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
|
||||
<Note>
|
||||
If this step fails, you may have to add the CA certificate.
|
||||
If this step fails, you may have to add the CA certificate.
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
<Step title="Generate dynamic secrets">
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Alternatively, you can initiate the creation of a new lease by selecting 'New Lease' from the dynamic secret lease list section.
|
||||
|
||||
|
||||
@@ -95,14 +102,14 @@ Create a user with the required permission in your MongoDB instance. This user w
|
||||
</Tip>
|
||||
|
||||
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials from it will be shown to you.
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials from it will be shown to you.
|
||||
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Audit or Revoke Leases
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
This will allow you to see the expiration time of the lease or delete a lease before it's set time to live.
|
||||
|
||||
|
||||
|
||||
@@ -62,7 +62,7 @@ Create a user with the required permission in your SQL instance. This user will
|
||||
<ParamField path="Database Name" type="string" required>
|
||||
Name of the database for which you want to create dynamic secrets
|
||||
</ParamField>
|
||||
|
||||
|
||||
<ParamField path="CA(SSL)" type="string">
|
||||
A CA may be required if your DB requires it for incoming connections. AWS RDS instances with default settings will requires a CA which can be downloaded [here](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html#UsingWithRDS.SSL.CertificatesAllRegions).
|
||||
</ParamField>
|
||||
@@ -71,22 +71,30 @@ Create a user with the required permission in your SQL instance. This user will
|
||||
|
||||
</Step>
|
||||
<Step title="(Optional) Modify SQL Statements">
|
||||
If you want to provide specific privileges for the generated dynamic credentials, you can modify the SQL statement to your needs. This is useful if you want to only give access to a specific table(s).
|
||||
|
||||
<ParamField path="Username Template" type="string" default="{{randomUsername}}">
|
||||
Specifies a template for generating usernames. This field allows customization of how usernames are automatically created.
|
||||
|
||||
|
||||
Allowed template variables are
|
||||
- `{{randomUsername}}`: Random username string
|
||||
- `{{unixTimestamp}}`: Current Unix timestamp
|
||||
</ParamField>
|
||||
<ParamField path="Customize SQL Statement" type="string">
|
||||
If you want to provide specific privileges for the generated dynamic credentials, you can modify the SQL statement to your needs. This is useful if you want to only give access to a specific table(s).
|
||||
</ParamField>
|
||||
</Step>
|
||||
<Step title="Click 'Submit'">
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
|
||||
<Note>
|
||||
If this step fails, you may have to add the CA certficate.
|
||||
If this step fails, you may have to add the CA certificate.
|
||||
</Note>
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Generate dynamic secrets">
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Alternatively, you can initiate the creation of a new lease by selecting 'New Lease' from the dynamic secret lease list section.
|
||||
|
||||
|
||||
@@ -101,14 +109,14 @@ Create a user with the required permission in your SQL instance. This user will
|
||||
</Tip>
|
||||
|
||||
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials for it will be shown to you.
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials for it will be shown to you.
|
||||
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Audit or Revoke Leases
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
This will allow you to see the expiration time of the lease or delete the lease before it's set time to live.
|
||||
|
||||
|
||||
|
||||
@@ -61,29 +61,37 @@ Create a user with the required permission in your SQL instance. This user will
|
||||
<ParamField path="Database Name" type="string" required>
|
||||
Name of the database for which you want to create dynamic secrets
|
||||
</ParamField>
|
||||
|
||||
|
||||
<ParamField path="CA(SSL)" type="string">
|
||||
A CA may be required if your DB requires it for incoming connections. AWS RDS instances with default settings will requires a CA which can be downloaded [here](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html#UsingWithRDS.SSL.CertificatesAllRegions).
|
||||
</ParamField>
|
||||
|
||||
</Step>
|
||||
<Step title="(Optional) Modify SQL Statements">
|
||||
If you want to provide specific privileges for the generated dynamic credentials, you can modify the SQL statement to your needs. This is useful if you want to only give access to a specific table(s).
|
||||
|
||||
<ParamField path="Username Template" type="string" default="{{randomUsername}}">
|
||||
Specifies a template for generating usernames. This field allows customization of how usernames are automatically created.
|
||||
|
||||
|
||||
Allowed template variables are
|
||||
- `{{randomUsername}}`: Random username string
|
||||
- `{{unixTimestamp}}`: Current Unix timestamp
|
||||
</ParamField>
|
||||
<ParamField path="Customize SQL Statement" type="string">
|
||||
If you want to provide specific privileges for the generated dynamic credentials, you can modify the SQL statement to your needs. This is useful if you want to only give access to a specific table(s).
|
||||
</ParamField>
|
||||
</Step>
|
||||
<Step title="Click `Submit`">
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
|
||||
<Note>
|
||||
If this step fails, you may have to add the CA certificate.
|
||||
If this step fails, you may have to add the CA certificate.
|
||||
</Note>
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Generate dynamic secrets">
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Alternatively, you can initiate the creation of a new lease by selecting 'New Lease' from the dynamic secret lease list section.
|
||||
|
||||
|
||||
@@ -98,14 +106,14 @@ Create a user with the required permission in your SQL instance. This user will
|
||||
</Tip>
|
||||
|
||||
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials from it will be shown to you.
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials from it will be shown to you.
|
||||
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Audit or Revoke Leases
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
This will allow you to see the expiration time of the lease or delete a lease before it's set time to live.
|
||||
|
||||
|
||||
@@ -116,4 +124,4 @@ To extend the life of the generated dynamic secret leases past its initial time
|
||||
|
||||
<Warning>
|
||||
Lease renewals cannot exceed the maximum TTL set when configuring the dynamic secret
|
||||
</Warning>
|
||||
</Warning>
|
||||
|
||||
@@ -61,7 +61,7 @@ Create a user with the required permission in your SQL instance. This user will
|
||||
<ParamField path="Database Name" type="string" required>
|
||||
Name of the database for which you want to create dynamic secrets
|
||||
</ParamField>
|
||||
|
||||
|
||||
<ParamField path="CA(SSL)" type="string">
|
||||
A CA may be required if your DB requires it for incoming connections. AWS RDS instances with default settings will requires a CA which can be downloaded [here](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html#UsingWithRDS.SSL.CertificatesAllRegions).
|
||||
</ParamField>
|
||||
@@ -70,20 +70,30 @@ Create a user with the required permission in your SQL instance. This user will
|
||||
|
||||
</Step>
|
||||
<Step title="(Optional) Modify SQL Statements">
|
||||
|
||||
<ParamField path="Username Template" type="string" default="{{randomUsername}}">
|
||||
Specifies a template for generating usernames. This field allows customization of how usernames are automatically created.
|
||||
|
||||
Allowed template variables are
|
||||
- `{{randomUsername}}`: Random username string
|
||||
- `{{unixTimestamp}}`: Current Unix timestamp
|
||||
</ParamField>
|
||||
<ParamField path="Customize SQL Statement" type="string">
|
||||
If you want to provide specific privileges for the generated dynamic credentials, you can modify the SQL statement to your needs. This is useful if you want to only give access to a specific table(s).
|
||||
</ParamField>
|
||||
</Step>
|
||||
<Step title="Click 'Submit'">
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
|
||||
<Note>
|
||||
If this step fails, you may have to add the CA certficate.
|
||||
If this step fails, you may have to add the CA certificate.
|
||||
</Note>
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Generate dynamic secrets">
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Alternatively, you can initiate the creation of a new lease by selecting 'New Lease' from the dynamic secret lease list section.
|
||||
|
||||
|
||||
@@ -98,14 +108,14 @@ Create a user with the required permission in your SQL instance. This user will
|
||||
</Tip>
|
||||
|
||||
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials for it will be shown to you.
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials for it will be shown to you.
|
||||
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Audit or Revoke Leases
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
This will allow you to see the expiration time of the lease or delete a lease before it's set time to live.
|
||||
|
||||
|
||||
@@ -116,4 +126,4 @@ To extend the life of the generated dynamic secret leases past its initial time
|
||||
|
||||
<Warning>
|
||||
Lease renewals cannot exceed the maximum TTL set when configuring the dynamic secret
|
||||
</Warning>
|
||||
</Warning>
|
||||
|
||||
@@ -62,7 +62,7 @@ Create a user with the required permission in your SQL instance. This user will
|
||||
<ParamField path="Database Name" type="string" required>
|
||||
Name of the database for which you want to create dynamic secrets
|
||||
</ParamField>
|
||||
|
||||
|
||||
<ParamField path="CA(SSL)" type="string">
|
||||
A CA may be required if your DB requires it for incoming connections. AWS RDS instances with default settings will requires a CA which can be downloaded [here](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html#UsingWithRDS.SSL.CertificatesAllRegions).
|
||||
</ParamField>
|
||||
@@ -71,22 +71,30 @@ Create a user with the required permission in your SQL instance. This user will
|
||||
|
||||
</Step>
|
||||
<Step title="(Optional) Modify SQL Statements">
|
||||
If you want to provide specific privileges for the generated dynamic credentials, you can modify the SQL statement to your needs. This is useful if you want to only give access to a specific table(s).
|
||||
|
||||
|
||||
<ParamField path="Username Template" type="string" default="{{randomUsername}}">
|
||||
Specifies a template for generating usernames. This field allows customization of how usernames are automatically created.
|
||||
|
||||
Allowed template variables are
|
||||
- `{{randomUsername}}`: Random username string
|
||||
- `{{unixTimestamp}}`: Current Unix timestamp
|
||||
</ParamField>
|
||||
<ParamField path="Customize SQL Statement" type="string">
|
||||
If you want to provide specific privileges for the generated dynamic credentials, you can modify the SQL statement to your needs. This is useful if you want to only give access to a specific table(s).
|
||||
</ParamField>
|
||||
</Step>
|
||||
<Step title="Click 'Submit'">
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
|
||||
<Note>
|
||||
If this step fails, you may have to add the CA certficate.
|
||||
If this step fails, you may have to add the CA certificate.
|
||||
</Note>
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Generate dynamic secrets">
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Alternatively, you can initiate the creation of a new lease by selecting 'New Lease' from the dynamic secret lease list section.
|
||||
|
||||
|
||||
@@ -101,14 +109,14 @@ Create a user with the required permission in your SQL instance. This user will
|
||||
</Tip>
|
||||
|
||||
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials for it will be shown to you.
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials for it will be shown to you.
|
||||
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Audit or Revoke Leases
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
This will allow you to see the expiration time of the lease or delete the lease before it's set time to live.
|
||||
|
||||
|
||||
|
||||
@@ -9,7 +9,6 @@ The Infisical RabbitMQ dynamic secret allows you to generate RabbitMQ credential
|
||||
|
||||
1. Ensure that the `management` plugin is enabled on your RabbitMQ instance. This is required for the dynamic secret to work.
|
||||
|
||||
|
||||
## Set up Dynamic Secrets with RabbitMQ
|
||||
|
||||
<Steps>
|
||||
@@ -19,98 +18,113 @@ The Infisical RabbitMQ dynamic secret allows you to generate RabbitMQ credential
|
||||
<Step title="Click on the 'Add Dynamic Secret' button">
|
||||
|
||||
</Step>
|
||||
<Step title="Select 'RabbitMQ'">
|
||||
|
||||
<Step title="Select RabbitMQ">
|
||||
|
||||
</Step>
|
||||
<Step title="Provide the inputs for dynamic secret parameters">
|
||||
<ParamField path="Secret Name" type="string" required>
|
||||
Name by which you want the secret to be referenced
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Default TTL" type="string" required>
|
||||
Default time-to-live for a generated secret (it is possible to modify this value after a secret is generated)
|
||||
</ParamField>
|
||||
<ParamField path="Default TTL" type="string" required>
|
||||
Default time-to-live for a generated secret (it is possible to modify this value after a secret is generated)
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Max TTL" type="string" required>
|
||||
Maximum time-to-live for a generated secret.
|
||||
</ParamField>
|
||||
<ParamField path="Max TTL" type="string" required>
|
||||
Maximum time-to-live for a generated secret.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Host" type="string" required>
|
||||
<ParamField path="Host" type="string" required>
|
||||
Your RabbitMQ host. This must be in HTTP format. _(Example: http://your-cluster-ip)_
|
||||
</ParamField>
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Port" type="string" required>
|
||||
The port that the RabbitMQ management plugin is listening on. This is `15672` by default.
|
||||
</ParamField>
|
||||
<ParamField path="Port" type="string" required>
|
||||
|
||||
<ParamField path="Virtual host name" type="string" required>
|
||||
The name of the virtual host that the user will be assigned to. This defaults to `/`.
|
||||
</ParamField>
|
||||
The port that the RabbitMQ management plugin is listening on. This is `15672` by default.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Virtual host name" type="string" required>
|
||||
The name of the virtual host that the user will be assigned to. This defaults
|
||||
to `/`.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Virtual host permissions (Read/Write/Configure)" type="string" required>
|
||||
The permissions that the user will have on the virtual host. This defaults to `.*`.
|
||||
|
||||
The three permission fields all take a regular expression _(regex)_, that should match resource names for which the user is granted read / write / configuration permissions
|
||||
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Username" type="string" required>
|
||||
The username of the user that will be used to provision new dynamic secret
|
||||
leases.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Username" type="string" required>
|
||||
The username of the user that will be used to provision new dynamic secret leases.
|
||||
</ParamField>
|
||||
<ParamField path="Password" type="string" required>
|
||||
The password of the user that will be used to provision new dynamic secret
|
||||
leases.
|
||||
</ParamField>
|
||||
|
||||
<ParamField path="Password" type="string" required>
|
||||
The password of the user that will be used to provision new dynamic secret leases.
|
||||
</ParamField>
|
||||
<ParamField path="Username Template" type="string" default="{{randomUsername}}">
|
||||
Specifies a template for generating usernames. This field allows customization of how usernames are automatically created.
|
||||
|
||||
<ParamField path="CA(SSL)" type="string">
|
||||
A CA may be required if your DB requires it for incoming connections. This is often the case when connecting to a managed service.
|
||||
</ParamField>
|
||||
Allowed template variables are
|
||||
- `{{randomUsername}}`: Random username string
|
||||
- `{{unixTimestamp}}`: Current Unix timestamp
|
||||
</ParamField>
|
||||
|
||||
|
||||
<ParamField path="CA(SSL)" type="string">
|
||||
A CA may be required if your DB requires it for incoming connections. This is often the case when connecting to a managed service.
|
||||
</ParamField>
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Click `Submit`">
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
|
||||
<Note>
|
||||
If this step fails, you may have to add the CA certificate.
|
||||
</Note>
|
||||
<Note>
|
||||
If this step fails, you may have to add the CA certificate.
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
<Step title="Generate dynamic secrets">
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Alternatively, you can initiate the creation of a new lease by selecting 'New Lease' from the dynamic secret lease list section.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
|
||||
When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.
|
||||
|
||||
|
||||
|
||||
|
||||
<Tip>
|
||||
Ensure that the TTL for the lease fall within the maximum TTL defined when configuring the dynamic secret.
|
||||
</Tip>
|
||||
<Tip>
|
||||
Ensure that the TTL for the lease fall within the maximum TTL defined when configuring the dynamic secret.
|
||||
</Tip>
|
||||
|
||||
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials from it will be shown to you.
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials from it will be shown to you.
|
||||
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Audit or Revoke Leases
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
This will allow you to see the expiration time of the lease or delete a lease before it's set time to live.
|
||||
|
||||
|
||||
|
||||
## Renew Leases
|
||||
|
||||
To extend the life of the generated dynamic secret leases past its initial time to live, simply click on the **Renew** button as illustrated below.
|
||||
|
||||
|
||||
<Warning>
|
||||
Lease renewals cannot exceed the maximum TTL set when configuring the dynamic secret
|
||||
Lease renewals cannot exceed the maximum TTL set when configuring the dynamic
|
||||
secret
|
||||
</Warning>
|
||||
|
||||
@@ -56,21 +56,29 @@ Create a user with the required permission in your Redis instance. This user wil
|
||||
|
||||
</Step>
|
||||
<Step title="(Optional) Modify Redis Statements">
|
||||
If you want to provide specific privileges for the generated dynamic credentials, you can modify the Redis statement to your needs. This is useful if you want to only give access to a specific table(s).
|
||||
|
||||
<ParamField path="Username Template" type="string" default="{{randomUsername}}">
|
||||
Specifies a template for generating usernames. This field allows customization of how usernames are automatically created.
|
||||
|
||||
|
||||
Allowed template variables are
|
||||
- `{{randomUsername}}`: Random username string
|
||||
- `{{unixTimestamp}}`: Current Unix timestamp
|
||||
</ParamField>
|
||||
<ParamField path="Customize Redis Statement" type="string">
|
||||
If you want to provide specific privileges for the generated dynamic credentials, you can modify the Redis statement to your needs. This is useful if you want to only give access to a specific table(s).
|
||||
</ParamField>
|
||||
</Step>
|
||||
<Step title="Click `Submit`">
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
|
||||
<Note>
|
||||
If this step fails, you may have to add the CA certificate.
|
||||
If this step fails, you may have to add the CA certificate.
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
<Step title="Generate dynamic secrets">
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Alternatively, you can initiate the creation of a new lease by selecting 'New Lease' from the dynamic secret lease list section.
|
||||
|
||||
|
||||
@@ -85,14 +93,14 @@ Create a user with the required permission in your Redis instance. This user wil
|
||||
</Tip>
|
||||
|
||||
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials from it will be shown to you.
|
||||
Once you click the `Submit` button, a new secret lease will be generated and the credentials from it will be shown to you.
|
||||
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Audit or Revoke Leases
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
Once you have created one or more leases, you will be able to access them by clicking on the respective dynamic secret item on the dashboard.
|
||||
This will allow you to see the expiration time of the lease or delete a lease before it's set time to live.
|
||||
|
||||
|
||||
@@ -103,4 +111,4 @@ To extend the life of the generated dynamic secret leases past its initial time
|
||||
|
||||
<Warning>
|
||||
Lease renewals cannot exceed the maximum TTL set when configuring the dynamic secret
|
||||
</Warning>
|
||||
</Warning>
|
||||
|
||||
@@ -62,21 +62,30 @@ The Infisical SAP ASE dynamic secret allows you to generate SAP ASE database cre
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="(Optional) Modify SQL Statements">
|
||||
If you want to provide specific privileges for the generated dynamic credentials, you can modify the SQL statement to your needs.
|
||||
<Step title="(Optional) Modify SAP SQL Statements">
|
||||
|
||||
<ParamField path="Username Template" type="string" default="{{randomUsername}}">
|
||||
Specifies a template for generating usernames. This field allows customization of how usernames are automatically created.
|
||||
|
||||
<Warning>
|
||||
Due to SAP ASE limitations, the attached SQL statements are not executed as a transaction.
|
||||
</Warning>
|
||||
Allowed template variables are
|
||||
- `{{randomUsername}}`: Random username string
|
||||
- `{{unixTimestamp}}`: Current Unix timestamp
|
||||
</ParamField>
|
||||
<ParamField path="Customize Statement" type="string">
|
||||
|
||||
If you want to provide specific privileges for the generated dynamic credentials, you can modify the SQL statement to your needs.
|
||||
<Warning>
|
||||
Due to SAP ASE limitations, the attached SQL statements are not executed as a transaction.
|
||||
</Warning>
|
||||
</ParamField>
|
||||
|
||||
</Step>
|
||||
<Step title="Click 'Submit'">
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
</Step>
|
||||
<Step title="Generate dynamic secrets">
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Alternatively, you can initiate the creation of a new lease by selecting 'New Lease' from the dynamic secret lease list section.
|
||||
|
||||
|
||||
|
||||
@@ -62,14 +62,25 @@ The Infisical SAP HANA dynamic secret allows you to generate SAP HANA database c
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="(Optional) Modify SQL Statements">
|
||||
If you want to provide specific privileges for the generated dynamic credentials, you can modify the SQL statement to your needs.
|
||||
|
||||
<Step title="(Optional) Modify SAP SQL Statements">
|
||||
|
||||
<ParamField path="Username Template" type="string" default="{{randomUsername}}">
|
||||
Specifies a template for generating usernames. This field allows customization of how usernames are automatically created.
|
||||
|
||||
Allowed template variables are
|
||||
- `{{randomUsername}}`: Random username string
|
||||
- `{{unixTimestamp}}`: Current Unix timestamp
|
||||
</ParamField>
|
||||
<ParamField path="Customize Statement" type="string">
|
||||
|
||||
If you want to provide specific privileges for the generated dynamic credentials, you can modify the SQL statement to your needs.
|
||||
|
||||
<Warning>
|
||||
Due to SAP HANA limitations, the attached SQL statements are not executed as a transaction.
|
||||
</Warning>
|
||||
|
||||
</ParamField>
|
||||
|
||||
</Step>
|
||||
<Step title="Click 'Submit'">
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
@@ -80,8 +91,8 @@ The Infisical SAP HANA dynamic secret allows you to generate SAP HANA database c
|
||||
|
||||
</Step>
|
||||
<Step title="Generate dynamic secrets">
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials.
|
||||
To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item.
|
||||
Alternatively, you can initiate the creation of a new lease by selecting 'New Lease' from the dynamic secret lease list section.
|
||||
|
||||
|
||||
|
||||
@@ -8,22 +8,27 @@ Infisical's Snowflake dynamic secrets allow you to generate Snowflake user crede
|
||||
## Snowflake Prerequisites
|
||||
|
||||
<Note>
|
||||
Infisical requires a Snowflake user in your account with the USERADMIN role. This user will act as a service account for Infisical and facilitate the creation of new users as needed.
|
||||
Infisical requires a Snowflake user in your account with the USERADMIN role.
|
||||
This user will act as a service account for Infisical and facilitate the
|
||||
creation of new users as needed.
|
||||
</Note>
|
||||
|
||||
<Steps>
|
||||
<Step title="Navigate to Snowflake's User Dashboard and press the '+ User' button">
|
||||
|
||||
</Step>
|
||||
<Step title="Create a Snowflake user with the USERADMIN role for Infisical">
|
||||
<Warning>
|
||||
Be sure to uncheck "Force user to change password on first time login"
|
||||
</Warning>
|
||||
|
||||
</Step>
|
||||
<Step title="Click on the Account Menu in the bottom left and take note of your Account and Organization identifiers">
|
||||
|
||||
</Step>
|
||||
<Step title="Navigate to Snowflake's User Dashboard and press the '+ User' button">
|
||||
|
||||
</Step>
|
||||
<Step title="Create a Snowflake user with the USERADMIN role for Infisical">
|
||||
<Warning>
|
||||
Be sure to uncheck "Force user to change password on first time login"
|
||||
</Warning>
|
||||
|
||||
</Step>
|
||||
<Step title="Click on the Account Menu in the bottom left and take note of your Account and Organization identifiers">
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Set up Dynamic Secrets with Snowflake
|
||||
@@ -71,10 +76,23 @@ Infisical's Snowflake dynamic secrets allow you to generate Snowflake user crede
|
||||
|
||||
</Step>
|
||||
<Step title="(Optional) Modify SQL Statements">
|
||||
If you want to provide specific privileges for the generated dynamic credentials, you can modify the SQL
|
||||
statement to your needs.
|
||||
|
||||
</Step>
|
||||
<ParamField path="Username Template" type="string" default="{{randomUsername}}">
|
||||
Specifies a template for generating usernames. This field allows customization of how usernames are automatically created.
|
||||
|
||||
Allowed template variables are
|
||||
- `{{randomUsername}}`: Random username string
|
||||
- `{{unixTimestamp}}`: Current Unix timestamp
|
||||
</ParamField>
|
||||
<ParamField path="Customize Statement" type="string">
|
||||
|
||||
If you want to provide specific privileges for the generated dynamic credentials, you can modify the SQL
|
||||
statement to your needs.
|
||||
|
||||
</ParamField>
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Click 'Submit'">
|
||||
After submitting the form, you will see a dynamic secret created in the dashboard.
|
||||
</Step>
|
||||
@@ -104,6 +122,7 @@ Infisical's Snowflake dynamic secrets allow you to generate Snowflake user crede
|
||||
|
||||
|
||||
</Step>
|
||||
|
||||
</Steps>
|
||||
|
||||
## Audit or Revoke Leases
|
||||
@@ -119,6 +138,6 @@ To extend the life of the generated dynamic secret lease past its initial time t
|
||||
|
||||
|
||||
<Warning>
|
||||
Lease renewals cannot exceed the maximum TTL set when configuring the dynamic
|
||||
secret.
|
||||
Lease renewals cannot exceed the maximum TTL set when configuring the dynamic
|
||||
secret.
|
||||
</Warning>
|
||||
|
||||
@@ -4,6 +4,7 @@ description: "Learn how to authenticate to Infisical from any platform or enviro
|
||||
---
|
||||
|
||||
**Universal Auth** is a platform-agnostic authentication method that can be configured for a [machine identity](/documentation/platform/identities/machine-identities) to authenticate from any platform/environment using a Client ID and Client Secret.
|
||||
This authentication method supports setting token periods, which can help [overcome secret zero](#solving-secret-zero-with-periodic-tokens).
|
||||
|
||||
## Diagram
|
||||
|
||||
@@ -64,7 +65,8 @@ using the Universal Auth authentication method.
|
||||
By default, the identity has been configured with Universal Auth. If you wish, you can edit the Universal Auth configuration
|
||||
details by pressing to edit the **Authentication** section.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Here's some more guidance on each field:
|
||||
|
||||
@@ -73,11 +75,12 @@ using the Universal Auth authentication method.
|
||||
- Access Token Max Number of Uses (default is `0`): The maximum number of times that an access token can be used; a value of `0` implies infinite number of uses.
|
||||
- Client Secret Trusted IPs: The IPs or CIDR ranges that the **Client Secret** can be used from together with the **Client ID** to get back an access token. By default, **Client Secrets** are given the `0.0.0.0/0`, allowing usage from any network address.
|
||||
- Access Token Trusted IPs: The IPs or CIDR ranges that access tokens can be used from. By default, each token is given the `0.0.0.0/0`, allowing usage from any network address.
|
||||
- Access Token Period (optional, default is `0`): If set, the access token becomes a renewable, non-expiring token for the specified period (in seconds). TTL and Max TTL are ignored when this is set. This is ideal for "secret zero" scenarios, where a workload needs to bootstrap itself securely without hard-coded static secrets.
|
||||
|
||||
<Warning>
|
||||
Restricting **Client Secret** and access token usage to specific trusted IPs is a paid feature.
|
||||
|
||||
If you’re using Infisical Cloud, then it is available under the Pro Tier. If you’re self-hosting Infisical, then you should contact sales@infisical.com to purchase an enterprise license to use it.
|
||||
If you're using Infisical Cloud, then it is available under the Pro Tier. If you're self-hosting Infisical, then you should contact sales@infisical.com to purchase an enterprise license to use it.
|
||||
</Warning>
|
||||
|
||||
</Step>
|
||||
@@ -96,6 +99,7 @@ using the Universal Auth authentication method.
|
||||
- Description: A description for the **Client Secret**.
|
||||
- TTL (default is `0`): The time-to-live for the **Client Secret**. By default, the TTL will be set to 0 which implies that the **Client Secret** will never expire; a value of `0` implies an infinite lifetime.
|
||||
- Max Number of Uses (default is `0`): The maximum number of times that the **Client Secret** can be used together with the **Client ID** to get back an access token; a value of `0` implies infinite number of uses.
|
||||
|
||||
</Step>
|
||||
<Step title="Adding an identity to a project">
|
||||
To enable the identity to access project-level resources such as secrets within a specific project, you should add it to that project.
|
||||
@@ -154,23 +158,50 @@ using the Universal Auth authentication method.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Solving Secret Zero with Periodic Tokens
|
||||
|
||||
In many automated, cloud-native, or ephemeral environments (such as VMs, containers, or serverless functions), it is often unsafe or impractical to hard-code long-lived credentials for bootstrapping access to secrets management systems. The "secret zero" problem refers to the challenge of securely providing a workload with its initial credential, without manual intervention or static secrets that could be leaked or reused. Periodic tokens in Universal Auth are designed to solve this problem by enabling secure, automated bootstrapping and ongoing access renewal, even in dynamic or short-lived environments.
|
||||
|
||||
A common challenge in cloud-native and automated environments is the "secret zero" problem: how to securely bootstrap a workload (such as a VM, container, or serverless function) with its first credential, without hard-coding static secrets or requiring manual intervention.
|
||||
|
||||
**Periodic tokens** in Universal Auth solve this by allowing you to issue an access token that can be continuously renewed by your workload before it expires (i.e., a client-initiated rotation mechanism):
|
||||
|
||||
- When you set the **Access Token Period** in the Universal Auth configuration, the issued access token can be renewed by your workload for the specified period (in seconds).
|
||||
- The token can be renewed any number of times, each time for the same period, with no maximum lifetime (unless you set a use limit).
|
||||
- As long as the token is renewed before its period expires, it remains valid, so you do not need to re-issue static credentials.
|
||||
- TTL and Max TTL are ignored when Access Token Period is set.
|
||||
|
||||
### Example: Bootstrapping with a Periodic Token
|
||||
|
||||
1. Configure Universal Auth for your identity and set **Access Token Period** (e.g., `3600` for 1 hour).
|
||||
2. For improved security, configure the Client Secret with a low number of uses (e.g., `1`) or a short TTL. This ensures that after the initial login, the Client Secret cannot be reused, and any disruption in token renewal will require manual intervention.
|
||||
3. Deploy your workload with the **Client Secret** and **Client ID**.
|
||||
4. The workload authenticates with Infisical using the Client Secret and Client ID to obtain the initial access token (JWT).
|
||||
5. The workload uses the access token to authenticate and continuously renews it before expiration:
|
||||
|
||||
```bash
|
||||
curl --location --request POST 'https://app.infisical.com/api/v1/auth/universal-auth/renew' \
|
||||
--header 'Authorization: Bearer <accessToken>'
|
||||
```
|
||||
|
||||
This approach allows your workload to securely bootstrap and maintain access to Infisical without hard-coded secrets, solving the secret zero problem.
|
||||
|
||||
**FAQ**
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Why is the Infisical API rejecting my identity credentials?">
|
||||
There are a few reasons for why this might happen:
|
||||
<Accordion title="Why is the Infisical API rejecting my identity credentials?">
|
||||
There are a few reasons for why this might happen:
|
||||
- The client secret or access token has expired.
|
||||
- The identity is insufficiently permissioned to interact with the resources you wish to access.
|
||||
- The client secret/access token is being used from an untrusted IP.
|
||||
</Accordion>
|
||||
<Accordion title="What is access token renewal and TTL/Max TTL?">
|
||||
A identity access token can have a time-to-live (TTL) or incremental lifetime after which it expires.
|
||||
|
||||
- The client secret or access token has expired.
|
||||
- The identity is insufficiently permissioned to interact with the resources you wish to access.
|
||||
- The client secret/access token is being used from an untrusted IP.
|
||||
</Accordion>
|
||||
<Accordion title="What is access token renewal and TTL/Max TTL?">
|
||||
A identity access token can have a time-to-live (TTL) or incremental lifetime after which it expires.
|
||||
In certain cases, you may want to extend the lifespan of an access token; to do so, you must set a max TTL parameter.
|
||||
|
||||
In certain cases, you may want to extend the lifespan of an access token; to do so, you must set a max TTL parameter.
|
||||
A token can be renewed any number of times where each call to renew it can extend the token's lifetime by increments of the access token's TTL.
|
||||
Regardless of how frequently an access token is renewed, its lifespan remains bound to the maximum TTL determined at its creation.
|
||||
|
||||
A token can be renewed any number of times where each call to renew it can extend the token's lifetime by increments of the access token's TTL.
|
||||
Regardless of how frequently an access token is renewed, its lifespan remains bound to the maximum TTL determined at its creation.
|
||||
|
||||
</Accordion>
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
@@ -29,7 +29,6 @@ Using a hardware security module comes with the added benefit of having a secure
|
||||
|
||||
Enabling HSM encryption has a set of key benefits:
|
||||
1. **Root Key Wrapping**: The root KMS encryption key that is used to secure your Infisical instance will be encrypted using the HSM device rather than the standard software-protected key.
|
||||
2. **FIPS 140-2/3 Compliance**: Using an HSM device ensures that your Infisical instance is FIPS 140-2 or FIPS 140-3 compliant. For FIPS 140-3, ensure that your HSM is FIPS 140-3 validated.
|
||||
|
||||
#### Caveats
|
||||
- **Performance**: Using an HSM device can have a performance impact on your Infisical instance. This is due to the additional latency introduced by the HSM device. This is however only noticeable when your instance(s) start up or when the encryption strategy is changed.
|
||||
@@ -38,29 +37,22 @@ Enabling HSM encryption has a set of key benefits:
|
||||
### Requirements
|
||||
- An Infisical instance with a version number that is equal to or greater than `v0.91.0`.
|
||||
- If you are using Docker, your instance must be using the `infisical/infisical-fips` image.
|
||||
- An HSM device from a provider such as [Thales Luna HSM](https://cpl.thalesgroup.com/encryption/data-protection-on-demand/services/luna-cloud-hsm), [AWS CloudHSM](https://aws.amazon.com/cloudhsm/), or others.
|
||||
- An HSM device from a provider such as [Thales Luna HSM](https://cpl.thalesgroup.com/encryption/data-protection-on-demand/services/luna-cloud-hsm), [AWS CloudHSM](https://aws.amazon.com/cloudhsm/), [Fortanix HSM](https://www.fortanix.com/platform/data-security-manager), or others.
|
||||
|
||||
|
||||
### FIPS Compliance
|
||||
FIPS, also known as the Federal Information Processing Standard, is a set of standards that are used to accredit cryptographic modules. FIPS 140-2 and FIPS 140-3 are the two most common standards used for cryptographic modules. If your HSM uses FIPS 140-3 validated hardware, Infisical will automatically be FIPS 140-3 compliant. If your HSM uses FIPS 140-2 validated hardware, Infisical will be FIPS 140-2 compliant.
|
||||
|
||||
HSM devices are especially useful for organizations that operate in regulated industries such as healthcare, finance, and government, where data security and compliance are of the utmost importance.
|
||||
|
||||
For organizations that work with US government agencies, FIPS compliance is almost always a requirement when dealing with sensitive information. FIPS compliance ensures that the cryptographic modules used by the organization meet the security requirements set by the US government.
|
||||
|
||||
## Setup Instructions
|
||||
|
||||
|
||||
<Steps>
|
||||
<Step title="Setting up an HSM Device">
|
||||
To set up HSM encryption, you need to configure an HSM provider and HSM key. The HSM provider is used to connect to the HSM device, and the HSM key is used to encrypt Infisical's KMS keys. We recommend using a Cloud HSM provider such as [Thales Luna HSM](https://cpl.thalesgroup.com/encryption/data-protection-on-demand/services/luna-cloud-hsm) or [AWS CloudHSM](https://aws.amazon.com/cloudhsm/).
|
||||
To set up HSM encryption, you need to configure an HSM provider and HSM key. The HSM provider is used to connect to the HSM device, and the HSM key is used to encrypt Infisical's KMS keys. We recommend using a Cloud HSM provider such as [Thales Luna HSM](https://cpl.thalesgroup.com/encryption/data-protection-on-demand/services/luna-cloud-hsm), [AWS CloudHSM](https://aws.amazon.com/cloudhsm/), or [Fortanix HSM](https://www.fortanix.com/platform/data-security-manager).
|
||||
|
||||
You need to follow the instructions provided by the HSM provider to set up the HSM device. Once the HSM device is set up, the HSM device can be used within Infisical.
|
||||
|
||||
After setting up the HSM from your provider, you will have a set of files that you can use to access the HSM. These files need to be present on the machine where Infisical is running.
|
||||
If you are using containers, you will need to mount the folder where these files are stored as a volume in the container.
|
||||
|
||||
The setup process for an HSM device varies depending on the provider. We have created a guide for Thales Luna Cloud HSM, which you can find below.
|
||||
The setup process for an HSM device varies depending on the provider. We have created guides for Thales Luna Cloud HSM and Fortanix HSM, which you can find below.
|
||||
|
||||
</Step>
|
||||
<Step title="Configure HSM on Infisical">
|
||||
@@ -255,6 +247,78 @@ For organizations that work with US government agencies, FIPS compliance is almo
|
||||
</Steps>
|
||||
After following these steps, your Docker setup will be ready to use HSM encryption.
|
||||
</Tab>
|
||||
<Tab title="Fortanix HSM">
|
||||
<Steps>
|
||||
<Step title="Set up Fortanix HSM">
|
||||
To use Fortanix HSM with Infisical, you need to:
|
||||
|
||||
1. Create an App in Fortanix:
|
||||
- Set Interface value to be PKCS#11
|
||||
- Select API key as authentication method
|
||||
- Assign app to a group
|
||||
|
||||
|
||||
|
||||
2. Take note of the domain (e.g., apac.smartkey.io). You will need this to set up the configuration file for the Fortanix client.
|
||||
</Step>
|
||||
|
||||
<Step title="Install PKCS11 Library">
|
||||
The easiest approach would be to download the `.so` file for Linux directly from the [Fortanix PKCS#11 installation page](https://fortanix.zendesk.com/hc/en-us/sections/4408769080724-PKCS-11).
|
||||
|
||||
Create a configuration file named `pkcs11.conf` with the following content:
|
||||
|
||||
```
|
||||
api_endpoint = "https://apac.smartkey.io"
|
||||
prevent_duplicate_opaque_objects = true
|
||||
retry_timeout_millis = 60000
|
||||
```
|
||||
|
||||
Note: Replace `apac.smartkey.io` with your actual Fortanix domain if different. For more details about the configuration file format and additional options, refer to the [Fortanix PKCS#11 Configuration File Documentation](https://support.fortanix.com/docs/clients-pkcs11-library#511-configuration-file-format).
|
||||
</Step>
|
||||
|
||||
<Step title="Create a directory for Fortanix files">
|
||||
Create a directory to store the Fortanix library and configuration file:
|
||||
|
||||
```bash
|
||||
mkdir -p /etc/fortanix-hsm
|
||||
```
|
||||
|
||||
Copy the downloaded `.so` file and the `pkcs11.conf` file to this directory:
|
||||
|
||||
```bash
|
||||
cp /path/to/fortanix_pkcs11_4.37.2554.so /etc/fortanix-hsm/
|
||||
cp /path/to/pkcs11.conf /etc/fortanix-hsm/
|
||||
```
|
||||
</Step>
|
||||
|
||||
<Step title="Run Docker">
|
||||
Run Docker with Fortanix HSM by mounting the directory and setting the required environment variables:
|
||||
|
||||
```bash
|
||||
docker run -p 80:8080 \
|
||||
-v /etc/fortanix-hsm:/etc/fortanix-hsm \
|
||||
-e HSM_LIB_PATH="/etc/fortanix-hsm/fortanix_pkcs11_4.37.2554.so" \ # Path to the PKCS#11 library
|
||||
-e HSM_PIN="MDE3YWUxO..." \ # Your Fortanix app API key used for authentication
|
||||
-e HSM_SLOT=0 \ # Slot value (arbitrary for Fortanix HSM)
|
||||
-e HSM_KEY_LABEL="hsm-key-label" \ # Label to identify the encryption key in the HSM
|
||||
-e FORTANIX_PKCS11_CONFIG_PATH="/etc/fortanix-hsm/pkcs11.conf" \ # Path to Fortanix configuration file
|
||||
|
||||
# The rest are unrelated to HSM setup...
|
||||
-e ENCRYPTION_KEY="<>" \
|
||||
-e AUTH_SECRET="<>" \
|
||||
-e DB_CONNECTION_URI="<>" \
|
||||
-e REDIS_URL="<>" \
|
||||
-e SITE_URL="<>" \
|
||||
infisical/infisical-fips:<version> # Replace <version> with the version you want to use
|
||||
```
|
||||
|
||||
<Warning>
|
||||
Note: Fortanix HSM integration only works for AMD64 CPU architectures.
|
||||
</Warning>
|
||||
</Step>
|
||||
</Steps>
|
||||
After following these steps, your Docker setup will be ready to use Fortanix HSM encryption.
|
||||
</Tab>
|
||||
</Tabs>
|
||||
</Tab>
|
||||
<Tab title="Kubernetes">
|
||||
@@ -569,6 +633,173 @@ For organizations that work with US government agencies, FIPS compliance is almo
|
||||
</Steps>
|
||||
After following these steps, your Kubernetes setup will be ready to use HSM encryption.
|
||||
</Tab>
|
||||
<Tab title="Fortanix HSM">
|
||||
<Steps>
|
||||
<Step title="Set up Fortanix HSM">
|
||||
First, you need to set up Fortanix HSM by:
|
||||
|
||||
1. Creating an App in Fortanix:
|
||||
- Set Interface value to be PKCS#11
|
||||
- Select API key as authentication method
|
||||
- Assign app to a group
|
||||
|
||||
|
||||
|
||||
2. Take note of the domain (e.g., apac.smartkey.io). You will need this when setting up the configuration file.
|
||||
</Step>
|
||||
|
||||
<Step title="Create configuration files">
|
||||
Create a directory to store the Fortanix configuration files:
|
||||
|
||||
```bash
|
||||
mkdir -p /etc/fortanix-hsm
|
||||
```
|
||||
|
||||
Download the Fortanix PKCS#11 library for Linux from the [Fortanix PKCS#11 installation page](https://fortanix.zendesk.com/hc/en-us/sections/4408769080724-PKCS-11).
|
||||
|
||||
Create a configuration file named `pkcs11.conf` with the following content:
|
||||
|
||||
```
|
||||
api_endpoint = "https://apac.smartkey.io"
|
||||
prevent_duplicate_opaque_objects = true
|
||||
retry_timeout_millis = 60000
|
||||
```
|
||||
|
||||
Note: Replace `apac.smartkey.io` with your actual Fortanix domain if different.
|
||||
</Step>
|
||||
|
||||
<Step title="Creating a Persistent Volume Claim (PVC)">
|
||||
Create a Persistent Volume Claim to store the Fortanix files:
|
||||
|
||||
```bash
|
||||
kubectl apply -f - <<EOF
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: fortanix-hsm-pvc
|
||||
spec:
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
resources:
|
||||
requests:
|
||||
storage: 100Mi
|
||||
EOF
|
||||
```
|
||||
|
||||
Create a temporary pod to upload the files:
|
||||
|
||||
```bash
|
||||
kubectl apply -f - <<EOF
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: fortanix-setup-pod
|
||||
spec:
|
||||
containers:
|
||||
- name: setup
|
||||
image: busybox
|
||||
command: ["/bin/sh", "-c", "sleep 3600"]
|
||||
volumeMounts:
|
||||
- name: fortanix-data
|
||||
mountPath: /data
|
||||
volumes:
|
||||
- name: fortanix-data
|
||||
persistentVolumeClaim:
|
||||
claimName: fortanix-hsm-pvc
|
||||
EOF
|
||||
```
|
||||
|
||||
Ensure the pod is running:
|
||||
|
||||
```bash
|
||||
kubectl wait --for=condition=Ready pod/fortanix-setup-pod --timeout=60s
|
||||
```
|
||||
|
||||
Copy the Fortanix files to the PVC:
|
||||
|
||||
```bash
|
||||
kubectl exec fortanix-setup-pod -- mkdir -p /data/
|
||||
kubectl cp /etc/fortanix-hsm/fortanix_pkcs11_4.37.2554.so fortanix-setup-pod:/data/
|
||||
kubectl cp /etc/fortanix-hsm/pkcs11.conf fortanix-setup-pod:/data/
|
||||
kubectl exec fortanix-setup-pod -- chmod -R 755 /data/
|
||||
```
|
||||
|
||||
Delete the temporary pod:
|
||||
|
||||
```bash
|
||||
kubectl delete pod fortanix-setup-pod
|
||||
```
|
||||
</Step>
|
||||
|
||||
<Step title="Update the Kubernetes Secret">
|
||||
Update your Kubernetes secret with the Fortanix HSM environment variables:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: infisical-secrets
|
||||
type: Opaque
|
||||
stringData:
|
||||
# ... Other environment variables ...
|
||||
HSM_LIB_PATH: "/etc/fortanix-hsm/fortanix_pkcs11_4.37.2554.so" # Path to the PKCS#11 library in the container
|
||||
HSM_PIN: "<your-fortanix-api-key>" # Your Fortanix app API key used for authentication
|
||||
HSM_SLOT: "0" # Slot value (can be set to 0 for Fortanix HSM as it's arbitrary)
|
||||
HSM_KEY_LABEL: "hsm-key-label" # Label to identify the encryption key in the HSM
|
||||
FORTANIX_PKCS11_CONFIG_PATH: "/etc/fortanix-hsm/pkcs11.conf" # Path to Fortanix configuration file
|
||||
```
|
||||
|
||||
Apply the updated secret:
|
||||
|
||||
```bash
|
||||
kubectl apply -f ./secret-file-name.yaml
|
||||
```
|
||||
</Step>
|
||||
|
||||
<Step title="Update Helm Values">
|
||||
Update your Helm values to use the FIPS-compliant image and mount the Fortanix HSM files:
|
||||
|
||||
```yaml
|
||||
# ... The rest of the values.yaml file ...
|
||||
|
||||
image:
|
||||
repository: infisical/infisical-fips # Must use "infisical/infisical-fips"
|
||||
tag: "v0.117.1-postgres"
|
||||
pullPolicy: IfNotPresent
|
||||
|
||||
extraVolumeMounts:
|
||||
- name: fortanix-data
|
||||
mountPath: /etc/fortanix-hsm # The path where Fortanix files will be available
|
||||
|
||||
extraVolumes:
|
||||
- name: fortanix-data
|
||||
persistentVolumeClaim:
|
||||
claimName: fortanix-hsm-pvc
|
||||
|
||||
# ... The rest of the values.yaml file ...
|
||||
```
|
||||
|
||||
<Warning>
|
||||
Note: Fortanix HSM integration only works for AMD64 CPU architectures.
|
||||
</Warning>
|
||||
</Step>
|
||||
|
||||
<Step title="Upgrade and Restart">
|
||||
Upgrade the Helm chart with the new values:
|
||||
|
||||
```bash
|
||||
helm upgrade --install infisical infisical-helm-charts/infisical-standalone --values /path/to/values.yaml
|
||||
```
|
||||
|
||||
Restart the deployment:
|
||||
|
||||
```bash
|
||||
kubectl rollout restart deployment/infisical-infisical
|
||||
```
|
||||
</Step>
|
||||
</Steps>
|
||||
After following these steps, your Kubernetes setup will be ready to use Fortanix HSM encryption.
|
||||
</Tab>
|
||||
</Tabs>
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
@@ -20,6 +20,7 @@ The **Settings** page lets you manage information about your organization includ
|
||||
- **Slug**: The slug of your organization.
|
||||
- **Default Organization Member Role**: The role assigned to users when joining your organization unless otherwise specified.
|
||||
- **Incident Contacts**: Emails that should be alerted if anything abnormal is detected within the organization.
|
||||
- **Enabled Products**: Products which are enabled for your organization. This setting strictly affects the sidebar UI; disabling a product does not disable its API or routes.
|
||||
|
||||
|
||||
|
||||
@@ -43,7 +44,7 @@ In the **Organization Roles** tab, you can edit current or create new custom rol
|
||||
|
||||
<Info>
|
||||
Note that Role-Based Access Management (RBAC) is partly a paid feature.
|
||||
|
||||
|
||||
Infisical provides immutable roles like `admin`, `member`, etc.
|
||||
at the organization and project level for free.
|
||||
|
||||
|
||||
299
docs/documentation/platform/pki/acme-ca.mdx
Normal file
299
docs/documentation/platform/pki/acme-ca.mdx
Normal file
@@ -0,0 +1,299 @@
|
||||
---
|
||||
title: "Certificates with ACME CA"
|
||||
description: "Learn how to automatically provision and manage TLS certificates using ACME Certificate Authorities like Let's Encrypt with Infisical PKI"
|
||||
---
|
||||
|
||||
## Concept
|
||||
|
||||
The Infisical ACME integration allows you to connect with ACME (Automatic Certificate Management Environment) Certificate Authorities to automatically issue and manage publicly trusted TLS certificates for your [subscribers](/documentation/platform/pki/subscribers). This integration enables you to leverage established public CA infrastructure like Let's Encrypt while centralizing your certificate management within Infisical.
|
||||
|
||||
ACME is a protocol that automates the process of certificate issuance and renewal through domain validation challenges. The integration is perfect for obtaining trusted X.509 certificates for public-facing services and is capable of automatically renewing certificates as needed.
|
||||
|
||||
<div align="center">
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[ACME CA Provider<br>e.g., Let's Encrypt] <-->|ACME v2 Protocol| B[Infisical]
|
||||
B -->|Creates TXT Records<br>via Route53| C[DNS Validation]
|
||||
B -->|Manages Certificates| D[Subscribers]
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
As part of the workflow, you configure DNS provider credentials, register an ACME CA provider with Infisical, and create subscribers to represent the certificates you wish to issue. Each issued certificate is automatically managed through its lifecycle, including renewal before expiration.
|
||||
|
||||
We recommend reading about [ACME protocol](https://tools.ietf.org/html/rfc8555) and [DNS-01 challenges](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge) for a fuller understanding of the underlying technology.
|
||||
|
||||
## Workflow
|
||||
|
||||
A typical workflow for using Infisical with ACME Certificate Authorities consists of the following steps:
|
||||
|
||||
1. Setting up AWS Route53 credentials with appropriate DNS permissions.
|
||||
2. Creating an AWS connection in Infisical to store the Route53 credentials.
|
||||
3. Registering an ACME Certificate Authority (like Let's Encrypt) with Infisical.
|
||||
4. Creating subscribers that use the ACME CA as their issuing authority.
|
||||
5. Managing certificate lifecycle events such as issuance, renewal, and revocation through Infisical.
|
||||
|
||||
## Understanding ACME DNS-01 Challenge
|
||||
|
||||
The DNS-01 challenge is the method used by ACME CA providers to verify that you control a domain before issuing a certificate. Here's how Infisical handles this process:
|
||||
|
||||
1. **Challenge Request**: When you request a certificate, the ACME provider (like Let's Encrypt) issues a challenge token.
|
||||
|
||||
2. **DNS Record Creation**: Infisical creates a TXT record at `_acme-challenge.<YOUR_DOMAIN>` with a value derived from the challenge token.
|
||||
|
||||
3. **DNS Propagation**: The TXT record must propagate through the DNS system (usually takes a few minutes, depending on TTL settings).
|
||||
|
||||
4. **Validation**: The ACME provider checks for the existence of this TXT record to verify domain control.
|
||||
|
||||
5. **Cleanup**: After validation completes successfully, Infisical automatically removes the TXT record from your DNS.
|
||||
|
||||
This automated process eliminates the need for manual intervention in domain validation, streamlining certificate issuance.
|
||||
|
||||
## Guide
|
||||
|
||||
In the following steps, we explore how to set up ACME Certificate Authority integration with Infisical using Let's Encrypt as an example.
|
||||
|
||||
<Steps>
|
||||
<Step title="Set Up AWS Connection with Required Permissions">
|
||||
Before proceeding with the ACME CA registration, you need to set up an AWS connection with the appropriate permissions for DNS validation:
|
||||
|
||||
1. Navigate to your Organization Settings > App Connections and create a new AWS connection.
|
||||
|
||||
2. Ensure your AWS connection has the following minimum permissions for Route53 DNS validation:
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": "route53:GetChange",
|
||||
"Resource": "arn:aws:route53:::change/*"
|
||||
},
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": "route53:ListHostedZonesByName",
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"route53:ListResourceRecordSets"
|
||||
],
|
||||
"Resource": [
|
||||
"arn:aws:route53:::hostedzone/YOUR_HOSTED_ZONE_ID"
|
||||
]
|
||||
},
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"route53:ChangeResourceRecordSets"
|
||||
],
|
||||
"Resource": [
|
||||
"arn:aws:route53:::hostedzone/YOUR_HOSTED_ZONE_ID"
|
||||
],
|
||||
"Condition": {
|
||||
"ForAllValues:StringEquals": {
|
||||
"route53:ChangeResourceRecordSetsRecordTypes": [
|
||||
"TXT"
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Replace `YOUR_HOSTED_ZONE_ID` with your actual Route53 hosted zone ID.
|
||||
|
||||
For detailed instructions on setting up an AWS connection, see the [AWS Connection](/integrations/app-connections/aws) documentation.
|
||||
</Step>
|
||||
<Step title="Register ACME Certificate Authority">
|
||||
<Tabs>
|
||||
<Tab title="Infisical UI">
|
||||
<Steps>
|
||||
<Step title="Create ACME CA">
|
||||
To register an ACME CA, head to your Project > Internal PKI > Certificate Authorities and press the **+** button in the External Certificate Authorities section.
|
||||
|
||||
|
||||
|
||||
Fill out the details for the ACME CA registration:
|
||||
|
||||
|
||||
|
||||
Here's guidance on each field:
|
||||
|
||||
- **Type**: Select "ACME" as the External CA type.
|
||||
- **Name**: Enter a name for the ACME CA (e.g., "lets-encrypt-production").
|
||||
- **DNS App Connection**: Select from available DNS app connections or configure a new one. This connection provides Infisical with the credentials needed to create and remove DNS records for ACME validation.
|
||||
- **Hosted Zone ID**: Enter your Route53 hosted zone ID (e.g., Z04044I124N1GOOMCOYX1) for the domain(s) you'll be requesting certificates for.
|
||||
- **Directory URL**: Enter the ACME v2 directory URL for your chosen CA provider (e.g., `https://acme-v02.api.letsencrypt.org/directory` for Let's Encrypt).
|
||||
- **Account Email**: Email address to associate with your ACME account. This email will receive important notifications about your certificates.
|
||||
- **Enable Direct Issuance**: Toggle on to allow direct certificate issuance without requiring subscribers.
|
||||
|
||||
Finally, press **Create** to register the ACME CA with Infisical.
|
||||
</Step>
|
||||
<Step title="Verify ACME CA Registration">
|
||||
Once registered, your ACME CA will appear in the External Certificate Authorities section.
|
||||
|
||||
|
||||
|
||||
From here, you can:
|
||||
|
||||
- View the status of the ACME CA registration
|
||||
- Edit the configuration settings
|
||||
- Disable or re-enable the ACME CA
|
||||
- Delete the ACME CA registration if no longer needed
|
||||
|
||||
You can now use this ACME CA to issue certificates for your subscribers.
|
||||
</Step>
|
||||
</Steps>
|
||||
</Tab>
|
||||
<Tab title="API">
|
||||
To register an ACME CA with Infisical using the API, make a request to the Create External CA endpoint:
|
||||
|
||||
### Sample request
|
||||
|
||||
```bash Request
|
||||
curl 'https://app.infisical.com/api/v1/pki/ca/acme' \
|
||||
-H 'Authorization: Bearer <your-access-token>' \
|
||||
-H 'Content-Type: application/json' \
|
||||
--data-raw '{
|
||||
"projectId": "0fccb6ee-1381-4ff1-8d5f-0cb93c6cc4d6",
|
||||
"name": "lets-encrypt-production",
|
||||
"type": "acme",
|
||||
"status": "active",
|
||||
"enableDirectIssuance": true,
|
||||
"configuration": {
|
||||
"dnsAppConnection": {
|
||||
"id": "1e5f8c0d-09d2-492c-9b28-469acd8e841b",
|
||||
"name": "acme-dns-test-connection"
|
||||
},
|
||||
"dnsProviderConfig": {
|
||||
"provider": "route53",
|
||||
"hostedZoneId": "Z040441124N1GOOMCQYX1"
|
||||
},
|
||||
"directoryUrl": "https://acme-v02.api.letsencrypt.org/directory",
|
||||
"accountEmail": "admin@example.com",
|
||||
"dnsAppConnectionId": "1e5f8c0d-09d2-492c-9b28-469acd8e841b"
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
### Sample response
|
||||
|
||||
```bash Response
|
||||
{
|
||||
"id": "c48b701e-a20c-4a9a-8119-68f54e5fbb05",
|
||||
"name": "lets-encrypt-production",
|
||||
"type": "acme",
|
||||
"status": "active",
|
||||
"projectId": "0fccb6ee-1381-4ff1-8d5f-0cb93c6cc4d6",
|
||||
"enableDirectIssuance": true,
|
||||
"configuration": {
|
||||
"accountEmail": "admin@example.com",
|
||||
"directoryUrl": "https://acme-v02.api.letsencrypt.org/directory",
|
||||
"dnsAppConnection": {
|
||||
"id": "1e5f8c0d-09d2-492c-9b28-469acd8e841b",
|
||||
"name": "acme-dns-test-connection"
|
||||
},
|
||||
"dnsAppConnectionId": "1e5f8c0d-09d2-492c-9b28-469acd8e841b",
|
||||
"dnsProviderConfig": {
|
||||
"provider": "route53",
|
||||
"hostedZoneId": "Z040441124N1GOOMCQYX1"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
</Step>
|
||||
<Step title="Create Subscriber for ACME CA">
|
||||
Next, create a subscriber that uses your ACME CA for certificate issuance. Navigate to your Project > Subscribers and create a new subscriber.
|
||||
|
||||
Configure the subscriber with:
|
||||
- **Issuing CA**: Select your registered ACME CA
|
||||
- **Common Name**: The domain for which you want to issue certificates (e.g., `example.com`)
|
||||
- **Alternative Names**: Additional domains to include in the certificate
|
||||
|
||||
Check out the [Subscribers](/documentation/platform/pki/subscribers) page for detailed instructions on creating and managing subscribers.
|
||||
</Step>
|
||||
<Step title="Issue Certificate">
|
||||
Once your subscriber is configured, you can issue certificates either through the Infisical UI or programmatically via the API.
|
||||
|
||||
When you request a certificate:
|
||||
1. Infisical generates a key pair for the certificate
|
||||
2. Sends a Certificate Signing Request (CSR) to the ACME CA
|
||||
3. Receives a DNS-01 challenge from the ACME provider
|
||||
4. Creates a TXT record in Route53 to satisfy the challenge
|
||||
5. Notifies the ACME provider that the challenge is ready for validation
|
||||
6. Once validated, the ACME provider issues the certificate
|
||||
7. Infisical stores and manages the certificate for your subscriber
|
||||
|
||||
The certificate will be automatically renewed before expiration according to your subscriber configuration.
|
||||
</Step>
|
||||
<Step title="Use Certificate in Your Applications">
|
||||
The issued certificate and private key are now available through Infisical and can be:
|
||||
|
||||
- Downloaded directly from the Infisical UI
|
||||
- Retrieved via the Infisical API for programmatic access using the [latest certificate bundle endpoint](/api-reference/endpoints/pki/subscribers/get-latest-cert-bundle)
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Example: Let's Encrypt Integration
|
||||
|
||||
Let's Encrypt is a free, automated, and open Certificate Authority that provides domain-validated SSL/TLS certificates. Here's how the integration works with Infisical:
|
||||
|
||||
### Production Environment
|
||||
- **Directory URL**: `https://acme-v02.api.letsencrypt.org/directory`
|
||||
- **Rate Limits**: 50 certificates per registered domain per week
|
||||
- **Certificate Validity**: 90 days with automatic renewal
|
||||
- **Trusted By**: All major browsers and operating systems
|
||||
|
||||
### Staging Environment (for testing)
|
||||
- **Directory URL**: `https://acme-staging-v02.api.letsencrypt.org/directory`
|
||||
- **Rate Limits**: Much higher limits for testing
|
||||
- **Certificate Validity**: 90 days (not trusted by browsers)
|
||||
- **Use Case**: Testing your ACME integration without hitting production rate limits
|
||||
|
||||
<Note>
|
||||
Always test your ACME integration using Let's Encrypt's staging environment first. This allows you to verify your DNS configuration and certificate issuance process without consuming your production rate limits.
|
||||
</Note>
|
||||
|
||||
## FAQ
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="What DNS validation methods are supported?">
|
||||
Currently, Infisical supports DNS-01 validation through AWS Route53. The DNS-01 challenge method is preferred for ACME integrations because it:
|
||||
|
||||
- Works with wildcard certificates
|
||||
- Doesn't require your servers to be publicly accessible
|
||||
- Can be fully automated without manual intervention
|
||||
|
||||
Support for additional DNS providers is planned for future releases.
|
||||
</Accordion>
|
||||
<Accordion title="Can I use wildcard certificates with ACME CAs?">
|
||||
Yes! ACME CAs like Let's Encrypt support wildcard certificates (e.g., `*.example.com`) when using DNS-01 validation. Simply specify the wildcard domain in your subscriber configuration.
|
||||
|
||||
Note that wildcard certificates still require DNS-01 validation - HTTP-01 validation cannot be used for wildcard certificates.
|
||||
</Accordion>
|
||||
<Accordion title="How long are ACME certificates valid?">
|
||||
Most ACME providers issue certificates with 90-day validity periods. This shorter validity period is designed to:
|
||||
|
||||
- Encourage automation of certificate management
|
||||
- Reduce the impact of compromised certificates
|
||||
- Ensure systems stay up-to-date with certificate management practices
|
||||
|
||||
When configured, Infisical automatically handles certificate renewal for subscribers.
|
||||
</Accordion>
|
||||
<Accordion title="Can I use multiple ACME providers?">
|
||||
Yes! You can register multiple ACME CAs in the same project:
|
||||
|
||||
- Different providers for different domains or use cases
|
||||
- Staging and production environments for the same provider
|
||||
- Backup providers for redundancy
|
||||
|
||||
Each subscriber can be configured to use a specific ACME CA based on your requirements.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
192
docs/documentation/platform/pki/external-ca.mdx
Normal file
192
docs/documentation/platform/pki/external-ca.mdx
Normal file
@@ -0,0 +1,192 @@
|
||||
---
|
||||
title: "External CA"
|
||||
sidebarTitle: "External CA"
|
||||
description: "Learn how to connect External Certificate Authorities with Infisical."
|
||||
---
|
||||
|
||||
## Concept
|
||||
|
||||
In addition to creating a Private CA hierarchy, Infisical allows you to integrate with External Certificate Authorities (CAs) to issue digital certificates for your [subscribers](/documentation/platform/pki/subscribers). This integration enables you to leverage established certificate authority infrastructure while centralizing your certificate management within Infisical.
|
||||
|
||||
<div align="center">
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
B[Infisical] -->|Manages Certificates| D[Subscribers]
|
||||
|
||||
A1[Public CAs<br>Let's Encrypt, ZeroSSL] -->|ACME Protocol| B
|
||||
A2[Enterprise CAs<br>Vault PKI, Step CA] -->|ACME Protocol| B
|
||||
A3[Cloud CAs<br>ACME-compatible services] -->|ACME Protocol| B
|
||||
|
||||
A4[Future: Enterprise CAs] -.->|EST/SCEP Protocols| B
|
||||
A5[Future: Cloud CAs] -.->|REST APIs| B
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
When you integrate an External CA with Infisical, you benefit from:
|
||||
|
||||
1. **Trust by Default**: Certificates issued by public CAs are trusted by default in browsers and operating systems.
|
||||
2. **Unified Management**: Manage all certificates—both internally and externally issued—from a single platform.
|
||||
3. **Automation**: Leverage Infisical's automation capabilities for certificate lifecycle management.
|
||||
4. **Compliance**: Meet requirements for publicly trusted certificates, especially for public-facing services.
|
||||
5. **Flexibility**: Choose the most appropriate CA for different use cases while maintaining consistent management.
|
||||
|
||||
## General Workflow
|
||||
|
||||
A typical workflow for integrating an External CA with Infisical consists of the following steps:
|
||||
|
||||
1. **Select External CA Type**: Choose the appropriate external CA based on your requirements and supported protocols.
|
||||
2. **Configure Prerequisites**: Set up any required credentials, connections, or configurations specific to your chosen CA type.
|
||||
3. **Register External CA**: Add the External CA configuration to your Infisical project.
|
||||
4. **Create Subscribers**: Set up subscribers that use the External CA as their issuing authority.
|
||||
5. **Manage Certificate Lifecycle**: Handle certificate issuance, renewal, and revocation through Infisical's unified interface.
|
||||
|
||||
The specific steps and requirements vary depending on the External CA type you choose to integrate.
|
||||
|
||||
## Supported Integration Methods
|
||||
|
||||
Infisical currently supports integration with External Certificate Authorities through the following protocol:
|
||||
|
||||
### ACME Protocol Integration
|
||||
|
||||
ACME (Automatic Certificate Management Environment) is a widely adopted protocol for automated certificate issuance and management. Infisical can integrate with any CA that supports the ACME protocol, including:
|
||||
|
||||
**Public Certificate Authorities:**
|
||||
- Let's Encrypt - Free, automated SSL/TLS certificates
|
||||
- ZeroSSL - Free and premium SSL certificates
|
||||
- Buypass - Norwegian CA with free ACME certificates
|
||||
|
||||
**Enterprise Certificate Authorities:**
|
||||
- HashiCorp Vault PKI - Enterprise secret management with ACME support
|
||||
- Step CA - Open-source certificate authority with ACME
|
||||
|
||||
**Cloud Certificate Authorities:**
|
||||
- Some managed certificate services that support ACME protocol
|
||||
|
||||
[Learn more about ACME integration →](/documentation/platform/pki/acme-ca)
|
||||
|
||||
## Use Cases
|
||||
|
||||
External CA integration is ideal for various scenarios:
|
||||
|
||||
### Public-Facing Services
|
||||
Use publicly trusted CAs for websites and services that need browser compatibility:
|
||||
- Web applications and APIs
|
||||
- Load balancers and CDNs
|
||||
- Public-facing microservices
|
||||
|
||||
### Compliance Requirements
|
||||
Meet specific compliance standards that require certificates from accredited CAs:
|
||||
- PCI DSS compliance
|
||||
- SOC 2 requirements
|
||||
- Industry-specific regulations
|
||||
|
||||
### Hybrid Infrastructure
|
||||
Combine internal and external CAs for different use cases:
|
||||
- Internal services with Private CAs
|
||||
- Public services with External CAs
|
||||
- Development vs. production environments
|
||||
|
||||
### Legacy System Integration
|
||||
Integrate with existing enterprise PKI infrastructure:
|
||||
- Windows Active Directory Certificate Services
|
||||
- Network device management
|
||||
- IoT device provisioning
|
||||
|
||||
## Benefits of Centralized Management
|
||||
|
||||
Managing External CAs through Infisical provides several advantages over direct CA management:
|
||||
|
||||
### Unified Certificate Inventory
|
||||
- Single dashboard for all certificates
|
||||
- Centralized expiration tracking
|
||||
- Cross-CA certificate analytics
|
||||
|
||||
### Automated Lifecycle Management
|
||||
- Automatic certificate reissuance before expiration
|
||||
- Proactive expiration alerts
|
||||
- Standardized certificate management processes
|
||||
|
||||
### Enhanced Security
|
||||
- Centralized access controls
|
||||
- Audit trails for all certificate operations
|
||||
- Policy enforcement across CAs
|
||||
|
||||
### Operational Efficiency
|
||||
- Reduced manual certificate management
|
||||
- Consistent deployment workflows
|
||||
- API-driven automation
|
||||
- Integration with existing tools
|
||||
|
||||
## Available Integration Guides
|
||||
|
||||
Get started with External CA integration:
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="ACME Protocol Integration" icon="certificate" href="/documentation/platform/pki/acme-ca">
|
||||
Set up automated certificate issuance with any ACME-compatible CA
|
||||
</Card>
|
||||
<Card title="API Integrations" icon="code" color="#gray">
|
||||
Custom CA integrations via REST APIs (Coming Soon)
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## FAQ
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Which External CAs does Infisical currently support?">
|
||||
Currently, Infisical supports any Certificate Authority that implements the ACME protocol, including:
|
||||
|
||||
- **Public CAs**: Let's Encrypt, ZeroSSL, Buypass
|
||||
- **Enterprise CAs**: HashiCorp Vault PKI, Step CA
|
||||
- **Cloud CAs**: ACME-compatible managed services
|
||||
|
||||
Integration uses DNS-01 validation through Route53. Learn more about [supported DNS validation methods](/documentation/platform/pki/acme-ca#what-dns-validation-methods-are-supported).
|
||||
|
||||
Support for additional integration protocols (EST, SCEP, direct APIs) is planned for future releases.
|
||||
</Accordion>
|
||||
<Accordion title="Can I use both Private CAs and External CAs in the same project?">
|
||||
Yes. You can have both Private CAs (root and intermediate) and External CAs in the same project, allowing you flexibility in how you issue certificates for different use cases. This hybrid approach enables you to:
|
||||
|
||||
- Use Private CAs for internal services and applications
|
||||
- Use External CAs for public-facing services
|
||||
- Apply consistent management practices across all certificate types
|
||||
- Implement appropriate security controls based on certificate usage
|
||||
</Accordion>
|
||||
<Accordion title="What types of certificates can I issue through External CAs?">
|
||||
The types of certificates you can issue depend on the External CA provider and type:
|
||||
|
||||
- **Public CAs**: Typically support Domain Validation (DV) certificates, with some offering Organization Validation (OV)
|
||||
- **Enterprise CAs**: Support internal certificates, device certificates, and custom certificate types
|
||||
- **Cloud CAs**: Support various certificate types depending on the service
|
||||
|
||||
Certificate capabilities vary by provider and integration method.
|
||||
</Accordion>
|
||||
<Accordion title="How does certificate renewal work with External CAs?">
|
||||
Certificate reissuance is handled automatically by Infisical based on the CA type:
|
||||
|
||||
- **Public CAs**: Automatic reissuance using ACME protocol with the same certificate extensions before expiration
|
||||
- **Other CA types**: Certificate management methods depend on the specific integration (when available)
|
||||
|
||||
All certificate lifecycle events are tracked and managed through Infisical's unified interface, ensuring continuous certificate validity.
|
||||
</Accordion>
|
||||
<Accordion title="What authentication methods are supported for External CAs?">
|
||||
Authentication methods vary by CA type:
|
||||
|
||||
- **Public CAs**: ACME account registration with email and account keys
|
||||
- **Enterprise CAs**: Client certificates, username/password, or domain authentication (when available)
|
||||
- **Cloud CAs**: API keys, OAuth tokens, or service account authentication (when available)
|
||||
|
||||
Infisical securely stores and manages all authentication credentials.
|
||||
</Accordion>
|
||||
<Accordion title="Can I enforce policies on certificates from External CAs?">
|
||||
Yes, Infisical provides policy enforcement capabilities:
|
||||
|
||||
- Certificate template constraints
|
||||
- Monitoring and alerting policies
|
||||
- Access controls for certificate operations
|
||||
|
||||
These policies ensure consistent governance across both internal and external certificate sources.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "Gloo Mesh Integration"
|
||||
description: "Learn how to automatically provision and manage Istio intermediate CA certificates for Gloo Mesh using Infisical PKI"
|
||||
---
|
||||
|
||||
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).
|
||||
|
||||
## 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.
|
||||
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.
|
||||
|
||||
With this approach, you get the following benefits:
|
||||
|
||||
- Securely store your root CA certificates and private keys.
|
||||
- Leverage Infisical subordinate CAs for an extra layer of protection beneath your root CA.
|
||||
- Use cert-manager to automatically issue and renew Istio intermediate CA certificates from the same root, ensuring cross-cluster workload communication.
|
||||
- Increased auditability of private key infrastructure.
|
||||
|
||||
|
||||
## 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.
|
||||
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.
|
||||
|
||||
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
|
||||
|
||||
## 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.
|
||||
@@ -1,7 +1,6 @@
|
||||
---
|
||||
title: "Kubernetes Issuer"
|
||||
sidebarTitle: "Certificates for Kubernetes"
|
||||
description: "Learn how to automatically provision and manage TLS certificates for in Kubernetes using Infisical PKI"
|
||||
title: "Cert Manager Issuer"
|
||||
description: "Learn how to automatically provision and manage TLS certificates in Kubernetes using Infisical PKI"
|
||||
---
|
||||
|
||||
## Concept
|
||||
@@ -21,20 +20,21 @@ A typical workflow for using the Infisical PKI Issuer to issue certificates for
|
||||
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. 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`.
|
||||
6. Create the approver policy to accept certificate request.
|
||||
7. Creating a `Certificate` resource in your Kubernetes cluster to represent a certificate you wish to issue. As part of this step, you specify the Kubernetes `Secret` to create and store the issued certificate and private key.
|
||||
8. Consuming the issued certificate across your Kubernetes resources from the specified Kubernetes `Secret`.
|
||||
|
||||
## Guide
|
||||
|
||||
In the following steps, we explore how to install the Infisical PKI Issuer using [kubectl](https://github.com/kubernetes/kubectl) and use it to obtain certificates for your Kubernetes resources.
|
||||
In the following steps, we explore how to install the Infisical PKI Issuer using [kubectl](https://github.com/kubernetes/kubectl) and use it to obtain certificates for your Kubernetes resources.
|
||||
|
||||
<Steps>
|
||||
<Step title="Create an identity in Infisical">
|
||||
|
||||
|
||||
Follow the instructions [here](/documentation/platform/identities/universal-auth) to configure a [machine identity](/documentation/platform/identities/machine-identities) in Infisical with Universal Auth.
|
||||
|
||||
|
||||
By the end of this step, you should have a **Client ID** and **Client Secret** on hand as part of the Universal Auth configuration for the Infisical PKI Issuer to authenticate with Infisical; this will be useful in steps 4 and 5.
|
||||
|
||||
|
||||
<Note>
|
||||
Currently, the Infisical PKI Issuer only supports authenticating with Infisical via the [Universal Auth](/documentation/platform/identities/universal-auth) authentication method.
|
||||
|
||||
@@ -43,14 +43,14 @@ In the following steps, we explore how to install the Infisical PKI Issuer using
|
||||
</Step>
|
||||
<Step title="Install cert-manager">
|
||||
Install `cert-manager` into your Kubernetes cluster by following the instructions [here](https://cert-manager.io/docs/installation/) or by running the following command:
|
||||
|
||||
|
||||
```bash
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.15.3/cert-manager.yaml
|
||||
```
|
||||
</Step>
|
||||
<Step title="Install the Issuer Controller">
|
||||
Install the Infisical PKI Issuer controller into your Kubernetes cluster by running the following command:
|
||||
|
||||
|
||||
```bash
|
||||
kubectl apply -f https://raw.githubusercontent.com/Infisical/infisical-issuer/main/build/install.yaml
|
||||
```
|
||||
@@ -76,7 +76,7 @@ In the following steps, we explore how to install the Infisical PKI Issuer using
|
||||
data:
|
||||
clientSecret: <client_secret>
|
||||
```
|
||||
|
||||
|
||||
```bash
|
||||
kubectl apply -f secret-issuer.yaml
|
||||
```
|
||||
@@ -84,7 +84,7 @@ In the following steps, we explore how to install the Infisical PKI Issuer using
|
||||
</Tabs>
|
||||
</Step>
|
||||
<Step title="Create Infisical PKI Issuer">
|
||||
Next, create the Infisical PKI Issuer by filling out `url`, `clientId`, either `caId` or `certificateTemplateId`, and applying the following configuration file for the `Issuer` resource.
|
||||
Next, create the Infisical PKI Issuer by filling out `url`, `clientId`, `projectId` or `certificateTemplateName`, and applying the following configuration file for the `Issuer` resource.
|
||||
This configuration file specifies the connection details to your Infisical PKI CA to be used for issuing certificates.
|
||||
|
||||
```yaml infisical-issuer.yaml
|
||||
@@ -95,8 +95,8 @@ In the following steps, we explore how to install the Infisical PKI Issuer using
|
||||
namespace: <namespace_you_want_to_issue_certificates_in>
|
||||
spec:
|
||||
url: "https://app.infisical.com" # the URL of your Infisical instance
|
||||
caId: <ca_id> # the ID of the CA you want to use to issue certificates
|
||||
certificateTemplateId: <certificate_template_id> # the ID of the certificate template you want to use to issue certificates against
|
||||
projectId: <project_id> # the ID of the project you want to use to issue certificates
|
||||
certificateTemplateName: <certificate_template_name> # the name of the certificate template you want to use to issue certificates against
|
||||
authentication:
|
||||
universalAuth:
|
||||
clientId: <client_id> # the Client ID from step 1
|
||||
@@ -104,20 +104,11 @@ In the following steps, we explore how to install the Infisical PKI Issuer using
|
||||
name: "issuer-infisical-client-secret"
|
||||
key: "clientSecret"
|
||||
```
|
||||
|
||||
|
||||
```
|
||||
kubectl apply -f infisical-issuer.yaml
|
||||
```
|
||||
|
||||
<Warning>
|
||||
The Infisical PKI Issuer supports issuing certificates against a specific CA or a specific certificate template.
|
||||
|
||||
For this reason, you should only fill in the `caId` or the `certificateTemplateId` field but not both.
|
||||
|
||||
We recommend using the `certificateTemplateId` field to issue certificates against a specific [certificate template](/documentation/platform/pki/certificate-templates)
|
||||
since templates let you enforce constraints on issued certificates and may have alerting policies bound to them.
|
||||
</Warning>
|
||||
|
||||
|
||||
You can check that the issuer was created successfully by running the following command:
|
||||
|
||||
```bash
|
||||
@@ -128,16 +119,60 @@ In the following steps, we explore how to install the Infisical PKI Issuer using
|
||||
NAME AGE
|
||||
issuer-infisical 21h
|
||||
```
|
||||
|
||||
|
||||
<Note>
|
||||
An `Issuer` is a namespaced resource, and it is not possible to issue certificates from an `Issuer` in a different namespace.
|
||||
This means you will need to create an `Issuer` in each namespace you wish to obtain `Certificates` in.
|
||||
|
||||
If you want to create a single `Issuer` that can be consumed in multiple namespaces, you should consider creating a `ClusterIssuer` resource. This is almost identical to the `Issuer` resource, however is non-namespaced so it can be used to issue `Certificates` across all namespaces.
|
||||
|
||||
|
||||
You can read more about the `Issuer` and `ClusterIssuer` resources [here](https://cert-manager.io/docs/configuration/).
|
||||
</Note>
|
||||
</Step>
|
||||
<Step title="Create Approver Policy">
|
||||
If you create a `CertificateRequest` now, you'll notice it's neither approved nor denied. This is expected because by default cert-manager approver controller requires an approver-policy.
|
||||
|
||||
To enable approval, create the following YAML file and apply it:
|
||||
|
||||
```yaml infisical-approver-policy.yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: infisical-issuer-approver
|
||||
rules:
|
||||
# Permission to approve or deny CertificateRequests for signers in cert-manager.io API group
|
||||
- apiGroups: ['cert-manager.io']
|
||||
resources: ['signers']
|
||||
verbs: ['approve']
|
||||
resourceNames:
|
||||
# Grant approval permissions for namespaced issuers
|
||||
- "issuers.infisical-issuer.infisical.com/default.issuer-infisical"
|
||||
# Grant approval permissions for cluster-scoped issuers
|
||||
- "clusterissuers.infisical-issuer.infisical.com/clusterissuer-infisical"
|
||||
---
|
||||
# Bind the cert-manager service account to the new role
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
name: infisical-issuer-approver-binding
|
||||
subjects:
|
||||
- kind: ServiceAccount
|
||||
name: cert-manager
|
||||
namespace: cert-manager
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: infisical-issuer-approver
|
||||
```
|
||||
|
||||
```
|
||||
kubectl apply -f infisical-approver-policy.yaml
|
||||
```
|
||||
|
||||
This configuration creates a `ClusterRole` named `infisical-issuer-approver` that grants approval permissions for specific Infisical issuer types. It then binds this role to the cert-manager service account, allowing it to approve certificate requests from your Infisical issuers.
|
||||
|
||||
For information, check out [cert manager approval policy doc](https://cert-manager.io/docs/policy/approval/approver-policy/).
|
||||
</Step>
|
||||
<Step title="Create Certificate">
|
||||
|
||||
Finally, create a `Certificate` by applying the following configuration file.
|
||||
@@ -162,7 +197,7 @@ In the following steps, we explore how to install the Infisical PKI Issuer using
|
||||
duration: 48h # the ttl for the certificate
|
||||
renewBefore: 12h # the time before the certificate expiry that the certificate should be automatically renewed
|
||||
```
|
||||
|
||||
|
||||
The above sample configuration file specifies a certificate to be issued with the common name `certificate-by-issuer.example.com` and ECDSA private key using the P-256 curve, valid for 48 hours; the certificate will be automatically renewed by `cert-manager` 12 hours before expiry.
|
||||
The certificate is issued by the issuer `issuer-infisical` created in the previous step and the resulting certificate and private key will be stored in a secret named `certificate-by-issuer`.
|
||||
|
||||
@@ -181,7 +216,7 @@ In the following steps, we explore how to install the Infisical PKI Issuer using
|
||||
</Step>
|
||||
<Step title="Use Certificate in Kubernetes Secret">
|
||||
Since the actual certificate and private key are stored in a Kubernetes secret, we can check that the secret was created successfully by running the following command:
|
||||
|
||||
|
||||
```bash
|
||||
kubectl get secret certificate-by-issuer -n <namespace_of_your_certificate>
|
||||
```
|
||||
@@ -190,9 +225,9 @@ In the following steps, we explore how to install the Infisical PKI Issuer using
|
||||
NAME TYPE DATA AGE
|
||||
certificate-by-issuer kubernetes.io/tls 2 26h
|
||||
```
|
||||
|
||||
|
||||
We can `describe` the secret to get more information about it:
|
||||
|
||||
|
||||
```bash
|
||||
kubectl describe secret certificate-by-issuer -n default
|
||||
```
|
||||
@@ -201,14 +236,14 @@ In the following steps, we explore how to install the Infisical PKI Issuer using
|
||||
Name: certificate-by-issuer
|
||||
Namespace: default
|
||||
Labels: controller.cert-manager.io/fao=true
|
||||
Annotations: cert-manager.io/alt-names:
|
||||
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/ip-sans:
|
||||
cert-manager.io/issuer-group: infisical-issuer.infisical.com
|
||||
cert-manager.io/issuer-kind: Issuer
|
||||
cert-manager.io/issuer-name: issuer-infisical
|
||||
cert-manager.io/uri-sans:
|
||||
cert-manager.io/uri-sans:
|
||||
|
||||
Type: kubernetes.io/tls
|
||||
|
||||
@@ -218,17 +253,18 @@ In the following steps, we explore how to install the Infisical PKI Issuer using
|
||||
tls.crt: 2380 bytes
|
||||
tls.key: 227 bytes
|
||||
```
|
||||
|
||||
|
||||
Here, `ca.crt` is the Root CA certificate, `tls.crt` is the requested certificate followed by the certificate chain, and `tls.key` is the private key for the certificate.
|
||||
|
||||
|
||||
We can decode the certificate and print it out using `openssl`:
|
||||
|
||||
```bash
|
||||
kubectl get secret certificate-by-issuer -n default -o jsonpath='{.data.tls\.crt}' | base64 --decode | openssl x509 -text -noout
|
||||
```
|
||||
|
||||
|
||||
In any case, the certificate is ready to be used as Kubernetes Secret by your Kubernetes resources.
|
||||
</Step>
|
||||
|
||||
</Steps>
|
||||
|
||||
## FAQ
|
||||
@@ -236,15 +272,24 @@ In the following steps, we explore how to install the Infisical PKI Issuer using
|
||||
<AccordionGroup>
|
||||
<Accordion title="What fields can be configured on the Certificate resource?">
|
||||
The full list of the fields supported on the `Certificate` resource can be found in the API reference documentation [here](https://cert-manager.io/docs/reference/api-docs/#cert-manager.io/v1.CertificateSpec).
|
||||
|
||||
|
||||
<Note>
|
||||
Currently, not all fields are supported by the Infisical PKI Issuer.
|
||||
</Note>
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Can certificates be renewed automatically?">
|
||||
Yes. `cert-manager` will automatically renew certificates according to the `renewBefore` threshold of expiry as
|
||||
specified in the corresponding `Certificate` resource.
|
||||
|
||||
|
||||
You can read more about the `renewBefore` field [here](https://cert-manager.io/docs/reference/api-docs/#cert-manager.io/v1.CertificateSpec).
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
<Accordion title="Why is my CertificateRequest not being approved, showing 'CertificateRequest has not been approved yet. Ignoring.'?">
|
||||
If you see log messages similar to:
|
||||
```
|
||||
"CertificateRequest has not been approved yet. Ignoring.","controller":"certificaterequest","controllerGroup":"cert-manager.io","controllerKind":"CertificateRequest","CertificateRequest":{"name":"skynet-infisical-rta-rsa2048-1","namespace":"infisical-system"},"namespace":"infisical-system","name":"skynet-infisical-rta-rsa2048-1","reconcileID":"bfb7cad9-d867-45b5-b3a3-0139e731b7a6"}
|
||||
```
|
||||
This indicates that the `CertificateRequest` has been created, but `cert-manager` has not yet approved it. This typically occurs because a necessary approver policy is missing. Refer to the documentation above to create an approver policy.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
@@ -24,7 +24,7 @@ A[Issuing CA] --> C1[Certificate]
|
||||
|
||||
The typical workflow for managing subscribers consists of the following steps:
|
||||
|
||||
1. Creating a subscriber and defining which (issuing) CA will issue X.509 certificates for it as well as attributes to be included on the certificates including common name, subject alternative names, TLL, etc.
|
||||
1. Creating a subscriber and defining which (issuing) CA will issue X.509 certificates for it as well as attributes to be included on the certificates including common name, subject alternative names, TTL, etc. You can also optionally configure automatic certificate renewal.
|
||||
2. Requesting for a certificate against the subscriber with or without a certificate signing request (CSR).
|
||||
3. Managing certificate lifecycle events such as certificate renewal and revocation. As part of the certificate revocation flow,
|
||||
you can also query for a Certificate Revocation List [CRL](https://en.wikipedia.org/wiki/Certificate_revocation_list), a time-stamped, signed
|
||||
@@ -49,17 +49,32 @@ In the following steps, we explore how to issue a X.509 certificate for a subscr
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
The **PKI Subscriber** modal is organized into two tabs:
|
||||
|
||||
### Configuration Tab
|
||||
|
||||
|
||||
|
||||
Here's some guidance on each field.
|
||||
This tab contains the core certificate attributes and settings:
|
||||
|
||||
- Subscriber Name: A slug-friendly name for the subscriber such as `web-service`.
|
||||
- Issuing CA: The Certificate Authority (CA) that will issue X.509 certificates for the subscriber.
|
||||
- Common Name (CN): The common name to be included on certificates to be issued to the subscriber.
|
||||
- Subject Alternative Names (SANs): A comma-delimited list of Subject Alternative Names (SANs) to be included on certificates; these can be hostnames or email addresses like `app1.acme.com, app2.acme.com`.
|
||||
- TTL: The lifetime of the certificate.
|
||||
- Key Usage: The key usage extension of the certificate.
|
||||
- Extended Key Usage: The extended key usage extension of the certificate.
|
||||
- **Subscriber Name**: A slug-friendly name for the subscriber such as `web-service`.
|
||||
- **Issuing CA**: The Certificate Authority (CA) that will issue X.509 certificates for the subscriber.
|
||||
- **Common Name (CN)**: The common name to be included on certificates to be issued to the subscriber.
|
||||
- **Subject Alternative Names (SANs)**: A comma-delimited list of Subject Alternative Names (SANs) to be included on certificates; these can be hostnames or email addresses like `app1.acme.com, app2.acme.com`.
|
||||
- **TTL**: The lifetime of the certificate.
|
||||
- **Key Usage**: The key usage extension of the certificate.
|
||||
- **Extended Key Usage**: The extended key usage extension of the certificate.
|
||||
|
||||
### Advanced Tab
|
||||
|
||||
|
||||
|
||||
This tab contains optional advanced features:
|
||||
|
||||
- **Certificate Auto Renewal**: Toggle to enable automatic certificate renewal for this subscriber.
|
||||
- **Renewal Before Expiry**: When auto renewal is enabled, specify how many days before certificate expiry the system should automatically issue a new certificate (e.g., 7 days).
|
||||
|
||||
<Note>
|
||||
It's possible to issue certificates for a subscriber with or without a certificate signing request (CSR).
|
||||
@@ -68,6 +83,10 @@ In the following steps, we explore how to issue a X.509 certificate for a subscr
|
||||
and a certificate is only issued if they comply.
|
||||
</Note>
|
||||
|
||||
<Note>
|
||||
When Certificate Auto Renewal is enabled, the system will automatically issue new certificates before the current ones expire, ensuring continuous certificate availability without manual intervention.
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
<Step title="Requesting a certificate">
|
||||
Once you have created a subscriber from step 1, you can issue a certificate for it.
|
||||
@@ -123,8 +142,13 @@ openssl verify -verbose -crl_check -crl_download -CAfile chain.pem cert.pem
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="What is the workflow for renewing a certificate?">
|
||||
To renew a certificate, you have to issue a new certificate for the same
|
||||
subscriber. The original certificate will continue to be valid through its
|
||||
original TTL unless explicitly revoked.
|
||||
To renew a certificate, you have two options:
|
||||
|
||||
**Manual Renewal**: Issue a new certificate for the same subscriber. The original certificate will continue to be valid through its original TTL unless explicitly revoked.
|
||||
|
||||
**Automatic Renewal**: If Certificate Auto Renewal is enabled for the subscriber, the system will automatically issue new certificates before the current ones expire based on the configured renewal period.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
<Accordion title="How does Certificate Auto Renewal work?">
|
||||
When Certificate Auto Renewal is enabled for a subscriber, the system monitors certificate expiration dates and automatically issues new certificates before they expire. You can configure how many days before expiry the renewal should occur (e.g., 7 days before expiration). This ensures continuous certificate availability without manual intervention.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
@@ -33,6 +33,14 @@ First, you would need to create a set of policies for a certain environment. In
|
||||
|
||||
The enforcement level determines how strict the policy is. A **Hard** enforcement level means that any change that matches the policy will need full approval prior merging. A **Soft** enforcement level allows for break glass functionality on the request. If a change request is bypassed, the approvers will be notified via email.
|
||||
|
||||
<Note>
|
||||
Enabling the "Bypass Approvals" toggle during policy creation will create a **Soft** enforcement level. Disabling the toggle makes the enforcement level **Hard**.
|
||||
</Note>
|
||||
|
||||
If you choose to allow approval bypasses (Soft Enforcement), you may select specific users or groups that can perform the bypass for that specific policy. Not choosing users or groups will allow anyone to bypass the policy.
|
||||
|
||||
A policy bypasser cannot bypass requests from others; the bypass action can only be performed by the request creator.
|
||||
|
||||
### Self approvals
|
||||
|
||||
If the **Self Approvals** option is enabled, users who are designated as approvers on the policy can approve requests that they themselves have submitted.
|
||||
|
||||
@@ -28,7 +28,7 @@ description: "Learn how to automatically rotate LDAP passwords."
|
||||
3. Select the **LDAP Connection** to use and configure the rotation behavior. Then click **Next**.
|
||||
|
||||
|
||||
- **LDAP Connection** - the connection that will perform the rotation of the configured DN's password.
|
||||
- **LDAP Connection** - the connection that will perform the rotation of the configured principal's password.
|
||||
<Note>
|
||||
LDAP Password Rotations require an LDAP Connection that uses ldaps:// protocol.
|
||||
</Note>
|
||||
@@ -40,13 +40,20 @@ description: "Learn how to automatically rotate LDAP passwords."
|
||||
</Note>
|
||||
|
||||
|
||||
4. Specify the Distinguished Name (DN) of the principal whose password you want to rotate and configure the password requirements. Then click **Next**.
|
||||
4. Configure the required Parameters for your rotation. Then click **Next**.
|
||||
|
||||
|
||||
- **Rotation Method** - The method to use when rotating the target principal's password.
|
||||
- **Connection Principal** - Infisical will use the LDAP Connection's binding principal to rotate the target principal's password.
|
||||
- **Target Principal** - Infisical will bind with the target Principal to rotate their own password.
|
||||
- **DN/UPN** - The Distinguished Name (DN), or User Principal Name (UPN) if supported, of the principal whose password you want to rotate.
|
||||
- **Password** - The target principal's password (if **Rotation Method** is set to **Target Principal**).
|
||||
- **Password Requirements** - The constraints to apply when generating new passwords.
|
||||
|
||||
5. Specify the secret names that the client credentials should be mapped to. Then click **Next**.
|
||||
|
||||
|
||||
- **DN** - the name of the secret that the principal's Distinguished Name (DN) will be mapped to.
|
||||
- **DN/UPN** - the name of the secret that the principal's Distinguished Name (DN) or User Principal Name (UPN) will be mapped to.
|
||||
- **Password** - the name of the secret that the rotated password will be mapped to.
|
||||
|
||||
6. Give your rotation a name and description (optional). Then click **Next**.
|
||||
@@ -85,6 +92,7 @@ description: "Learn how to automatically rotate LDAP passwords."
|
||||
"minutes": 0
|
||||
},
|
||||
"parameters": {
|
||||
"rotationMethod": "connection-principal",
|
||||
"dn": "CN=John,CN=Users,DC=example,DC=com",
|
||||
"passwordRequirements": {
|
||||
"length": 48,
|
||||
@@ -154,6 +162,7 @@ description: "Learn how to automatically rotate LDAP passwords."
|
||||
"lastRotationMessage": null,
|
||||
"type": "ldap-password",
|
||||
"parameters": {
|
||||
"rotationMethod": "connection-principal",
|
||||
"dn": "CN=John,CN=Users,DC=example,DC=com",
|
||||
"passwordRequirements": {
|
||||
"length": 48,
|
||||
|
||||
@@ -0,0 +1,158 @@
|
||||
---
|
||||
title: "MySQL Credentials Rotation"
|
||||
description: "Learn how to automatically rotate MySQL credentials."
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. Create a [MySQL Connection](/integrations/app-connections/mysql) with the required **Secret Rotation** permissions
|
||||
2. Create two designated database users for Infisical to rotate the credentials for. Be sure to grant each user login permissions for the desired database with the necessary privileges their use case will require.
|
||||
|
||||
An example creation statement might look like:
|
||||
```SQL
|
||||
-- create user roles
|
||||
CREATE USER 'infisical_user_1'@'%' IDENTIFIED BY 'temporary_password';
|
||||
CREATE USER 'infisical_user_2'@'%' IDENTIFIED BY 'temporary_password';
|
||||
|
||||
-- grant all privileges
|
||||
GRANT ALL PRIVILEGES ON my_database.* TO 'infisical_user_1'@'%';
|
||||
GRANT ALL PRIVILEGES ON my_database.* TO 'infisical_user_2'@'%';
|
||||
|
||||
-- apply the privilege changes
|
||||
FLUSH PRIVILEGES;
|
||||
```
|
||||
|
||||
<Tip>
|
||||
To learn more about the MySQL permission system, please visit their [documentation](https://dev.mysql.com/doc/refman/8.4/en/grant.html).
|
||||
</Tip>
|
||||
|
||||
|
||||
## Create a MySQL Credentials Rotation in Infisical
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Infisical UI">
|
||||
1. Navigate to your Secret Manager Project's Dashboard and select **Add Secret Rotation** from the actions dropdown.
|
||||
|
||||
|
||||
2. Select the **MySQL Credentials** option.
|
||||
|
||||
|
||||
3. Select the **MySQL Connection** to use and configure the rotation behavior. Then click **Next**.
|
||||
|
||||
|
||||
- **MySQL Connection** - the connection that will perform the rotation of the configured database user credentials.
|
||||
- **Rotation Interval** - the interval, in days, that once elapsed will trigger a rotation.
|
||||
- **Rotate At** - the local time of day when rotation should occur once the interval has elapsed.
|
||||
- **Auto-Rotation Enabled** - whether secrets should automatically be rotated once the rotation interval has elapsed. Disable this option to manually rotate secrets or pause secret rotation.
|
||||
|
||||
4. Input the usernames of the database users created above that will be used for rotation. Then click **Next**.
|
||||
|
||||
|
||||
- **Database Username 1** - the username of the first user that will be used for rotation.
|
||||
- **Database Username 2** - the username of the second user that will be used for rotation.
|
||||
|
||||
5. Specify the secret names that the active credentials should be mapped to. Then click **Next**.
|
||||
|
||||
|
||||
- **Username** - the name of the secret that the active username will be mapped to.
|
||||
- **Password** - the name of the secret that the active password will be mapped to.
|
||||
|
||||
6. Give your rotation a name and description (optional). Then click **Next**.
|
||||
|
||||
|
||||
- **Name** - the name of the secret rotation configuration. Must be slug-friendly.
|
||||
- **Description** (optional) - a description of this rotation configuration.
|
||||
|
||||
7. Review your configuration, then click **Create Secret Rotation**.
|
||||
|
||||
|
||||
8. Your **MySQL Credentials** are now available for use via the mapped secrets.
|
||||
|
||||
</Tab>
|
||||
<Tab title="API">
|
||||
To create a MySQL Credentials Rotation, make an API request to the [Create MySQL Credentials Rotation](/api-reference/endpoints/secret-rotations/mysql-credentials/create) API endpoint.
|
||||
|
||||
### Sample request
|
||||
|
||||
```bash Request
|
||||
curl --request POST \
|
||||
--url https://us.infisical.com/api/v2/secret-rotations/mysql-credentials \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data '{
|
||||
"name": "my-mysql-rotation",
|
||||
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"description": "my database credentials rotation",
|
||||
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"environment": "dev",
|
||||
"secretPath": "/",
|
||||
"isAutoRotationEnabled": true,
|
||||
"rotationInterval": 30,
|
||||
"rotateAtUtc": {
|
||||
"hours": 0,
|
||||
"minutes": 0
|
||||
},
|
||||
"parameters": {
|
||||
"username1": "infisical_user_1",
|
||||
"username2": "infisical_user_2"
|
||||
},
|
||||
"secretsMapping": {
|
||||
"username": "MYSQL_USERNAME",
|
||||
"password": "MYSQL_PASSWORD"
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
### Sample response
|
||||
|
||||
```bash Response
|
||||
{
|
||||
"secretRotation": {
|
||||
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"name": "my-mysql-rotation",
|
||||
"description": "my database credentials rotation",
|
||||
"secretsMapping": {
|
||||
"username": "MYSQL_USERNAME",
|
||||
"password": "MYSQL_PASSWORD"
|
||||
},
|
||||
"isAutoRotationEnabled": true,
|
||||
"activeIndex": 0,
|
||||
"folderId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"createdAt": "2023-11-07T05:31:56Z",
|
||||
"updatedAt": "2023-11-07T05:31:56Z",
|
||||
"rotationInterval": 30,
|
||||
"rotationStatus": "success",
|
||||
"lastRotationAttemptedAt": "2023-11-07T05:31:56Z",
|
||||
"lastRotatedAt": "2023-11-07T05:31:56Z",
|
||||
"lastRotationJobId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"nextRotationAt": "2023-11-07T05:31:56Z",
|
||||
"connection": {
|
||||
"app": "mysql",
|
||||
"name": "my-mysql-connection",
|
||||
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a"
|
||||
},
|
||||
"environment": {
|
||||
"slug": "dev",
|
||||
"name": "Development",
|
||||
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a"
|
||||
},
|
||||
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"folder": {
|
||||
"id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"path": "/"
|
||||
},
|
||||
"rotateAtUtc": {
|
||||
"hours": 0,
|
||||
"minutes": 0
|
||||
},
|
||||
"lastRotationMessage": null,
|
||||
"type": "mysql-credentials",
|
||||
"parameters": {
|
||||
"username1": "infisical_user_1",
|
||||
"username2": "infisical_user_2"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
@@ -5,42 +5,53 @@ description: "Learn how to share time & view-count bound secrets securely with a
|
||||
---
|
||||
|
||||
Developers frequently need to share secrets with team members, contractors, or other third parties, which can be risky due to potential leaks or misuse.
|
||||
Infisical offers a secure solution for sharing secrets over the internet in a time and view count bound manner. It is possible to share secrets without signing up via [share.infisical.com](https://share.infisical.com) or via Infisical Dashboard (which has more advanced funcitonality).
|
||||
Infisical offers a secure solution for sharing secrets over the internet in a time and view-count bound manner. It is possible to share secrets without signing up via [share.infisical.com](https://share.infisical.com) or via Infisical Dashboard (which has more advanced functionality).
|
||||
|
||||
With its zero-knowledge architecture, secrets shared via Infisical remain unreadable even to Infisical itself.
|
||||
## Sharing a Secret
|
||||
|
||||
## Share a Secret
|
||||
<Steps>
|
||||
<Step title="Navigate to the 'Secret Sharing' page and click 'Share Secret'">
|
||||
|
||||
</Step>
|
||||
<Step title="Configure Secret Share">
|
||||
|
||||
|
||||
1. Navigate to the **Organization** page.
|
||||
2. Click on the **Secret Sharing** tab from the sidebar.
|
||||
- **Name (optional):** A friendly name for the shared secret.
|
||||
- **Your Secret:** The secret content.
|
||||
- **Password (optional):** A password which will be required when viewing the secret.
|
||||
|
||||
|
||||
- **Limit access to people within organization:** Only lets people within your organization view the secret. Enabling this feature requires secret viewers to log into Infisical.
|
||||
- **Expires In:** The time it'll take for the secret to expire.
|
||||
- **Max Views:** How many times the secret can be viewed before it's destroyed.
|
||||
|
||||
<Note>
|
||||
Infisical does not have access to the shared secrets. This is a part of our
|
||||
zero knowledge architecture.
|
||||
</Note>
|
||||
- **Authorized Emails (optional):** Emails which are authorized to view this secret. Enabling this feature requires secret viewers to log into Infisical. Each email will receive the shared secret link in their inbox after creation.
|
||||
</Step>
|
||||
<Step title="Copy Link and Share Secret">
|
||||
After creating the shared secret, its link will be displayed. Share this with the intended recipients.
|
||||
|
||||
3. Click on the **Share Secret** button. Set the secret, its expiration time and specify if the secret can be viewed only once. It expires as soon as any of the conditions are met.
|
||||
Also, specify if the secret can be accessed by anyone or only people within your organization.
|
||||
<Info>
|
||||
If no organization or email restrictions are set, anyone with this link can view the secret before it expires.
|
||||
</Info>
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Access Shared Secret">
|
||||
Visiting the secret link will display its contents.
|
||||
|
||||
<Note>
|
||||
Secret once set cannot be changed. This is to ensure that the secret is not
|
||||
tampered with.
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
5. Copy the link and share it with the intended recipient. Anyone with the link can access the secret before its expiration condition. Hence, it is recommended to share the link only with the intended recipient.
|
||||
## Deleting a Shared Secret
|
||||
|
||||
|
||||
To delete a shared secret, click the **Trash Can** icon on the relevant shared secret row in the [**Secret Sharing**](https://app.infisical.com/organization/secret-sharing?selectedTab=share-secret) page.
|
||||
|
||||
## Access a Shared Secret
|
||||
|
||||
|
||||
Just click on the link you received to access the secret. The secret will be displayed on the screen & for how long it is valid.
|
||||
## FAQ
|
||||
|
||||
|
||||
|
||||
## Delete a Shared Secret
|
||||
|
||||
In the **Secret Sharing** tab, click on the **Delete** button next to the secret you want to delete. This will delete the secret immediately & the link will no longer be accessible.
|
||||
<AccordionGroup>
|
||||
<Accordion title="Can secrets be changed after they are shared?">
|
||||
No, secrets cannot be changed after they've been created. This is to ensure that secrets are not tampered with.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
@@ -14,7 +14,7 @@ description: "Learn how to configure Auth0 OIDC for Infisical SSO."
|
||||
<Step title="Setup application in Auth0">
|
||||
1.1. From the Application's Page, navigate to the settings tab of the Auth0 application you want to integrate with Infisical.
|
||||
|
||||
|
||||
|
||||
1.2. In the Application URIs section, set the **Application Login URI** and **Allowed Web Origins** fields to `https://app.infisical.com` and the **Allowed Callback URL** field to `https://app.infisical.com/api/v1/sso/oidc/callback`.
|
||||
|
||||
|
||||
@@ -70,7 +70,7 @@ description: "Learn how to configure Auth0 OIDC for Infisical SSO."
|
||||
prior to enforcing OIDC SSO to prevent any unintended issues.
|
||||
</Warning>
|
||||
<Info>
|
||||
In case of a lockout, an organization admin can use the admin login portal in the `/login/admin` path e.g. https://app.infisical.com/login/admin.
|
||||
In case of a lockout, an organization admin can use the [Admin Login Portal](https://infisical.com/docs/documentation/platform/sso/overview#admin-login-portal) in the `/login/admin` path e.g. https://app.infisical.com/login/admin.
|
||||
</Info>
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
@@ -23,30 +23,30 @@ description: "Learn how to configure Auth0 SAML for Infisical SSO."
|
||||
</Step>
|
||||
<Step title="Create a SAML application in Auth0">
|
||||
2.1. In your Auth0 account, head to Applications and create an application.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Select **Regular Web Application** and press **Create**.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
2.2. In the Application head to Settings > Application URIs and add the **Application Callback URL** from step 1 into the **Allowed Callback URLs** field.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
2.3. In the Application head to Addons > SAML2 Web App and copy the **Issuer**, **Identity Provider Login URL**, and **Identity Provider Certificate** from the **Usage** tab.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
2.4. Back in Infisical, set **Issuer**, **Identity Provider Login URL**, and **Certificate** to the corresponding items from step 2.3.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
2.5. Back in Auth0, in the **Settings** tab, set the **Application Callback URL** to the **Application Callback URL** from step 1
|
||||
and update the **Settings** field with the JSON under the picture below (replacing `<audience-from-infisical>` with the **Audience** from step 1).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
```json
|
||||
{
|
||||
"audience": "<audience-from-infisical>",
|
||||
@@ -76,7 +76,7 @@ description: "Learn how to configure Auth0 SAML for Infisical SSO."
|
||||
Once you've completed this requirement, you can toggle the **Enforce SAML SSO** button to enforce SAML SSO.
|
||||
|
||||
<Info>
|
||||
In case of a lockout, an organization admin can use the admin login portal in the `/login/admin` path e.g. https://app.infisical.com/login/admin.
|
||||
In case of a lockout, an organization admin can use the [Admin Login Portal](https://infisical.com/docs/documentation/platform/sso/overview#admin-login-portal) in the `/login/admin` path e.g. https://app.infisical.com/login/admin.
|
||||
</Info>
|
||||
</Step>
|
||||
|
||||
@@ -96,4 +96,4 @@ description: "Learn how to configure Auth0 SAML for Infisical SSO."
|
||||
32`.
|
||||
<div class="height:1px;"/>
|
||||
- `SITE_URL`: The absolute URL of your self-hosted instance of Infisical including the protocol (e.g. https://app.infisical.com)
|
||||
</Note>
|
||||
</Note>
|
||||
|
||||
@@ -5,7 +5,7 @@ description: "Learn how to configure Microsoft Entra ID for Infisical SSO."
|
||||
|
||||
<Info>
|
||||
Azure SAML SSO is a paid feature.
|
||||
|
||||
|
||||
If you're using Infisical Cloud, then it is available under the **Pro Tier**. If you're self-hosting Infisical,
|
||||
then you should contact sales@infisical.com to purchase an enterprise license to use it.
|
||||
</Info>
|
||||
@@ -26,7 +26,7 @@ description: "Learn how to configure Microsoft Entra ID for Infisical SSO."
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
On the next screen, press the **+ Create your own application** button.
|
||||
Give the application a unique name like Infisical; choose the "Integrate any other application you don't find in the gallery (Non-gallery)"
|
||||
option and hit the **Create** button.
|
||||
@@ -89,9 +89,9 @@ description: "Learn how to configure Microsoft Entra ID for Infisical SSO."
|
||||
</Step>
|
||||
<Step title="Assign users in Azure to the application">
|
||||
Back in Azure, navigate to the **Users and groups** tab and select **+ Add user/group** to assign access to the login with SSO application on a user or group-level.
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
</Step>
|
||||
<Step title="Enable SAML SSO in Infisical">
|
||||
Enabling SAML SSO allows members in your organization to log into Infisical via Azure.
|
||||
|
||||
@@ -109,7 +109,7 @@ description: "Learn how to configure Microsoft Entra ID for Infisical SSO."
|
||||
prior to enforcing SAML SSO to prevent any unintended issues.
|
||||
</Warning>
|
||||
<Info>
|
||||
In case of a lockout, an organization admin can use the admin login portal in the `/login/admin` path e.g. https://app.infisical.com/login/admin.
|
||||
In case of a lockout, an organization admin can use the [Admin Login Portal](https://infisical.com/docs/documentation/platform/sso/overview#admin-login-portal) in the `/login/admin` path e.g. https://app.infisical.com/login/admin.
|
||||
</Info>
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
@@ -70,7 +70,7 @@ Prerequisites:
|
||||
We recommend ensuring that your account is provisioned using the identity provider prior to enforcing OIDC SSO to prevent any unintended issues.
|
||||
</Warning>
|
||||
<Info>
|
||||
In case of a lockout, an organization admin can use the admin login portal in the `/login/admin` path e.g. https://app.infisical.com/login/admin.
|
||||
In case of a lockout, an organization admin can use the [Admin Login Portal](https://infisical.com/docs/documentation/platform/sso/overview#admin-login-portal) in the `/login/admin` path e.g. https://app.infisical.com/login/admin.
|
||||
</Info>
|
||||
</Step>
|
||||
|
||||
|
||||
@@ -24,21 +24,21 @@ description: "Learn how to configure Google SAML for Infisical SSO."
|
||||
<Step title="Create a SAML application in Google">
|
||||
2.1. In your [Google Admin console](https://support.google.com/a/answer/182076), head to Menu > Apps > Web and mobile apps and
|
||||
create a **custom SAML app**.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
2.2. In the **App details** tab, give the application a unique name like Infisical.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
2.3. In the **Google Identity Provider details** tab, copy the **SSO URL**, **Entity ID** and **Certificate**.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
2.4. Back in Infisical, set **SSO URL** and **Certificate** to the corresponding items from step 2.3.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
2.5. Back in the Google Admin console, in the **Service provider details** tab, set the **ACS URL** and **Entity ID** to the corresponding items from step 1.
|
||||
|
||||
Also, check the **Signed response** checkbox.
|
||||
@@ -84,7 +84,7 @@ description: "Learn how to configure Google SAML for Infisical SSO."
|
||||
prior to enforcing SAML SSO to prevent any unintended issues.
|
||||
</Warning>
|
||||
<Info>
|
||||
In case of a lockout, an organization admin can use the admin login portal in the `/login/admin` path e.g. https://app.infisical.com/login/admin.
|
||||
In case of a lockout, an organization admin can use the [Admin Login Portal](https://infisical.com/docs/documentation/platform/sso/overview#admin-login-portal) in the `/login/admin` path e.g. https://app.infisical.com/login/admin.
|
||||
</Info>
|
||||
</Step>
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ description: "Learn how to configure JumpCloud SAML for Infisical SSO."
|
||||
|
||||
<Info>
|
||||
JumpCloud SAML SSO is a paid feature.
|
||||
|
||||
|
||||
If you're using Infisical Cloud, then it is available under the **Pro Tier**. If you're self-hosting Infisical,
|
||||
then you should contact sales@infisical.com to purchase an enterprise license to use it.
|
||||
</Info>
|
||||
@@ -83,13 +83,12 @@ description: "Learn how to configure JumpCloud SAML for Infisical SSO."
|
||||
|
||||
To enforce SAML SSO, you're required to test out the SAML connection by successfully authenticating at least one JumpCloud user with Infisical;
|
||||
Once you've completed this requirement, you can toggle the **Enforce SAML SSO** button to enforce SAML SSO.
|
||||
|
||||
|
||||
<Warning>
|
||||
We recommend ensuring that your account is provisioned the application in JumpCloud
|
||||
prior to enforcing SAML SSO to prevent any unintended issues.
|
||||
We recommend ensuring that your account is provisioned in the application in JumpCloud prior to enforcing SAML SSO to prevent any unintended issues.
|
||||
</Warning>
|
||||
<Info>
|
||||
In case of a lockout, an organization admin can use the admin login portal in the `/login/admin` path e.g. https://app.infisical.com/login/admin.
|
||||
In case of a lockout, an organization admin can use the [Admin Login Portal](https://infisical.com/docs/documentation/platform/sso/overview#admin-login-portal) in the `/login/admin` path e.g. https://app.infisical.com/login/admin.
|
||||
</Info>
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
@@ -97,7 +97,7 @@ description: "Learn how to configure Keycloak OIDC for Infisical SSO."
|
||||
prior to enforcing OIDC SSO to prevent any unintended issues.
|
||||
</Warning>
|
||||
<Info>
|
||||
In case of a lockout, an organization admin can use the admin login portal in the `/login/admin` path e.g. https://app.infisical.com/login/admin.
|
||||
In case of a lockout, an organization admin can use the [Admin Login Portal](https://infisical.com/docs/documentation/platform/sso/overview#admin-login-portal) in the `/login/admin` path e.g. https://app.infisical.com/login/admin.
|
||||
</Info>
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
@@ -5,7 +5,7 @@ description: "Learn how to configure Keycloak SAML for Infisical SSO."
|
||||
|
||||
<Info>
|
||||
Keycloak SAML SSO is a paid feature.
|
||||
|
||||
|
||||
If you're using Infisical Cloud, then it is available under the **Pro Tier**. If you're self-hosting Infisical,
|
||||
then you should contact sales@infisical.com to purchase an enterprise license to use it.
|
||||
</Info>
|
||||
@@ -13,36 +13,36 @@ description: "Learn how to configure Keycloak SAML for Infisical SSO."
|
||||
<Steps>
|
||||
<Step title="Prepare the SAML SSO configuration in Infisical">
|
||||
In Infisical, head to the **Single Sign-On (SSO)** page and select the **General** tab. Click **Connect** for **SAML** under the Connect to an Identity Provider section. Select **Keycloak**, then click **Connect** again.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Next, copy the **Valid redirect URI** and **SP Entity ID** to use when configuring the Keycloak SAML application.
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Create a SAML client application in Keycloak">
|
||||
2.1. In your realm, navigate to the **Clients** tab and click **Create client** to create a new client application.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<Info>
|
||||
You don’t typically need to make a realm dedicated to Infisical. We recommend adding Infisical as a client to your primary realm.
|
||||
</Info>
|
||||
|
||||
|
||||
In the General Settings step, set **Client type** to **SAML**, the **Client ID** field to `https://app.infisical.com`, and the **Name** field to a friendly name like **Infisical**.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<Info>
|
||||
If you’re self-hosting Infisical, then you will want to replace https://app.infisical.com with your own domain.
|
||||
</Info>
|
||||
|
||||
|
||||
Next, in the Login Settings step, set both the **Home URL** field and **Valid redirect URIs** field to the **Valid redirect URI** from step 1 and press **Save**.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
2.2. Once you've created the client, under its **Settings** tab, make sure to set the following values:
|
||||
|
||||
|
||||
- Under **SAML Capabilities**:
|
||||
- Name ID format: email (or username).
|
||||
- Force name ID format: On.
|
||||
@@ -54,59 +54,59 @@ description: "Learn how to configure Keycloak SAML for Infisical SSO."
|
||||
- Signature algorithm: RSA_SHA256.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
2.3. Next, navigate to the **Client scopes** tab select the client's dedicated scope.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Next click **Add predefined mapper**.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Select the **X500 email**, **X500 givenName**, and **X500 surname** attributes and click **Add**.
|
||||
|
||||
|
||||
|
||||
|
||||
Now click on the **X500 email** mapper and set the **SAML Attribute Name** field to **email**.
|
||||
|
||||
Now click on the **X500 email** mapper and set the **SAML Attribute Name** field to **email**.
|
||||
|
||||
|
||||
|
||||
|
||||
Repeat the same for **X500 givenName** and **X500 surname** mappers, setting the **SAML Attribute Name** field to **firstName** and **lastName** respectively.
|
||||
|
||||
|
||||
Next, back in the client scope's **Mappers**, click **Add mapper** and select **by configuration**.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Select **User Property**.
|
||||
|
||||
|
||||
|
||||
|
||||
Set the the **Name** field to **Username**, the **Property** field to **username**, and the **SAML Attribtue Name** to **username**.
|
||||
|
||||
Set the the **Name** field to **Username**, the **Property** field to **username**, and the **SAML Attribute Name** to **username**.
|
||||
|
||||
|
||||
|
||||
|
||||
Repeat the same for the `id` attribute, setting the **Name** field to **ID**, the **Property** field to **id**, and the **SAML Attribute Name** to **id**.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Once you've completed the above steps, the list of mappers should look like this:
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Retrieve Identity Provider (IdP) Information from Keycloak">
|
||||
Back in Keycloak, navigate to Configure > Realm settings > General tab > Endpoints > SAML 2.0 Identity Provider Metadata and copy the IDP URL. This should appear in various places and take the form: `https://keycloak-mysite.com/realms/myrealm/protocol/saml`.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Also, in the **Keys** tab, locate the RS256 key and copy the certificate to use when finishing configuring Keycloak SAML in Infisical.
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Finish configuring SAML in Infisical">
|
||||
Back in Infisical, set **IDP URL** and **Certificate** to the items from step 3. Also, set the **Client ID** to the `https://app.infisical.com`.
|
||||
|
||||
|
||||
Once you've done that, press **Update** to complete the required configuration.
|
||||
|
||||
|
||||
@@ -119,7 +119,7 @@ description: "Learn how to configure Keycloak SAML for Infisical SSO."
|
||||
<Step title="Enforce SAML SSO in Infisical">
|
||||
Enforcing SAML SSO ensures that members in your organization can only access Infisical
|
||||
by logging into the organization via Keycloak.
|
||||
|
||||
|
||||
To enforce SAML SSO, you're required to test out the SAML connection by successfully authenticating at least one Keycloak user with Infisical;
|
||||
Once you've completed this requirement, you can toggle the **Enforce SAML SSO** button to enforce SAML SSO.
|
||||
|
||||
@@ -128,7 +128,7 @@ description: "Learn how to configure Keycloak SAML for Infisical SSO."
|
||||
prior to enforcing SAML SSO to prevent any unintended issues.
|
||||
</Warning>
|
||||
<Info>
|
||||
In case of a lockout, an organization admin can use the admin login portal in the `/login/admin` path e.g. https://app.infisical.com/login/admin.
|
||||
In case of a lockout, an organization admin can use the [Admin Login Portal](https://infisical.com/docs/documentation/platform/sso/overview#admin-login-portal) in the `/login/admin` path e.g. https://app.infisical.com/login/admin.
|
||||
</Info>
|
||||
</Step>
|
||||
</Steps>
|
||||
@@ -147,4 +147,4 @@ description: "Learn how to configure Keycloak SAML for Infisical SSO."
|
||||
32`.
|
||||
<div class="height:1px;"/>
|
||||
- `SITE_URL`: The absolute URL of your self-hosted instance of Infisical including the protocol (e.g. https://app.infisical.com)
|
||||
</Note>
|
||||
</Note>
|
||||
|
||||
@@ -93,13 +93,12 @@ description: "Learn how to configure Okta SAML 2.0 for Infisical SSO."
|
||||
Once you've completed this requirement, you can toggle the **Enforce SAML SSO** button to enforce SAML SSO.
|
||||
|
||||
<Warning>
|
||||
We recommend ensuring that your account is provisioned the application in Okta
|
||||
prior to enforcing SAML SSO to prevent any unintended issues.
|
||||
We recommend ensuring that your account is provisioned for the application in Okta prior to enforcing SAML SSO to prevent any unintended issues.
|
||||
</Warning>
|
||||
<Info>
|
||||
In case of a lockout, an organization admin can use the admin login portal in the `/login/admin` path e.g. https://app.infisical.com/login/admin.
|
||||
</Info>
|
||||
|
||||
<Info>
|
||||
In case of a lockout, an organization admin can use the [Admin Login Portal](https://infisical.com/docs/documentation/platform/sso/overview#admin-login-portal) in the `/login/admin` path e.g. https://app.infisical.com/login/admin.
|
||||
</Info>
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
|
||||
@@ -39,18 +39,30 @@ If your required identity provider is not shown in the list above, please reach
|
||||
For enhanced security, Infisical enforces PKCE (Proof Key for Code Exchange) with the OAuth 2.0-based SSO providers and OIDC. This provides additional protection against authorization code interception attacks and strengthens your authentication flow security.
|
||||
</Info>
|
||||
|
||||
## SSO Break Glass
|
||||
|
||||
In the event your SSO provider experiences downtime, and you need to access Infisical, Organization Admins can utilize the Admin Login Portal to bypass SSO enforcement.
|
||||
|
||||
This portal is accessible at `/login/admin` (e.g., https://app.infisical.com/login/admin).
|
||||
|
||||
<Note>
|
||||
To bypass SSO for an organization, you must be an **Organization Admin** for that specific organization. This **Organization Admin** role is independent of **Server Admin** status. Being a **Server Admin** alone does not grant permission to use this bypass feature.
|
||||
</Note>
|
||||
|
||||
## FAQ
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Why does Infisical require additional email verification for users connected via SAML?">
|
||||
By default, Infisical Cloud is configured to not trust emails from external
|
||||
identity providers to prevent any malicious account takeover attempts via
|
||||
email spoofing. Accordingly, Infisical creates a new user for anyone provisioned
|
||||
through an external identity provider and requires an additional email
|
||||
verification step upon their first login.
|
||||
<Accordion title="Why does Infisical require additional email verification for users connected via SAML?">
|
||||
By default, Infisical Cloud is configured to not trust emails from external
|
||||
identity providers to prevent any malicious account takeover attempts via
|
||||
email spoofing. Accordingly, Infisical creates a new user for anyone provisioned
|
||||
through an external identity provider and requires an additional email
|
||||
verification step upon their first login.
|
||||
|
||||
If you're running a self-hosted instance of Infisical and would like it to trust emails from external identity providers,
|
||||
you can configure this behavior in the Server Admin Console.
|
||||
|
||||
</Accordion>
|
||||
If you're running a self-hosted instance of Infisical and would like it to trust emails from external identity providers,
|
||||
you can configure this behavior in the Server Admin Console.
|
||||
</Accordion>
|
||||
<Accordion title="Why do I get redirected to SSO when trying to use the Admin Login Portal?">
|
||||
You are likely being redirected because you do not have email authentication mode enabled, or you're not an **Organization Admin**. This portal requires **Organization Admin** status and direct credential login (email and password). **Server Admin** status alone is insufficient.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
Reference in New Issue
Block a user