Merge branch 'main' into feat/point-in-time-revamp

2026-10-08 20:28:16 +00:00 · 2025-06-05 18:31:27 -03:00
parent d5f5abef8e ce170a6a47
commit 6334ad0d07
757 changed files with 31611 additions and 4112 deletions
@@ -0,0 +1,4 @@
+---
+title: "Available"
+openapi: "GET /api/v1/app-connections/github-radar/available"
+---
@@ -0,0 +1,10 @@
+---
+title: "Create"
+openapi: "POST /api/v1/app-connections/github-radar"
+---
+
+<Note>
+    GitHub Radar Connections must be created through the Infisical UI.
+    Check out the configuration docs for [GitHub Radar Connections](/integrations/app-connections/github-radar) for a step-by-step
+    guide.
+</Note>
@@ -0,0 +1,4 @@
+---
+title: "Delete"
+openapi: "DELETE /api/v1/app-connections/github-radar/{connectionId}"
+---
@@ -0,0 +1,4 @@
+---
+title: "Get by ID"
+openapi: "GET /api/v1/app-connections/github-radar/{connectionId}"
+---
@@ -0,0 +1,4 @@
+---
+title: "Get by Name"
+openapi: "GET /api/v1/app-connections/github-radar/connection-name/{connectionName}"
+---
@@ -0,0 +1,4 @@
+---
+title: "List"
+openapi: "GET /api/v1/app-connections/github-radar"
+---
@@ -0,0 +1,10 @@
+---
+title: "Update"
+openapi: "PATCH /api/v1/app-connections/github-radar/{connectionId}"
+---
+
+<Note>
+    GitHub Radar Connections must be updated through the Infisical UI.
+    Check out the configuration docs for [GitHub Radar Connections](/integrations/app-connections/github-radar) for a step-by-step
+    guide.
+</Note>
@@ -0,0 +1,4 @@
+---
+title: "Available"
+openapi: "GET /api/v1/app-connections/mysql/available"
+---
@@ -0,0 +1,8 @@
+---
+title: "Create"
+openapi: "POST /api/v1/app-connections/mysql"
+---
+
+<Note>
+    Check out the configuration docs for [MySQL Connections](/integrations/app-connections/mysql) to learn how to obtain the required credentials.
+</Note>
@@ -0,0 +1,4 @@
+---
+title: "Delete"
+openapi: "DELETE /api/v1/app-connections/mysql/{connectionId}"
+---
@@ -0,0 +1,4 @@
+---
+title: "Get by ID"
+openapi: "GET /api/v1/app-connections/mysql/{connectionId}"
+---
@@ -0,0 +1,4 @@
+---
+title: "Get by Name"
+openapi: "GET /api/v1/app-connections/mysql/connection-name/{connectionName}"
+---
@@ -0,0 +1,4 @@
+---
+title: "List"
+openapi: "GET /api/v1/app-connections/mysql"
+---
@@ -0,0 +1,8 @@
+---
+title: "Update"
+openapi: "PATCH /api/v1/app-connections/mysql/{connectionId}"
+---
+
+<Note>
+    Check out the configuration docs for [MySQL Connections](/integrations/app-connections/mysql) to learn how to obtain the required credentials.
+</Note>
@@ -0,0 +1,8 @@
+---
+title: "Create"
+openapi: "POST /api/v2/secret-rotations/mysql-credentials"
+---
+
+<Note>
+    Check out the configuration docs for [MySQL Credentials Rotations](/documentation/platform/secret-rotation/mysql-credentials) to learn how to obtain the required parameters.
+</Note>
@@ -0,0 +1,4 @@
+---
+title: "Delete"
+openapi: "DELETE /api/v2/secret-rotations/mysql-credentials/{rotationId}"
+---
@@ -0,0 +1,4 @@
+---
+title: "Get by ID"
+openapi: "GET /api/v2/secret-rotations/mysql-credentials/{rotationId}"
+---
@@ -0,0 +1,4 @@
+---
+title: "Get by Name"
+openapi: "GET /api/v2/secret-rotations/mysql-credentials/rotation-name/{rotationName}"
+---
@@ -0,0 +1,4 @@
+---
+title: "Get Credentials by ID"
+openapi: "GET /api/v2/secret-rotations/mysql-credentials/{rotationId}/generated-credentials"
+---
@@ -0,0 +1,4 @@
+---
+title: "List"
+openapi: "GET /api/v2/secret-rotations/mysql-credentials"
+---
@@ -0,0 +1,4 @@
+---
+title: "Rotate Secrets"
+openapi: "POST /api/v2/secret-rotations/mysql-credentials/{rotationId}/rotate-secrets"
+---
@@ -0,0 +1,8 @@
+---
+title: "Update"
+openapi: "PATCH /api/v2/secret-rotations/mysql-credentials/{rotationId}"
+---
+
+<Note>
+    Check out the configuration docs for [MySQL Credentials Rotations](/documentation/platform/secret-rotation/mysql-credentials) to learn how to obtain the required parameters.
+</Note>
@@ -0,0 +1,4 @@
+---
+title: "Get by Project ID"
+openapi: "GET /api/v2/secret-scanning/configs"
+---
@@ -0,0 +1,8 @@
+---
+title: "Update"
+openapi: "PATCH /api/v2/secret-scanning/configs"
+---
+
+<Note>
+    Check out the [Configuration Docs](/documentation/platform/secret-scanning/overview#configuration) for an in-depth guide on custom configurations.
+</Note>
@@ -0,0 +1,4 @@
+---
+title: "Create"
+openapi: "POST /api/v2/secret-scanning/data-sources/github"
+---
@@ -0,0 +1,4 @@
+---
+title: "Delete"
+openapi: "DELETE /api/v2/secret-scanning/data-sources/github/{dataSourceId}"
+---
@@ -0,0 +1,4 @@
+---
+title: "Get by ID"
+openapi: "GET /api/v2/secret-scanning/data-sources/github/{dataSourceId}"
+---
@@ -0,0 +1,4 @@
+---
+title: "Get by Name"
+openapi: "GET /api/v2/secret-scanning/data-sources/github/data-source-name/{dataSourceName}"
+---
@@ -0,0 +1,4 @@
+---
+title: "List Resources"
+openapi: "GET /api/v2/secret-scanning/data-sources/github/{dataSourceId}/resources"
+---
@@ -0,0 +1,4 @@
+---
+title: "List Scans"
+openapi: "GET /api/v2/secret-scanning/data-sources/github/{dataSourceId}/scans"
+---
@@ -0,0 +1,4 @@
+---
+title: "List"
+openapi: "GET /api/v2/secret-scanning/data-sources/github"
+---
@@ -0,0 +1,4 @@
+---
+title: "Scan Resource"
+openapi: "POST /api/v2/secret-scanning/data-sources/github/{dataSourceId}/resources/{resourceId}/scan"
+---
@@ -0,0 +1,4 @@
+---
+title: "Scan"
+openapi: "POST /api/v2/secret-scanning/data-sources/github/{dataSourceId}/scan"
+---
@@ -0,0 +1,4 @@
+---
+title: "Update"
+openapi: "PATCH /api/v2/secret-scanning/data-sources/github/{dataSourceId}"
+---
@@ -0,0 +1,4 @@
+---
+title: "List"
+openapi: "GET /api/v2/secret-scanning/data-sources"
+---
@@ -0,0 +1,4 @@
+---
+title: "Options"
+openapi: "GET /api/v2/secret-scanning/data-sources/options"
+---
@@ -0,0 +1,4 @@
+---
+title: "List"
+openapi: "GET /api/v2/secret-scanning/findings"
+---
@@ -0,0 +1,4 @@
+---
+title: "Update"
+openapi: "PATCH /api/v2/secret-scanning/findings/{findingId}"
+---
@@ -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">
 	![Add Dynamic Secret Button](../../../images/platform/dynamic-secrets/add-dynamic-secret-button.png)
  </Step>
-  <Step title="Select 'AWS ElastiCache'">
+  <Step title="Select AWS ElastiCache">
 	![Dynamic Secret Modal](../../../images/platform/dynamic-secrets/dynamic-secret-modal-aws-elasti-cache.png)
  </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).
+  ![Modify ElastiCache Statements Modal](/images/platform/dynamic-secrets/modify-elasticache-statement.png)
+   <ParamField path="Username Template" type="string" default="{{randomUsername}}">
+       Specifies a template for generating usernames. This field allows customization of how usernames are automatically created.

-	![Modify ElastiCache Statements Modal](/images/platform/dynamic-secrets/modify-elasticache-statement.png)
+       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.

 	![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-generate-redis.png)
@@ -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.

 	![Provision Lease](/images/platform/dynamic-secrets/lease-values.png)
  </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.

 ![Provision Lease](/images/platform/dynamic-secrets/lease-data.png)
@@ -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>

 	![Dynamic Secret Setup Modal](../../../images/platform/dynamic-secrets/dynamic-secret-setup-modal-aws-iam.png)

  </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.

 	![Dynamic Secret](../../../images/platform/dynamic-secrets/dynamic-secret.png)
  </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.

 	![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-generate.png)
@@ -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.

 	![Provision Lease](/images/platform/dynamic-secrets/lease-values-aws-iam.png)
  </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.

 ![Provision Lease](/images/platform/dynamic-secrets/lease-data.png)
@@ -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>

 	![Dynamic Secret Setup Modal](../../../images/platform/dynamic-secrets/dynamic-secret-setup-modal-cassandra.png)

  </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).
+  ![Modify CQL Statements Modal](../../../images/platform/dynamic-secrets/modify-cql-statements.png)
+  <ParamField path="Username Template" type="string" default="{{randomUsername}}">
+       Specifies a template for generating usernames. This field allows customization of how usernames are automatically created.

-	![Modify CQL Statements Modal](../../../images/platform/dynamic-secrets/modify-cql-statements.png)
+       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>

 	![Dynamic Secret](../../../images/platform/dynamic-secrets/dynamic-secret.png)
  </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.

 	![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-generate.png)
@@ -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.

 	![Provision Lease](/images/platform/dynamic-secrets/lease-values.png)
  </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.

 ![Provision Lease](/images/platform/dynamic-secrets/lease-data.png)
@@ -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.

-  	![Dynamic Secret Setup Modal](../../../images/platform/dynamic-secrets/dynamic-secret-input-modal-elastic-search.png)
+      Allowed template variables are
+      - `{{randomUsername}}`: Random username string
+      - `{{unixTimestamp}}`: Current Unix timestamp
+    </ParamField>

+![Dynamic Secret Setup Modal](../../../images/platform/dynamic-secrets/dynamic-secret-input-modal-elastic-search.png)

  </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.

-	![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-generate-redis.png)
-	![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-lease-empty-redis.png)
+    ![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-generate-redis.png)
+    ![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-lease-empty-redis.png)

-	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.

-	![Provision Lease](/images/platform/dynamic-secrets/provision-lease.png)
+    ![Provision Lease](/images/platform/dynamic-secrets/provision-lease.png)

-	<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.
+
+    ![Provision Lease](/images/platform/dynamic-secrets/lease-values.png)

-	![Provision Lease](/images/platform/dynamic-secrets/lease-values.png)
  </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.

 ![Provision Lease](/images/platform/dynamic-secrets/lease-data.png)

 ## 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.
 ![Provision Lease](/images/platform/dynamic-secrets/dynamic-secret-lease-renew.png)

 <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>
@@ -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">
+    ![Add Dynamic Secret Button](/images/platform/dynamic-secrets/add-dynamic-secret-button.png)
+  </Step>
+  <Step title="Select Kubernetes">
+    ![Dynamic Secret Modal](/images/platform/dynamic-secrets/dynamic-secret-modal-kubernetes.png)
+  </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>
+
+    ![Dynamic Secret Setup Modal](../../../images/platform/dynamic-secrets/dynamic-secret-setup-modal-kubernetes.png)
+
+  </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.
+
+    ![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-generate.png)
+    ![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-lease-empty.png)
+
+    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.
+
+    ![Provision Lease](/images/platform/dynamic-secrets/provision-lease.png)
+
+    <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.
+
+    ![Provision Lease](/images/platform/dynamic-secrets/kubernetes-lease-value.png)
+
+  </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>
+
+![Provision Lease](/images/platform/dynamic-secrets/lease-data.png)
@@ -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>

-	![Dynamic Secret Setup Modal](../../../images/platform/dynamic-secrets/dynamic-secret-modal-atlas.png)
+    ![Dynamic Secret Setup Modal](../../../images/platform/dynamic-secrets/dynamic-secret-modal-atlas.png)

  </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.

-				![Modify Scope Modal](../../../images/platform/dynamic-secrets/advanced-option-atlas.png)
-				- **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.
+![Modify Scope Modal](../../../images/platform/dynamic-secrets/advanced-option-atlas.png)
+
+   <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>
+
+    ![Dynamic Secret](../../../images/platform/dynamic-secrets/dynamic-secret.png)

-	![Dynamic Secret](../../../images/platform/dynamic-secrets/dynamic-secret.png)
  </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.

-	![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-generate.png)
-	![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-lease-empty.png)
+    ![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-generate.png)
+    ![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-lease-empty.png)

-	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.

-	![Provision Lease](/images/platform/dynamic-secrets/provision-lease.png)
+    ![Provision Lease](/images/platform/dynamic-secrets/provision-lease.png)

-	<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.
+
+    ![Provision Lease](/images/platform/dynamic-secrets/lease-values.png)

-	![Provision Lease](/images/platform/dynamic-secrets/lease-values.png)
  </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.

 ![Provision Lease](/images/platform/dynamic-secrets/lease-data.png)

 ## 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.
 ![Provision Lease](/images/platform/dynamic-secrets/dynamic-secret-lease-renew.png)

 <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>

 	![Dynamic Secret Setup Modal](../../../images/platform/dynamic-secrets/dynamic-secret-mongodb.png)
 	</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.

 	![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-generate.png)
@@ -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.

 	![Provision Lease](/images/platform/dynamic-secrets/lease-values.png)
  </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.

 ![Provision Lease](/images/platform/dynamic-secrets/lease-data.png)
@@ -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).
+  ![Modify SQL Statements Modal](../../../images/platform/dynamic-secrets/modify-sql-statements-mssql.png)
+  <ParamField path="Username Template" type="string" default="{{randomUsername}}">
+       Specifies a template for generating usernames. This field allows customization of how usernames are automatically created.

-	![Modify SQL Statements Modal](../../../images/platform/dynamic-secrets/modify-sql-statements-mssql.png)
+       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>

 	![Dynamic Secret](../../../images/platform/dynamic-secrets/dynamic-secret.png)
  </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.

 	![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-generate.png)
@@ -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.

 	![Provision Lease](/images/platform/dynamic-secrets/lease-values.png)
  </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.

 ![Provision Lease](/images/platform/dynamic-secrets/lease-data.png)
@@ -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).
+  ![Modify SQL Statements Modal](../../../images/platform/dynamic-secrets/modify-sql-statement-mysql.png)
+  <ParamField path="Username Template" type="string" default="{{randomUsername}}">
+       Specifies a template for generating usernames. This field allows customization of how usernames are automatically created.

-	![Modify SQL Statements Modal](/images/platform/dynamic-secrets/modify-sql-statement-mysql.png)
+       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>

 	![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret.png)
  </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.

 	![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-generate.png)
@@ -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.

 	![Provision Lease](/images/platform/dynamic-secrets/lease-values.png)
  </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.

 ![Provision Lease](/images/platform/dynamic-secrets/lease-data.png)
@@ -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">
+	![Modify SQL Statements Modal](../../../images/platform/dynamic-secrets/modify-sql-statement-oracle.png)
+	<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>

 	![Dynamic Secret](../../../images/platform/dynamic-secrets/dynamic-secret.png)
  </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.

 	![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-generate.png)
@@ -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.

 	![Provision Lease](/images/platform/dynamic-secrets/lease-values.png)
  </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.

 ![Provision Lease](/images/platform/dynamic-secrets/lease-data.png)
@@ -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).
-
 	![Modify SQL Statements Modal](../../../images/platform/dynamic-secrets/modify-sql-statements.png)
+	<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>

 	![Dynamic Secret](../../../images/platform/dynamic-secrets/dynamic-secret.png)
  </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.

 	![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-generate.png)
@@ -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.

 	![Provision Lease](/images/platform/dynamic-secrets/lease-values.png)
  </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.

 ![Provision Lease](/images/platform/dynamic-secrets/lease-data.png)
@@ -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">
 	![Add Dynamic Secret Button](../../../images/platform/dynamic-secrets/add-dynamic-secret-button.png)
  </Step>
-  <Step title="Select 'RabbitMQ'">
-	![Dynamic Secret Modal](../../../images/platform/dynamic-secrets/dynamic-secret-modal-rabbit-mq.png)
+  <Step title="Select RabbitMQ">
+	![Dynamic Secret Modal](../../../images/platform/dynamic-secrets/dynamic-secret-rabbit-mq-modal.png)
  </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>

-  	![Dynamic Secret Setup Modal](../../../images/platform/dynamic-secrets/dynamic-secret-input-modal-rabbit-mq.png)
+<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>

+![Dynamic Secret Setup Modal](../../../images/platform/dynamic-secrets/dynamic-secret-input-modal-rabbit-mq.png)

  </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.

-	![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-generate-redis.png)
-	![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-lease-empty-redis.png)
+    ![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-generate-redis.png)
+    ![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-lease-empty-redis.png)

-	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.

-	![Provision Lease](/images/platform/dynamic-secrets/provision-lease.png)
+    ![Provision Lease](/images/platform/dynamic-secrets/provision-lease.png)

-	<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.
+
+    ![Provision Lease](/images/platform/dynamic-secrets/lease-values.png)

-	![Provision Lease](/images/platform/dynamic-secrets/lease-values.png)
  </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.

 ![Provision Lease](/images/platform/dynamic-secrets/lease-data.png)

 ## 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.
 ![Provision Lease](/images/platform/dynamic-secrets/dynamic-secret-lease-renew.png)

 <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).
+  ![Modify Redis Statements Modal](/images/platform/dynamic-secrets/modify-redis-statement.png)
+   <ParamField path="Username Template" type="string" default="{{randomUsername}}">
+       Specifies a template for generating usernames. This field allows customization of how usernames are automatically created.

-	![Modify Redis Statements Modal](/images/platform/dynamic-secrets/modify-redis-statement.png)
+       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.

 	![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-generate-redis.png)
@@ -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.

 	![Provision Lease](/images/platform/dynamic-secrets/lease-values.png)
  </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.

 ![Provision Lease](/images/platform/dynamic-secrets/lease-data.png)
@@ -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
    ![Dynamic Secret Setup Modal](../../../images/platform/dynamic-secrets/sap-ase/dynamic-secret-sap-ase-setup-modal.png)

  </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">
    ![Modify SQL Statements Modal](../../../images/platform/dynamic-secrets/sap-ase/dynamic-secret-sap-ase-statements.png)
+    <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.

    ![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-generate.png)
@@ -62,14 +62,25 @@ The Infisical SAP HANA dynamic secret allows you to generate SAP HANA database c
    ![Dynamic Secret Setup Modal](../../../images/platform/dynamic-secrets/dynamic-secret-setup-modal-sap-hana.png)

  </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.
-    ![Modify SQL Statements Modal](../../../images/platform/dynamic-secrets/modify-sap-hana-sql-statements.png)
+  <Step title="(Optional) Modify SAP SQL Statements">
+  ![Modify SQL Statements Modal](../../../images/platform/dynamic-secrets/modify-sap-hana-sql-statements.png)
+    <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.

    ![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-generate.png)
@@ -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">
-        ![Snowflake User Dashboard](/images/platform/dynamic-secrets/snowflake/dynamic-secret-snowflake-users-page.png)
-    </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>
-        ![Snowflake Create Service User](/images/platform/dynamic-secrets/snowflake/dynamic-secret-snowflake-create-service-user.png)
-    </Step>
-    <Step title="Click on the Account Menu in the bottom left and take note of your Account and Organization identifiers">
-        ![Snowflake Account And Organization Identifiers](/images/platform/dynamic-secrets/snowflake/dynamic-secret-snowflake-identifiers.png)
-    </Step>
+  <Step title="Navigate to Snowflake's User Dashboard and press the '+ User' button">
+    ![Snowflake User
+    Dashboard](/images/platform/dynamic-secrets/snowflake/dynamic-secret-snowflake-users-page.png)
+  </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>
+    ![Snowflake Create Service
+    User](/images/platform/dynamic-secrets/snowflake/dynamic-secret-snowflake-create-service-user.png)
+  </Step>
+  <Step title="Click on the Account Menu in the bottom left and take note of your Account and Organization identifiers">
+    ![Snowflake Account And Organization
+    Identifiers](/images/platform/dynamic-secrets/snowflake/dynamic-secret-snowflake-identifiers.png)
+  </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.
        ![Modify SQL Statements Modal](/images/platform/dynamic-secrets/snowflake/dynamic-secret-snowflake-sql-statements.png)
-    </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
        ![Provision Lease](/images/platform/dynamic-secrets/lease-values.png)

    </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
 ![Provision Lease](/images/platform/dynamic-secrets/dynamic-secret-lease-renew.png)

 <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>
@@ -0,0 +1,134 @@
+---
+title: "Vertica"
+description: "Learn how to dynamically generate Vertica database users."
+---
+
+The Infisical Vertica dynamic secret allows you to generate Vertica database credentials on demand based on configured role.
+
+## Prerequisite
+
+Create a user with the required permission in your Vertica instance. This user will be used to create new accounts on-demand.
+
+## Set up Dynamic Secrets with Vertica
+
+<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">
+	![Add Dynamic Secret Button](../../../images/platform/dynamic-secrets/add-dynamic-secret-button.png)
+  </Step>
+  <Step title="Select `Vertica`">
+	![Dynamic Secret Modal](../../../images/platform/dynamic-secrets/vertica/dynamic-secret-modal-vertica.png)
+  </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="Host" type="string" required>
+		Vertica database host
+	</ParamField>
+
+	<ParamField path="Port" type="number" required>
+		Vertica database port (default: 5433)
+	</ParamField>
+
+	<ParamField path="Database" type="string" required>
+		Name of the Vertica database for which you want to create dynamic secrets
+	</ParamField>
+
+	<ParamField path="User" type="string" required>
+		Username that will be used to create dynamic secrets
+	</ParamField>
+
+	<ParamField path="Password" type="string" required>
+		Password that will be used to create dynamic secrets
+	</ParamField>
+
+	![Dynamic Secret Setup Modal](../../../images/platform/dynamic-secrets/vertica/dynamic-secret-setup-modal-vertica.png)
+
+  </Step>
+  <Step title="(Optional) Modify SQL Statements">
+	![Modify SQL Statements Modal](../../../images/platform/dynamic-secrets/vertica/modify-sql-statements-vertica.png)
+	<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="Creation Statement" type="string">
+  	Customize the SQL statement used to create new users. Default creates a user with basic schema permissions.
+	</ParamField>
+	<ParamField path="Revocation Statement" type="string">
+  	Customize the SQL statement used to revoke users. Default revokes a user.
+	</ParamField>
+  </Step>
+  <Step title="(Optional) Configure Password Requirements">
+	<ParamField path="Password Length" type="number" default="48">
+		Length of generated passwords (1-250 characters)
+	</ParamField>
+	<ParamField path="Character Requirements" type="object">
+		Minimum required character counts:
+		- **Lowercase Count**: Minimum lowercase letters (default: 1)
+		- **Uppercase Count**: Minimum uppercase letters (default: 1) 
+		- **Digit Count**: Minimum digits (default: 1)
+		- **Symbol Count**: Minimum symbols (default: 0)
+	</ParamField>
+	<ParamField path="Allowed Symbols" type="string" default="-_.~!*">
+		Symbols allowed in generated passwords
+	</ParamField>
+  </Step>
+  <Step title="Click 'Submit'">
+  	After submitting the form, you will see a dynamic secret created in the dashboard.
+
+	![Dynamic Secret](../../../images/platform/dynamic-secrets/vertica/dynamic-secret-vertica.png)
+  </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.
+	Alternatively, you can initiate the creation of a new lease by selecting 'New Lease' from the dynamic secret lease list section.
+
+	![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-generate.png)
+	![Dynamic Secret](/images/platform/dynamic-secrets/dynamic-secret-lease-empty.png)
+
+	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.
+
+	![Provision Lease](/images/platform/dynamic-secrets/provision-lease.png)
+
+	<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.
+
+	![Provision Lease](/images/platform/dynamic-secrets/lease-values.png)
+  </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 expiration time of the lease or delete the lease before its set time to live.
+
+![Provision Lease](/images/platform/dynamic-secrets/lease-data.png)
+
+## 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.
+![Provision Lease](/images/platform/dynamic-secrets/dynamic-secret-lease-renew.png)
+
+<Warning>
+	Lease renewals cannot exceed the maximum TTL set when configuring the dynamic secret
+</Warning>
@@ -89,22 +89,3 @@ The relay system provides secure tunneling:
   - Gateways only accept connections to approved resources
   - Each connection requires explicit project authorization
   - Resources remain private to their assigned organization
-
-## Security Measures
-
-### Certificate Lifecycle
- Certificates have limited validity periods
- Automatic certificate rotation
- Immediate certificate revocation capabilities
-
-### Monitoring and Verification
-1. **Continuous Verification**:
-   - Regular heartbeat checks
-   - Certificate chain validation
-   - Connection state monitoring
-
-2. **Security Controls**:
-   - Automatic connection termination on verification failure
-   - Audit logging of all access attempts
-   - Machine identity based authentication
-
@@ -0,0 +1,168 @@
+---
+title: "Networking"
+description: "Network configuration and firewall requirements for Infisical Gateway"
+---
+
+The Infisical Gateway requires outbound network connectivity to establish secure communication with Infisical's relay infrastructure. 
+This page outlines the required ports, protocols, and firewall configurations needed for optimal gateway usage.
+
+## Network Architecture
+
+The gateway uses a relay-based architecture to establish secure connections:
+
+1. **Gateway** connects outbound to **Relay Servers** using UDP/QUIC protocol
+2. **Relay Servers** facilitate secure communication between Gateway and Infisical Cloud
+3. All traffic is end-to-end encrypted using mutual TLS over QUIC
+
+## Required Network Connectivity
+
+### Outbound Connections (Required)
+
+The gateway requires the following outbound connectivity:
+
+| Protocol | Destination | Ports | Purpose |
+|----------|-------------|-------|---------|
+| UDP | Relay Servers | 49152-65535 | Allocated relay communication (TLS) |
+| TCP | app.infisical.com / eu.infisical.com | 443 | API communication and relay allocation |
+
+### Relay Server IP Addresses
+
+Your firewall must allow outbound connectivity to the following Infisical relay servers on dynamically allocated ports.
+
+<Tabs>
+  <Tab title="Infisical cloud (US)">
+    ```
+    54.235.197.91:49152-65535
+    18.215.196.229:49152-65535
+    3.222.120.233:49152-65535
+    34.196.115.157:49152-65535
+    ```
+  </Tab>
+  <Tab title="Infisical cloud (EU)">
+    ```
+    3.125.237.40:49152-65535
+    52.28.157.98:49152-65535
+    3.125.176.90:49152-65535
+    ```
+  </Tab>
+  <Tab title="Infisical dedicated">
+    Please contact your Infisical account manager for dedicated relay server IP addresses.
+  </Tab>
+</Tabs>
+
+<Warning>
+    These IP addresses are static and managed by Infisical. Any changes will be communicated with 60-day advance notice.
+</Warning>
+
+## Protocol Details
+
+### QUIC over UDP
+
+The gateway uses QUIC (Quick UDP Internet Connections) for primary communication:
+
+- **Port 5349**: STUN/TURN over TLS (secure relay communication)
+- **Built-in features**: Connection migration, multiplexing, reduced latency
+- **Encryption**: TLS 1.3 with certificate pinning
+
+## Understanding Firewall Behavior with UDP
+
+Unlike TCP connections, UDP is a stateless protocol, and depending on your organization's firewall configuration, you may need to adjust network rules accordingly.
+When the gateway sends UDP packets to a relay server, the return responses need to be allowed back through the firewall. 
+Modern firewalls handle this through "connection tracking" (also called "stateful inspection"), but the behavior can vary depending on your firewall configuration. 
+
+
+### Connection Tracking 
+
+Modern firewalls automatically track UDP connections and allow return responses. This is the preferred configuration as it:
+- Automatically handles return responses
+- Reduces firewall rule complexity
+- Avoids the need for manual IP whitelisting
+
+In the event that your firewall does not support connection tracking, you will need to whitelist the relay IPs to explicitly define return traffic manually.
+
+## Common Network Scenarios
+
+### Corporate Firewalls
+
+For corporate environments with strict egress filtering:
+
+1. **Whitelist relay IP addresses** (listed above)
+2. **Allow UDP port 5349** outbound
+3. **Configure connection tracking** for UDP return traffic
+4. **Allow ephemeral port range** 49152-65535 for return traffic if connection tracking is disabled
+
+### Cloud Environments (AWS/GCP/Azure)
+
+Configure security groups to allow:
+- **Outbound UDP** to relay IPs on port 5349
+- **Outbound HTTPS** to app.infisical.com/eu.infisical.com on port 443
+- **Inbound UDP** on ephemeral ports (if not using stateful rules)
+
+## Frequently Asked Questions
+
+<Accordion title="What happens if there is a network interruption?">
+The gateway is designed to handle network interruptions gracefully:
+
+- **Automatic reconnection**: The gateway will automatically attempt to reconnect to relay servers every 5 seconds if the connection is lost
+- **Connection retry logic**: Built-in retry mechanisms handle temporary network outages without manual intervention
+- **Multiple relay servers**: If one relay server is unavailable, the gateway can connect to alternative relay servers
+- **Persistent sessions**: Existing connections are maintained where possible during brief network interruptions
+- **Graceful degradation**: The gateway logs connection issues and continues attempting to restore connectivity
+
+No manual intervention is typically required during network interruptions.
+</Accordion>
+
+<Accordion title="Why does the gateway use QUIC instead of TCP?">
+QUIC (Quick UDP Internet Connections) provides several advantages over traditional TCP for gateway communication:
+
+- **Faster connection establishment**: QUIC combines transport and security handshakes, reducing connection setup time
+- **Built-in encryption**: TLS 1.3 is integrated into the protocol, ensuring all traffic is encrypted by default
+- **Connection migration**: QUIC connections can survive IP address changes (useful for NAT rebinding)
+- **Reduced head-of-line blocking**: Multiple data streams can be multiplexed without blocking each other
+- **Better performance over unreliable networks**: Advanced congestion control and packet loss recovery
+- **Lower latency**: Optimized for real-time communication between gateway and cloud services
+
+While TCP is stateful and easier for firewalls to track, QUIC's performance benefits outweigh the additional firewall configuration requirements.
+</Accordion>
+
+<Accordion title="Do I need to open any inbound ports on my firewall?">
+No inbound ports need to be opened. The gateway only makes outbound connections:
+
+- **Outbound UDP** to relay servers on ports 49152-65535
+- **Outbound HTTPS** to Infisical API endpoints
+- **Return responses** are handled by connection tracking or explicit IP whitelisting
+
+This design maintains security by avoiding the need for inbound firewall rules that could expose your network to external threats.
+</Accordion>
+
+<Accordion title="What if my firewall blocks the required UDP ports?">
+If your firewall has strict UDP restrictions:
+
+1. **Work with your network team** to allow outbound UDP to the specific relay IP addresses
+2. **Use explicit IP whitelisting** if connection tracking is disabled  
+3. **Consider network policy exceptions** for the gateway host
+4. **Monitor firewall logs** to identify which specific rules are blocking traffic
+
+The gateway requires UDP connectivity to function - TCP-only configurations are not supported.
+</Accordion>
+
+<Accordion title="How many relay servers does the gateway connect to?">
+The gateway connects to **one relay server at a time**:
+
+- **Single active connection**: Only one relay connection is established per gateway instance
+- **Automatic failover**: If the current relay becomes unavailable, the gateway will connect to an alternative relay
+- **Load distribution**: Different gateway instances may connect to different relay servers for load balancing
+- **No manual selection**: The Infisical API automatically assigns the optimal relay server based on availability and proximity
+
+You should whitelist all relay IP addresses to ensure proper failover functionality.
+</Accordion>
+<Accordion title="Can the relay servers decrypt traffic going through them?">
+No, relay servers cannot decrypt any traffic passing through them:
+
+- **End-to-end encryption**: All traffic between the gateway and Infisical Cloud is encrypted using mutual TLS with certificate pinning
+- **Relay acts as a tunnel**: The relay server only forwards encrypted packets - it has no access to encryption keys
+- **No data storage**: Relay servers do not store any traffic or network-identifiable information  
+- **Certificate isolation**: Each organization has its own private PKI system, ensuring complete tenant isolation
+
+The relay infrastructure is designed as a secure forwarding mechanism, similar to a VPN tunnel, where the relay provider cannot see the contents of the traffic flowing through it.
+</Accordion>
@@ -32,7 +32,7 @@ For detailed installation instructions, refer to the Infisical [CLI Installation
 To function, the Gateway must authenticate with Infisical. This requires a machine identity configured with the appropriate permissions to create and manage a Gateway.
 Once authenticated, the Gateway establishes a secure connection with Infisical to allow your private resources to be reachable.

-### Deployment process
+### Get started

 <Steps>
  <Step title="Create a Gateway Identity">
@@ -128,7 +128,7 @@ Once authenticated, the Gateway establishes a secure connection with Infisical t

      </Tab>

-      <Tab title="Development (direct)">
+      <Tab title="Local Installation (testing)">
        For development or testing, you can run the Gateway directly. Log in with your machine identity and start the Gateway in one command:
        ```bash
        infisical gateway --token $(infisical login --method=universal-auth --client-id=<> --client-secret=<> --plain)
@@ -52,10 +52,11 @@ Infisical is able to authenticate and interact with the TokenReview API by using

 In the following steps, we explore how to create and use identities for your applications in Kubernetes to access the Infisical API using the Kubernetes Auth authentication method.

+
+
 <Steps>
    <Step title="Obtaining the token reviewer JWT for Infisical">
-				<Tabs>
-					<Tab title="Option 1: Reviewer JWT Token">
+      <Accordion title="Option 1: Reviewer JWT Token">

        <Note>
        **When to use this option**: Choose this approach when you want centralized authentication management. Only one service account needs special permissions, and your application service accounts remain unchanged.
@@ -126,41 +127,91 @@ In the following steps, we explore how to create and use identities for your app
        ```

        Keep this JWT token handy as you will need it for the **Token Reviewer JWT** field when configuring the Kubernetes Auth authentication method for the identity in step 2.
+      </Accordion>

-</Tab>
-<Tab title="Option 2: Client JWT as Reviewer JWT Token">
+      <Accordion title="Option 2: Client JWT as Reviewer JWT Token">
+        <Note>
+        **When to use this option**: Choose this approach to eliminate long-lived tokens. This option simplifies Infisical configuration but requires each application service account to have elevated permissions.
+        </Note>

-    <Note>
-    **When to use this option**: Choose this approach to eliminate long-lived tokens. This option simplifies Infisical configuration but requires each application service account to have elevated permissions.
-    </Note>
+        The self-validation method eliminates the need for a separate long-lived reviewer JWT by using the same token for both authentication and validation. Instead of creating a dedicated reviewer service account, you'll grant the necessary permissions to each application service account.

-    The self-validation method eliminates the need for a separate long-lived reviewer JWT by using the same token for both authentication and validation. Instead of creating a dedicated reviewer service account, you'll grant the necessary permissions to each application service account.
+        For each service account that needs to authenticate with Infisical, add the `system:auth-delegator` role:

-    For each service account that needs to authenticate with Infisical, add the `system:auth-delegator` role:
+        ```yaml client-role-binding.yaml
+        apiVersion: rbac.authorization.k8s.io/v1
+        kind: ClusterRoleBinding
+        metadata:
+          name: infisical-client-binding-[your-app-name]
+        roleRef:
+          apiGroup: rbac.authorization.k8s.io
+          kind: ClusterRole
+          name: system:auth-delegator
+        subjects:
+          - kind: ServiceAccount
+            name: [your-app-service-account]
+            namespace: [your-app-namespace]
+        ```

-    ```yaml client-role-binding.yaml
-    apiVersion: rbac.authorization.k8s.io/v1
-    kind: ClusterRoleBinding
-    metadata:
-      name: infisical-client-binding-[your-app-name]
-    roleRef:
-      apiGroup: rbac.authorization.k8s.io
-      kind: ClusterRole
-      name: system:auth-delegator
-    subjects:
-      - kind: ServiceAccount
-        name: [your-app-service-account]
-        namespace: [your-app-namespace]
-    ```
+        ```
+        kubectl apply -f client-role-binding.yaml
+        ```

-    ```
-    kubectl apply -f client-role-binding.yaml
-    ```
+        When configuring Kubernetes Auth in Infisical, leave the **Token Reviewer JWT** field empty. Infisical will use the client's own token for validation.
+      </Accordion>
+      <Accordion title="Option 3: Use Gateway as Reviewer">
+        <Note>
+        **When to use this option**: Choose this approach when you have a gateway deployed in your Kubernetes Cluster and wish to eliminate long-lived tokens. This approach simplifies Infisical Kubernetes Auth configuration, and only one service account will need to have the elevated `system:auth-delegator` ClusterRole binding.
+        </Note>

-    When configuring Kubernetes Auth in Infisical, leave the **Token Reviewer JWT** field empty. Infisical will use the client's own token for validation.
-</Tab>
-</Tabs>
-</Step>
+        <Info>
+          **Note:** Gateway is a paid feature. - **Infisical Cloud users:** Gateway is
+          available under the **Enterprise Tier**. - **Self-Hosted Infisical:** Please
+          contact [[email protected]](mailto:[email protected]) to purchase an
+          enterprise license.
+        </Info>
+
+        <Steps>
+          <Step title="Deploying a gateway">
+            To deploy a gateway in your Kubernetes cluster, follow our [Gateway deployment guide using helm](/documentation/platform/gateways/overview).
+          </Step>
+
+          <Step title="Grant the gateway the system:auth-delegator ClusterRole binding">
+            To grant the gateway the `system:auth-delegator` ClusterRole binding, you can use the following command:
+
+            ```yaml gateway-role-binding.yaml
+            apiVersion: rbac.authorization.k8s.io/v1
+            kind: ClusterRoleBinding
+            metadata:
+              name: infisical-token-reviewer-role-binding
+              namespace: default # Replace with your namespace if not default
+            roleRef:
+              apiGroup: rbac.authorization.k8s.io
+              kind: ClusterRole
+              name: system:auth-delegator
+            subjects:
+              - kind: ServiceAccount
+                name: infisical-gateway # The name of the gateway service account
+                namespace: default # Replace with your namespace if not default
+            ```
+
+            ```bash
+            kubectl apply -f gateway-role-binding.yaml
+            ```
+
+            <Tip>
+              The gateway service account name is `infisical-gateway` by default if deployed using Helm.
+            </Tip>
+          </Step>
+
+          <Step title="Configure the Kubernetes Auth authentication method for the identity">
+            To configure your Kubernetes Auth method to use the gateway as the token reviewer, set the `Review Method` to "Gateway as Reviewer", and select the gateway you want to use as the token reviewer.
+
+            ![identities organization create kubernetes auth method](/images/platform/identities/identities-kubernetes-auth-gateway-as-reviewer.png)
+          </Step>
+        </Steps>
+      </Accordion>
+    </Step>

  <Step title="Creating an identity">
    To create an identity, head to your Organization Settings > Access Control > Identities and press **Create identity**.
@@ -0,0 +1,177 @@
+---
+title: SPIFFE/SPIRE
+description: "Learn how to authenticate SPIRE workloads with Infisical using OpenID Connect (OIDC)."
+---
+
+**OIDC Auth** is a platform-agnostic JWT-based authentication method that can be used to authenticate from any platform or environment using an identity provider with OpenID Connect.
+
+## Diagram
+
+The following sequence diagram illustrates the OIDC Auth workflow for authenticating SPIRE workloads with Infisical.
+
+```mermaid
+sequenceDiagram
+  participant Client as SPIRE Workload
+  participant Agent as SPIRE Agent
+  participant Server as SPIRE Server
+  participant Infis as Infisical
+
+  Client->>Agent: Step 1: Request JWT-SVID
+  Agent->>Server: Validate workload and fetch signing key
+  Server-->>Agent: Return signing material
+  Agent-->>Client: Return JWT-SVID with verifiable claims
+
+  Note over Client,Infis: Step 2: Login Operation
+  Client->>Infis: Send JWT-SVID to /api/v1/auth/oidc-auth/login
+
+  Note over Infis,Server: Step 3: Query verification
+  Infis->>Server: Request JWT public key using OIDC Discovery
+  Server-->>Infis: Return public key
+
+  Note over Infis: Step 4: JWT validation
+  Infis->>Client: Return short-lived access token
+
+  Note over Client,Infis: Step 5: Access Infisical API with Token
+  Client->>Infis: Make authenticated requests using the short-lived access token
+```
+
+## Concept
+
+At a high-level, Infisical authenticates a SPIRE workload by verifying the JWT-SVID and checking that it meets specific requirements (e.g. it is issued by a trusted SPIRE server) at the `/api/v1/auth/oidc-auth/login` endpoint. If successful,
+then Infisical returns a short-lived access token that can be used to make authenticated requests to the Infisical API.
+
+To be more specific:
+
+1. The SPIRE workload requests a JWT-SVID from the local SPIRE Agent.
+2. The SPIRE Agent validates the workload's identity and requests signing material from the SPIRE Server.
+3. The SPIRE Agent returns a JWT-SVID containing the workload's SPIFFE ID and other claims.
+4. The JWT-SVID is sent to Infisical at the `/api/v1/auth/oidc-auth/login` endpoint.
+5. Infisical fetches the public key that was used to sign the JWT-SVID from the SPIRE Server using OIDC Discovery.
+6. Infisical validates the JWT-SVID using the public key provided by the SPIRE Server and checks that the subject, audience, and claims of the token matches with the set criteria.
+7. If all is well, Infisical returns a short-lived access token that the workload can use to make authenticated requests to the Infisical API.
+
+<Note>Infisical needs network-level access to the SPIRE Server's OIDC Discovery endpoint.</Note>
+
+## Prerequisites
+
+Before following this guide, ensure you have:
+
+- A running SPIRE deployment with both SPIRE Server and SPIRE Agent configured
+- OIDC Discovery Provider deployed alongside your SPIRE Server
+- Workload registration entries created in SPIRE for the workloads that need to access Infisical
+- Network connectivity between Infisical and your OIDC Discovery Provider endpoint
+
+For detailed SPIRE setup instructions, refer to the [SPIRE documentation](https://spiffe.io/docs/latest/spire-about/).
+
+## OIDC Discovery Provider Setup
+
+To enable JWT-SVID verification with Infisical, you need to deploy the OIDC Discovery Provider alongside your SPIRE Server. The OIDC Discovery Provider runs as a separate service that exposes the necessary OIDC endpoints.
+
+In Kubernetes deployments, this is typically done by adding an `oidc-discovery-provider` container to your SPIRE Server StatefulSet:
+
+```yaml
+- name: spire-oidc
+  image: ghcr.io/spiffe/oidc-discovery-provider:1.12.2
+  args:
+    - -config
+    - /run/spire/oidc/config/oidc-discovery-provider.conf
+  ports:
+    - containerPort: 443
+      name: spire-oidc-port
+```
+
+The OIDC Discovery Provider will expose the OIDC Discovery endpoint at `https://<spire-oidc-host>/.well-known/openid_configuration`, which Infisical will use to fetch the public keys for JWT-SVID verification.
+
+<Note>For detailed setup instructions, refer to the [SPIRE OIDC Discovery Provider documentation](https://github.com/spiffe/spire/tree/main/support/oidc-discovery-provider).</Note>
+
+## Guide
+
+In the following steps, we explore how to create and use identities to access the Infisical API using the OIDC Auth authentication method with SPIFFE/SPIRE.
+
+<Steps>
+    <Step title="Creating an identity">
+    To create an identity, head to your Organization Settings > Access Control > Identities and press **Create identity**.
+
+    ![identities organization](/images/platform/identities/identities-org.png)
+
+    When creating an identity, you specify an organization level [role](/documentation/platform/role-based-access-controls) for it to assume; you can configure roles in Organization Settings > Access Control > Organization Roles.
+
+    ![identities organization create](/images/platform/identities/identities-org-create.png)
+
+    Now input a few details for your new identity. Here's some guidance for each field:
+
+    - Name (required): A friendly name for the identity.
+    - Role (required): A role from the **Organization Roles** tab for the identity to assume. The organization role assigned will determine what organization level resources this identity can have access to.
+
+    Once you've created an identity, you'll be redirected to a page where you can manage the identity.
+
+    ![identities page](/images/platform/identities/identities-page.png)
+
+    Since the identity has been configured with Universal Auth by default, you should re-configure it to use OIDC Auth instead. To do this, press to edit the **Authentication** section,
+    remove the existing Universal Auth configuration, and add a new OIDC Auth configuration onto the identity.
+
+    ![identities page remove default auth](/images/platform/identities/identities-page-remove-default-auth.png)
+
+    ![identities create oidc auth method](/images/platform/identities/identities-org-create-oidc-auth-method.png)
+
+    <Warning>Restrict access by configuring the Subject, Audiences, and Claims fields</Warning>
+
+    Here's some more guidance on each field:
+    - OIDC Discovery URL: The URL used to retrieve the OpenID Connect configuration from the SPIRE Server. This will be used to fetch the public key needed for verifying the provided JWT-SVID. This should be set to your SPIRE Server's OIDC Discovery endpoint, typically `https://<spire-server-host>:<port>/.well-known/openid_configuration`
+    - Issuer: The unique identifier of the SPIRE Server issuing the JWT-SVID. This value is used to verify the iss (issuer) claim in the JWT-SVID to ensure the token is issued by a trusted SPIRE Server. This should match your SPIRE Server's configured issuer, typically `https://<spire-server-host>:<port>`
+    - CA Certificate: The PEM-encoded CA certificate for establishing secure communication with the SPIRE Server endpoints. This should contain the CA certificate that signed your SPIRE Server's TLS certificate.
+    - Subject: The expected SPIFFE ID that is the subject of the JWT-SVID. The format of the sub field for SPIRE JWT-SVIDs follows the SPIFFE ID format: `spiffe://<trust-domain>/<workload-path>`. For example: `spiffe://example.org/workload/api-server`
+    - Audiences: A list of intended recipients for the JWT-SVID. This value is checked against the aud (audience) claim in the token. When workloads request JWT-SVIDs from SPIRE, they specify an audience (e.g., `infisical` or your service name). Configure this to match what your workloads use.
+    - Claims: Additional information or attributes that should be present in the JWT-SVID for it to be valid. Standard SPIRE JWT-SVID claims include `sub` (SPIFFE ID), `aud` (audience), `exp` (expiration), and `iat` (issued at). You can also configure custom claims if your SPIRE Server includes additional metadata.
+    - Access Token TTL (default is `2592000` equivalent to 30 days): The lifetime for an access token in seconds. This value will be referenced at renewal time.
+    - Access Token Max TTL (default is `2592000` equivalent to 30 days): The maximum lifetime for an access token in seconds. This value will be referenced at renewal time.
+    - 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.
+    - 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.
+    <Tip>SPIRE JWT-SVIDs contain standard claims like `sub` (SPIFFE ID), `aud` (audience), `exp`, and `iat`. The audience is typically specified when requesting the JWT-SVID (e.g., `spire-agent api fetch jwt -audience infisical`).</Tip>
+    <Info>The `subject`, `audiences`, and `claims` fields support glob pattern matching; however, we highly recommend using hardcoded SPIFFE IDs whenever possible for better security.</Info>
+    </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.
+
+    To do this, head over to the project you want to add the identity to and go to Project Settings > Access Control > Machine Identities and press **Add identity**.
+
+    Next, select the identity you want to add to the project and the project level role you want to allow it to assume. The project role assigned will determine what project level resources this identity can have access to.
+
+    ![identities project](/images/platform/identities/identities-project.png)
+
+    ![identities project create](/images/platform/identities/identities-project-create.png)
+    </Step>
+    <Step title="Using JWT-SVID to authenticate with Infisical">
+    Here's an example of how a workload can use its JWT-SVID to authenticate with Infisical and retrieve secrets:
+
+    ```bash
+    #!/bin/bash
+
+    # Obtain JWT-SVID from SPIRE Agent
+    JWT_SVID=$(spire-agent api fetch jwt -audience infisical -socketPath /run/spire/sockets/agent.sock | grep -A1 "token(" | tail -1)
+
+    # Authenticate with Infisical using the JWT-SVID
+    ACCESS_TOKEN=$(curl -s -X POST \
+        -H "Content-Type: application/json" \
+        -d "{\"identityId\":\"<your-identity-id>\",\"jwt\":\"$JWT_SVID\"}" \
+        https://app.infisical.com/api/v1/auth/oidc-auth/login | jq -r '.accessToken')
+
+    # Use the access token to retrieve secrets
+    curl -s -H "Authorization: Bearer $ACCESS_TOKEN" \
+        "https://app.infisical.com/api/v3/secrets/raw?workspaceSlug=<project-slug>&environment=<env-slug>&secretPath=/"
+    ```
+
+    <Note>
+        Each identity access token has a time-to-live (TTL) which you can infer from the response of the login operation;
+        the default TTL is `7200` seconds which can be adjusted.
+
+        If an identity access token expires, it can no longer authenticate with the Infisical API. In this case,
+        a new access token should be obtained by performing another login operation.
+    </Note>
+
+    <Tip>
+        JWT-SVIDs from SPIRE have their own expiration time (typically short-lived). Ensure your application handles both JWT-SVID renewal from SPIRE and access token renewal from Infisical appropriately.
+    </Tip>
+    </Step>
+
+</Steps>
@@ -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.
@@ -41,13 +40,6 @@ Enabling HSM encryption has a set of key benefits:
 - 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


@@ -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>
@@ -37,6 +37,10 @@ The enforcement level determines how strict the policy is. A **Hard** enforcemen
    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.
@@ -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.
+        ![Secret Manager Dashboard](/images/secret-rotations-v2/generic/add-secret-rotation.png)
+
+        2. Select the **MySQL Credentials** option.
+        ![Select MySQL Credentials](/images/secret-rotations-v2/mysql-credentials/select-mysql-credentials-option.png)
+
+        3. Select the **MySQL Connection** to use and configure the rotation behavior. Then click **Next**.
+        ![Rotation Configuration](/images/secret-rotations-v2/mysql-credentials/mysql-credentials-configuration.png)
+
+            - **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**.
+        ![Rotation Parameters](/images/secret-rotations-v2/mysql-credentials/mysql-credentials-parameters.png)
+
+            - **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**.
+        ![Rotation Secrets Mapping](/images/secret-rotations-v2/mysql-credentials/mysql-credentials-secrets-mapping.png)
+
+            - **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**.
+        ![Rotation Details](/images/secret-rotations-v2/mysql-credentials/mysql-credentials-details.png)
+
+            - **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**.
+        ![Rotation Review](/images/secret-rotations-v2/mysql-credentials/mysql-credentials-confirm.png)
+
+        8. Your **MySQL Credentials** are now available for use via the mapped secrets.
+        ![Rotation Created](/images/secret-rotations-v2/mysql-credentials/mysql-credentials-created.png)
+    </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>
@@ -1,175 +0,0 @@
---
-title: 'Secret Scanning'
-description: "Scan and prevent secret leaks in your code repositories"
---
-
-The Infisical Secret Scanner allows you to keep an overview and stay alert of exposed secrets across your entire GitHub organization and repositories.
-
-To further enhance security, we recommend you also use our [CLI Secret Scanner](/cli/scanning-overview#automatically-scan-changes-before-you-commit) to scan for exposed secrets prior to pushing your changes.
-
-
-<Accordion title="Self-hosting">
-
-  To setup secret scanning on your own instance of Infisical, you can follow the steps below.
-
-  <Steps>
-    <Step title="Create a GitHub App">
-      Create a new GitHub app in your GitHub organization or personal [Developer Settings](https://github.com/settings/apps).
-
-      ![Create GitHub App](/images/platform/secret-scanning/github-create-app.png)
-
-      ### Configure the GitHub App
-      To configure the GitHub app to work with Infisical, you'll need to modify the following settings:
-      - **Homepage URL**: Required to be set. Set it to the URL of your Infisical instance. (e.g. `https://app.infisical.com`)
-      - **Setup URL**: Set this to `https://<your-infisical-instance.com>/organization/secret-scanning`
-      - **Webhook URL**: Set this to `https://<your-infisical-instance.com>/api/v1/secret-scanning/webhook`
-      - **Webhook Secret**: Set this to a random string. This is used to verify the webhook request from Infisical. Use `openssl rand -base64 32` in your terminal to generate a random secret.
-
-      <Note>
-        Remember to save the webhook secret as you will need it in the next step.
-      </Note>
-
-      ![GitHub App Settings](/images/platform/secret-scanning/github-configure-app.png)
-
-      ### Configure the GitHub App Permissions
-      The GitHub app needs the following permissions:
-      
-      Repository permissions:
-      - `Checks`: Read and Write
-      - `Contents`: Read-only
-      - `Issues`: Read and Write
-      - `Pull Requests`: Read and Write
-      - `Metadata`: Read-only (enabled by default)
-
-      ![Github App Repository Permissions](/images/platform/secret-scanning/github-repo-permissions.png)
-
-      Subscribed events:
-      - `Check run`
-      - `Pull request`
-      - `Push`
-
-      ![Github App Subscribed Events](/images/platform/secret-scanning/github-subscribed-events.png)
-    
-
-      ### Create the GitHub App
-      Now you can create the GitHub app by clicking on the "Create GitHub App" button.
-
-      <Note>
-        If you want other Github users to be able to install the app, you need to tick the "Any account" option under "Where can this GitHub App be installed?"
-      </Note>
-
-      ![Create GitHub App](/images/platform/secret-scanning/github-create-app-button.png)
-    </Step>
-
-    <Step title="Retrieve the GitHub App ID">
-      After clicking the "Create GitHub App" button, you will be redirected to the GitHub settings page. Here you can copy the "App ID" and save it for later when you need to configure your environment variables for your Infisical instance.
-
-      ![Github App ID](/images/platform/secret-scanning/github-app-copy-app-id.png)
-    </Step>
-
-    <Step title="Retrieve your GitHub App slug">
-      The GitHub App slug is the name of the app you created in a slug friendly format. You can find the slug in the URL of the app you created.
-
-      ![Github App Slug](/images/platform/secret-scanning/github-app-copy-slug.png)
-    </Step>
-
-    <Step title="Create a new GitHub App private key">
-      Create a new app private key by clicking on the "Generate a private key" button under the "Private keys" section.
-
-      Once you click the "Generate a private key" button, the private key will be downloaded to your computer. Save this file for later as you will need the private key when configuring Infisical.
-
-      ![Github App Private Key](/images/platform/secret-scanning/github-app-create-private-key.png)
-
-      <Note>
-        Remember to save the private key as you will need it in the next step.
-      </Note>
-      
-    </Step>
-
-
-    <Step title="Configure your Infisical instance">
-      Now you can configure your Infisical instance by setting the following environment variables:
-      
-      - `SECRET_SCANNING_GIT_APP_ID`: The App ID of your GitHub App.
-      - `SECRET_SCANNING_GIT_APP_SLUG`: The slug of your GitHub App.
-      - `SECRET_SCANNING_PRIVATE_KEY`: The private key of your GitHub App that you created in a previous step.
-      - `SECRET_SCANNING_WEBHOOK_SECRET`: The webhook secret of your GitHub App that you created in a previous step.
-    </Step>
-  </Steps>
-
-  After restarting your Infisical instance, you should be able to use the secret scanning feature within your organization. Follow the steps below to add the GitHub App to your Infisical organization.
-</Accordion>
-
-## Install the Infisical Radar GitHub App
-
-To install the GitHub App, press the "Integrate With GitHub" button in the top right corner of your Infisical Secret Scanning dashboard.
-
-![Integrate With GitHub](/images/platform/secret-scanning/infisical-connect-secret-scanner.png)
-
-Next, you'll be prompted to select which organization you'd like to install the app into. Select the organization you'd like to install the app into by clicking the organization in the menu.
-
-![Select Organization](/images/platform/secret-scanning/github-select-org-2.png)
-
-Select the repositories you'd like to scan for secrets and press the "Install" button.
-
-![Select Repositories](/images/platform/secret-scanning/github-select-repos.png)
-
-## Code Scanning
-
-![Scanning Overview](/images/platform/secret-scanning/overview.png)
-
-Secret scans are built on event-driven architecture. This means that every time a push is made to one of your selected repositories, Infisical will scan the modified files for any exposed secrets.
-
-If one or more exposed secrets are detected, it will be displayed in your Infisical dashboard. An exposed secret is known as a **"Risk"**. Each risk has the following data associated with it:
- **Date**: When the risk was first detected.
- **Secret Type**: Which type of secret was detected.
- **Info**: Information about the secret, such as the repository, file name, and the committer who made the change.
-
-Once an exposed secret is detected, all organization admins will be sent an e-mail notification containing details about the exposed secret.
-
-<Tip>
-  Each risk also contains a "View Exposed Secret" button, which will take you directly to the GitHub commit and to the line where the secret was exposed.
-</Tip>
-
-
-
-![Exposed Secret](/images/platform/secret-scanning/exposed-secret.png)
-
-
-## Responding to Exposed Secrets
-
-After an exposed secret is detected, it will be marked as `Needs Attention`. When there are risks marked as needs attention, it's important to address them as soon as possible.
-
-You can mark the risk as `Resolved` by changing the status to one of the following states:
- **This Is a False Positive**: The secret was not exposed, but was detected by the scanner.
- **I Have Rotated The Secret**: The secret was exposed, but it has now been removed.
- **No Rotation Needed**: You are choosing to ignore this risk. You may choose to do this if the risk is non-sensitive or otherwise not a security risk.
-
-![Needs Attention](/images/platform/secret-scanning/needs-attention.png)
-
-
-
-
-## Ignoring Known Secrets
-If you're intentionally committing a test secret that the secret scanner might flag, you can instruct Infisical to overlook that secret with the methods listed below.
-
-### infisical-scan:ignore
-
-To ignore a secret contained in line of code, simply add `infisical-scan:ignore ` at the end of the line as comment in the given programming.
-
-```js example.js
-function helloWorld() {
-    console.log("8dyfuiRyq=vVc3RRr_edRk-fK__JItpZ"); // infisical-scan:ignore
-}
-```
-
-### .infisicalignore
-An alternative method to exclude specific findings involves creating a .infisicalignore file at your repository's root.
-You can then add the fingerprints of the findings you wish to exclude. The [Infisical scan](/cli/scanning-overview) report provides a unique Fingerprint for each secret found.
-By incorporating these Fingerprints into the .infisicalignore file, Infisical will skip the corresponding secret findings in subsequent scans.
-
-```.ignore .infisicalignore
-bea0ff6e05a4de73a5db625d4ae181a015b50855:frontend/components/utilities/attemptLogin.js:stripe-access-token:147
-bea0ff6e05a4de73a5db625d4ae181a015b50855:backend/src/json/integrations.json:generic-api-key:5
-1961b92340e5d2613acae528b886c842427ce5d0:frontend/components/utilities/attemptLogin.js:stripe-access-token:148
-```
@@ -0,0 +1,96 @@
+---
+title: "GitHub Secret Scanning"
+sidebarTitle: "GitHub"
+description: "Learn how to configure secret scanning for GitHub."
+---
+
+## Prerequisites
+
+- Create a [GitHub Radar Connection](/integrations/app-connections/github-radar)
+
+## Create a GitHub Data Source in Infisical
+
+<Tabs>
+    <Tab title="Infisical UI">
+        1. Navigate to your Secret Scanning Project's Dashboard and click the **Add Data Source** button.
+        ![Secret Scanning Dashboard](/images/platform/secret-scanning/github/github-data-source-step-1.png)
+
+        2. Select the **GitHub** option.
+        ![Select GitHub Option](/images/platform/secret-scanning/github/github-data-source-step-2.png)
+
+        3. Select the **GitHub Radar Connection** to use and configure which repositories you would like to scan. Then click **Next**.
+        ![Data Source Configuration](/images/platform/secret-scanning/github/github-data-source-step-3.png)
+
+            - **GitHub Radar Connection** - the connection that has access to the repositories you want to scan.
+            - **Scan Repositories** - select which repositories you would like to scan.
+                - **All Repositories** - Infisical will scan all repositories associated with your connection.
+                - **Select Repositories** - Infisical will scan the selected repositories.
+            - **Auto-Scan Enabled** - whether Infisical should automatically perform a scan when a push is made to configured repositories.
+
+        4. Give your data source a name and description (optional). Then click **Next**.
+        ![Data Source Details](/images/platform/secret-scanning/github/github-data-source-step-4.png)
+
+            - **Name** - the name of the data source. Must be slug-friendly.
+            - **Description** (optional) - a description of this data source.
+
+        5. Review your data source, then click **Create Data Source**.
+        ![Data Source Review](/images/platform/secret-scanning/github/github-data-source-step-5.png)
+
+        6. Your **GitHub Data Source** is now available and will begin a full scan if **Auto-Scan** is enabled.
+        ![Data Source Created](/images/platform/secret-scanning/github/github-data-source-step-6.png)
+
+        7. You can view repositories and scan results by clicking on your data source.
+        ![Data Source Page](/images/platform/secret-scanning/github/github-data-source-step-7.png)
+
+        8. In addition, you can review any findings from the **Findings Page**.
+        ![Findings Page](/images/platform/secret-scanning/github/github-data-source-step-8.png)
+    </Tab>
+    <Tab title="API">
+        To create a GitHub Data Source, make an API request to the [Create GitHub Data Source](/api-reference/endpoints/secret-scanning/data-sources/github/create) API endpoint.
+
+        ### Sample request
+
+        ```bash Request
+        curl --request POST \
+        --url https://us.infisical.com/api/v2/secret-scanning/data-sources/github \
+        --header 'Content-Type: application/json' \
+        --data '{
+            "name": "my-github-source",
+            "projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
+            "description": "my github data source",
+            "connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
+            "isAutoScanEnabled": true,
+            "config": {
+                "includeRepos": ["*"]
+            }
+        }'
+        ```
+
+        ### Sample response
+
+        ```bash Response
+        {
+            "dataSource": {
+                "id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
+                "externalId": "1234567890",
+                "name": "my-github-source",
+                "description": "my github data source",
+                "isAutoScanEnabled": true,
+                "projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
+                "createdAt": "2023-11-07T05:31:56Z",
+                "updatedAt": "2023-11-07T05:31:56Z",
+                "type": "github",
+                "connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
+                "connection": {
+                    "app": "github-radar",
+                    "name": "my-radar-app",
+                    "id": "3c90c3cc-0d44-4b50-8888-8dd25736052a"
+                },
+                "config": {
+                    "includeRepos": ["*"]
+                }
+            }
+        }
+        ```
+    </Tab>
+</Tabs>
@@ -0,0 +1,230 @@
+---
+title: "Secret Scanning"
+sidebarTitle: "Overview"
+description: "Scan and prevent secret leaks in your code repositories"
+---
+
+## Introduction
+
+Monitor and detect exposed secrets across your data sources, including code repositories, with Infisical Secret Scanning.
+
+For additional security, we recommend using our [CLI Secret Scanner](/cli/scanning-overview#automatically-scan-changes-before-you-commit) to check for exposed secrets before pushing your code changes.
+
+<Note>
+    Secret Scanning is a paid feature.
+    If you're using Infisical Cloud, then it is available under the **Enterprise Tier**. If you're self-hosting Infisical,
+    then you should contact [email protected] to purchase an enterprise license to use it.
+</Note>
+
+## How Secret Scanning Works
+
+Secret Scanning consists of several components that enable you to quickly respond to secret leaks:
+
+- **Scanner Engine**: The core component that analyzes your code and detects potential secrets using pattern matching and entropy analysis
+- **Real-time Monitoring**: Provides continuous surveillance of your repositories for immediate detection of exposed secrets
+- **Alert System**: Notifies organization admins via email when secrets are detected
+- **Risk Management**: Allows tracking and managing detected secrets with different status options
+- **Data Sources**: Integrates with various data sources and version control systems
+- **Customizable Rules**: Supports ignore patterns and custom configurations to reduce false positives
+
+These components work together to provide comprehensive secret detection and incident response capabilities.
+
+### Data Sources
+
+Data sources are configured integrations with external platforms, such as a GitHub organization or a GitLab group, that establish secure connections for scanning purposes using [App Connections](/integrations/app-connections/overview).
+
+A data source acts as a secure intermediary between the external system and the scanner engine. It manages a collection of scannable resources (such as repositories) and handles the authentication and communication required for scanning operations.
+
+![data sources](/images/platform/secret-scanning/secret-scanning-data-sources.png)
+
+### Resources
+
+Resources are the atomic, scannable units, such as a repository, that can be monitored for secret exposure. Resources are added automatically when a data source is scanned and updated when scanning events are triggered, such as when a user pushes changes to GitHub.
+
+Each resource maintains its own scanning history and status, allowing for granular monitoring and management of secret scanning across your organization.
+
+![resources](/images/platform/secret-scanning/secret-scanning-resources.png)
+
+### Scans
+
+Scans can be initiated in two ways:
+
+1. **Full Scan** - Manually triggered scan that comprehensively checks either all resources associated with a data source or a single selected resource.
+
+2. **Diff Scan** - Automatically executed when **Auto-Scan** is enabled on a data source. This scan type specifically focuses on updates to existing resources.
+
+All scan activities can be monitored in real-time through the Infisical UI, which displays:
+- Current scan status
+- Timestamp of the scan
+- Resource(s) being scanned
+- Detection results (whether any secrets were found)
+
+![scans](/images/platform/secret-scanning/secret-scanning-scans.png)
+
+### Findings
+
+Findings are automatically generated when secret leaks are detected during scanning operations. Each finding contains comprehensive information including:
+- The specific scanning rule that identified the leak
+- File location and line number where the secret was found
+- Resource-specific details (e.g., commit hash and author for Git repositories)
+
+Findings are initially marked as **Unresolved** and can be updated to one of the following statuses with additional remarks:
+- **Resolved** - The issue has been addressed
+- **False Positive** - The detection was incorrect
+- **Ignore** - The finding can be safely disregarded
+
+These status options help teams effectively track and manage the lifecycle of detected secret leaks.
+
+![findings](/images/platform/secret-scanning/secret-scanning-findings.png)
+
+### Configuration
+
+You can configure custom scanning rules and exceptions by updating your project's scanning configuration via the UI or API.
+
+The configuration options allow you to:
+- Define custom scanning patterns and rules
+- Set up ignore patterns to reduce false positives
+- Specify file path exclusions
+- Configure entropy thresholds for secret detection
+- Add allowlists for known safe patterns
+
+For detailed configuration options, expand the example configuration below.
+
+<Accordion title="Example Configuration">
+    ```toml
+    # Title for the configuration file
+    title = "Some title"
+
+
+    # This configuration is the foundation that can be expanded. If there are any overlapping rules
+    # between this base and the expanded configuration, the rules in this base will take priority.
+    # Another aspect of extending configurations is the ability to link multiple files, up to a depth of 2.
+    # "Allowlist" arrays get appended and may have repeated elements.
+    # "useDefault" and "path" cannot be used simultaneously. Please choose one.
+    [extend]
+    # useDefault will extend the base configuration with the default config:
+    # https://raw.githubusercontent.com/Infisical/infisical/main/cli/config/infisical-scan.toml
+    useDefault = true
+    # or you can supply a path to a configuration. Path is relative to where infisical cli
+    # was invoked, not the location of the base config.
+    path = "common_config.toml"
+
+    # An array of tables that contain information that define instructions
+    # on how to detect secrets
+    [[rules]]
+
+    # Unique identifier for this rule
+    id = "some-identifier-for-rule"
+
+    # Short human readable description of the rule.
+    description = "awesome rule 1"
+
+    # Golang regular expression used to detect secrets. Note Golang's regex engine
+    # does not support lookaheads.
+    regex = '''one-go-style-regex-for-this-rule'''
+
+    # Golang regular expression used to match paths. This can be used as a standalone rule or it can be used
+    # in conjunction with a valid `regex` entry.
+    path = '''a-file-path-regex'''
+
+    # Array of strings used for metadata and reporting purposes.
+    tags = ["tag","another tag"]
+
+    # A regex match may have many groups, this allows you to specify the group that should be used as (which group the secret is contained in)
+    # its entropy checked if `entropy` is set.
+    secretGroup = 3
+
+    # Float representing the minimum shannon entropy a regex group must have to be considered a secret.
+    # Shannon entropy measures how random a data is. Since secrets are usually composed of many random characters, they typically have high entropy
+    entropy = 3.5
+
+    # Keywords are used for pre-regex check filtering.
+    # If rule has keywords but the text fragment being scanned doesn't have at least one of it's keywords, it will be skipped for processing further.
+    # Ideally these values should either be part of the identifier or unique strings specific to the rule's regex
+    # (introduced in v8.6.0)
+    keywords = [
+        "auth",
+        "password",
+        "token",
+    ]
+
+    # You can include an allowlist table for a single rule to reduce false positives or ignore commits
+    # with known/rotated secrets
+    [rules.allowlist]
+    description = "ignore commit A"
+    commits = [ "commit-A", "commit-B"]
+    paths = [
+        '''go\.mod''',
+        '''go\.sum'''
+    ]
+    # note: (rule) regexTarget defaults to check the _Secret_ in the finding.
+    # if regexTarget is not specified then _Secret_ will be used.
+    # Acceptable values for regexTarget are "match" and "line"
+    regexTarget = "match"
+    regexes = [
+        '''process''',
+        '''getenv''',
+    ]
+    # note: stopwords targets the extracted secret, not the entire regex match
+    # if the extracted secret is found in the stopwords list, the finding will be skipped (i.e not included in report)
+    stopwords = [
+        '''client''',
+        '''endpoint''',
+    ]
+
+
+    # This is a global allowlist which has a higher order of precedence than rule-specific allowlists.
+    # If a commit listed in the `commits` field below is encountered then that commit will be skipped and no
+    # secrets will be detected for said commit. The same logic applies for regexes and paths.
+    [allowlist]
+    description = "global allow list"
+    commits = [ "commit-A", "commit-B", "commit-C"]
+    paths = [
+        '''gitleaks\.toml''',
+        '''(.*?)(jpg|gif|doc)'''
+    ]
+
+    # note: (global) regexTarget defaults to check the _Secret_ in the finding.
+    # if regexTarget is not specified then _Secret_ will be used.
+    # Acceptable values for regexTarget are "match" and "line"
+    regexTarget = "match"
+
+    regexes = [
+        '''219-09-9999''',
+        '''078-05-1120''',
+        '''(9[0-9]{2}|666)-\d{2}-\d{4}''',
+    ]
+    # note: stopwords targets the extracted secret, not the entire regex match
+    # if the extracted secret is found in the stopwords list, the finding will be skipped (i.e not included in report)
+    stopwords = [
+        '''client''',
+        '''endpoint''',
+    ]
+    ```
+</Accordion>
+
+![config](/images/platform/secret-scanning/secret-scanning-config.png)
+
+## Ignoring Known Secrets
+If you're intentionally committing a test secret that the secret scanner might flag, you can instruct Infisical to overlook that secret with the methods listed below.
+
+### infisical-scan:ignore
+
+To ignore a secret contained in line of code, simply add `infisical-scan:ignore ` at the end of the line as comment in the given programming.
+
+```js example.js
+function helloWorld() {
+    console.log("8dyfuiRyq=vVc3RRr_edRk-fK__JItpZ"); // infisical-scan:ignore
+}
+```
+
+### .infisicalignore
+An alternative method to exclude specific findings involves creating a .infisicalignore file at your repository's root.
+You can then add the fingerprints of the findings you wish to exclude. The [Infisical scan](/cli/scanning-overview) report provides a unique Fingerprint for each secret found.
+By incorporating these Fingerprints into the .infisicalignore file, Infisical will skip the corresponding secret findings in subsequent scans.
+
+```.ignore .infisicalignore
+bea0ff6e05a4de73a5db625d4ae181a015b50855:frontend/components/utilities/attemptLogin.js:stripe-access-token:147
+bea0ff6e05a4de73a5db625d4ae181a015b50855:backend/src/json/integrations.json:generic-api-key:5
+1961b92340e5d2613acae528b886c842427ce5d0:frontend/components/utilities/attemptLogin.js:stripe-access-token:148
+```
@@ -4,33 +4,36 @@ sidebarTitle: "Networking"
 description: "Network configuration details for Infisical Cloud"
 ---

-## Overview
-
 When integrating your infrastructure with Infisical Cloud, you may need to configure network access controls. This page provides the IP addresses that Infisical uses to communicate with your services.

-## Egress IP Addresses
+## Infisical IP Addresses

-Infisical Cloud operates from two regions: US and EU. If your infrastructure has strict network policies, you may need to allow traffic from Infisical by adding the following IP addresses to your ingress rules. These are the egress IPs Infisical uses when making outbound requests to your services.
+Infisical Cloud operates from multiple regions. If your infrastructure has strict network policies, you may need to allow traffic from Infisical by adding the following IP addresses to your ingress rules. These are the IP addresses that Infisical uses when making outbound requests to your services.

-### US Region
+<Tabs>
+  <Tab title="US Region">
+    ```
+    3.213.63.16
+    54.164.68.7
+    ```
+  </Tab>
+  
+  <Tab title="EU Region">
+    ```
+    3.77.89.19
+    3.125.209.189
+    ```
+  </Tab>
+  
+  <Tab title="Dedicated Cloud">
+    For dedicated Infisical deployments, please contact your account manager for the specific IP addresses used in your dedicated environment.
+  </Tab>
+</Tabs>

-To allow connections from Infisical US, add these IP addresses to your ingress rules:
+<Warning>
+These IP addresses are static and managed by Infisical. Any changes will be communicated with 60-day advance notice.
+</Warning>

- `3.213.63.16`
- `54.164.68.7`
+## What These IP Addresses Are Used For

-### EU Region
-
-To allow connections from Infisical EU, add these IP addresses to your ingress rules:
-
- `3.77.89.19`
- `3.125.209.189`
-
-## Common Use Cases
-
-You may need to allow Infisical’s egress IPs if your services require inbound connections for:
-
- Secret rotation - When Infisical needs to send requests to your systems to automatically rotate credentials
- Dynamic secrets - When Infisical generates and manages temporary credentials for your cloud services
- Secret integrations - When syncing secrets with third-party services like Azure Key Vault
- Native authentication with machine identities - When using methods like Kubernetes authentication
+These IP addresses represent the source IPs you'll see when Infisical Cloud makes connections to your infrastructure. All outbound traffic from Infisical Cloud originates from these IP addresses, ensuring predictable source IP addresses for your firewall rules.
--- a/Show More
+++ b/Show More