Merge branch 'main' into ENG-2636

docs/api-reference/endpoints/certificates/bundle.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Get Certificate Bundle"
-openapi: "GET /api/v2/workspace/{slug}/bundle"
+openapi: "GET /api/v1/pki/certificates/{serialNumber}/bundle"
 ---
 
 <Note>

docs/api-reference/endpoints/certificates/private-key.mdx

@@ -1,4 +1,4 @@
 ---
 title: "Get Certificate Private Key"
-openapi: "GET /api/v2/workspace/{slug}/private-key"
+openapi: "GET /api/v1/pki/certificates/{serialNumber}/private-key"
 ---

docs/documentation/platform/access-controls/abac/managing-user-metadata.mdx

@@ -27,7 +27,7 @@ User identities can have metadata attributes assigned directly. These attributes
 </Tabs>
 
 #### Applying ABAC Policies with User Metadata
-Attribute-based access controls are currently only available for polices defined on Secrets Manager projects. 
+Attribute-based access controls are currently only available for policies defined on Secrets Manager projects.
 You can set ABAC permissions to dynamically set access to environments, folders, secrets, and secret tags.
 
 <img src="/images/platform/access-controls/example-abac-1.png" />

docs/documentation/platform/project-templates.mdx

@@ -33,7 +33,7 @@ In the following steps, we'll explore how to set up a project template.
     <Tab title="Infisical UI">
         <Steps>
             <Step title="Creating a Project Template">
-                Navigate to the Project Templates tab on the Organization Settings page and tap on the **Add Template** button.
+                Navigate to the **Project Templates** tab on the Feature Settings page for the project type you want to create a template for and tap on the **Add Template** button.
                 ![project template add button](/images/platform/project-templates/project-template-add-button.png)
 
                 Specify your template details. Here's some guidance on each field:
@@ -67,6 +67,7 @@ In the following steps, we'll explore how to set up a project template.
         --header 'Content-Type: application/json' \
         --data '{
             "name": "my-project-template",
+            "type": "secret-manager",
             "description": "...",
             "environments": "[...]",
             "roles": "[...]",

docs/documentation/platform/ssh/overview.mdx

@@ -31,16 +31,9 @@ we will register a remote host with Infisical through a [machine identity](/docu
 
 <Steps>
   <Step title="Create an Infisical SSH project">
-    1.1. Start by creating a new Infisical SSH project in Infisical.
+    Start by creating a new Infisical SSH project in Infisical.
     
     ![ssh project create](/images/platform/ssh/v2/ssh-create-project.png)
-    
-    1.2. Create a custom role in the project under Access Control > Project Roles to grant the machine identity that we will create in step 2 the ability to **Create** and **Issue Host Certificates** on the **SSH Host** resource; this will enable the linked machine identity to bootstrap a remote host with Infisical
-    and establish the necessary configuration on it.
-    
-    ![ssh custom role bootstrap 1](/images/platform/ssh/v2/ssh-add-bootstrap-role-1.png)
-    
-    ![ssh custom role bootstrap 2](/images/platform/ssh/v2/ssh-add-bootstrap-role-2.png)
   </Step>
   <Step title="Create a machine identity for bootstrapping Infisical SSH">
     2.1. Follow the instructions [here](/documentation/platform/identities/universal-auth) to configure a [machine identity](/documentation/platform/identities/machine-identities) in Infisical with Universal Auth.
@@ -52,7 +45,14 @@ we will register a remote host with Infisical through a [machine identity](/docu
         You may use other authentication methods as suitable (e.g. [AWS Auth](/documentation/platform/identities/aws-auth), [Azure Auth](/documentation/platform/identities/azure-auth), [GCP Auth](/documentation/platform/identities/gcp-auth), etc.) as part of the machine identity configuration but, to keep this example simple, we will be using Universal Auth.
     </Note>
 
-    2.2. Add the machine identity to the Infisical SSH project you created in the previous step and assign it the custom role you created in step 1.2.
+    2.2. Add the machine identity to the Infisical SSH project you created in the previous step and assign it the **SSH Host Bootstrapper** role.
+
+      This role grants the ability to **Create** and **Issue Host Certificates** on the **SSH Host** resource; this will enable the linked machine identity to bootstrap a remote host with Infisical
+      and establish the necessary configuration on it.
+
+      <Tip>
+          If you plan to use a custom role to bootstrap SSH hosts, ensure the role has the **Create** and **Issue Host Certificates** on the **SSH Host** resource.
+      </Tip>
 
     ![ssh add identity to project](/images/platform/ssh/v2/ssh-add-identity-to-project.png)
 

docs/integrations/platforms/kubernetes/infisical-dynamic-secret-crd.mdx

@@ -165,7 +165,7 @@ spec:
 </Accordion>
 
   <Accordion title="managedSecretReference.creationPolicy">
-    Creation polices allow you to control whether or not owner references should be added to the managed Kubernetes secret that is generated by the Infisical operator. 
+    Creation policies allow you to control whether or not owner references should be added to the managed Kubernetes secret that is generated by the Infisical operator.
     This is useful for tools such as ArgoCD, where every resource requires an owner reference; otherwise, it will be pruned automatically.
 
     #### Available options

docs/integrations/platforms/kubernetes/infisical-push-secret-crd.mdx

@@ -34,7 +34,7 @@ Before applying the InfisicalPushSecret CRD, you need to create a Kubernetes sec
   metadata:
     name: infisical-push-secret-demo
   spec:
-    resyncInterval: 1m
+    resyncInterval: 1m # Remove this field to disable automatic reconciliation of the InfisicalPushSecret CRD.
     hostAPI: https://app.infisical.com/api
 
     # Optional, defaults to no replacement.
@@ -124,7 +124,9 @@ After applying the InfisicalPushSecret CRD, you should notice that the secrets y
 
 <Accordion title="resyncInterval">
 
-  The `resyncInterval` is a string-formatted duration that defines the time between each resync.
+  The `resyncInterval` is a string-formatted duration that defines the time between each resync. The field is optional, and will default to no automatic resync if not defined.
+
+  If you don't want to automatically reconcile the InfisicalPushSecret CRD on an interval, you can remove the `resyncInterval` field entirely from your InfisicalPushSecret CRD.
 
   The format of the field is `[duration][unit]` where `duration` is a number and `unit` is a string representing the unit of time.
 
@@ -239,7 +241,21 @@ After applying the InfisicalPushSecret CRD, you should notice that the secrets y
         DATABASE_URL: postgres://127.0.0.1:5432
         ENCRYPTION_KEY: fabcc12-a22-facbaa4-11aa568aab
     ```
+  </Accordion>
+  <Accordion title="generators[]">
+    The `generators[]` field is used to define the generators you want to use for your InfisicalPushSecret CRD.
+    You can follow the guide for [using generators to push secrets](#using-generators-to-push-secrets) for more information.
 
+    Example:
+
+    ```yaml
+      push:
+        generators:
+          - destinationSecretName: password-generator-test
+            generatorRef:
+              kind: Password
+              name: password-generator
+    ```
   </Accordion>
 </Accordion>
 
@@ -459,6 +475,148 @@ Using Go templates, you can format, combine, and create new key-value pairs of s
   Please refer to the [templating functions documentation](/integrations/platforms/kubernetes/overview#available-helper-functions) for more information.
 </Accordion>
 
+## Using generators to push secrets
+
+Generators allow secrets to be dynamically generated during each reconciliation cycle and then pushed to Infisical. They are useful for use cases where a new secret value is needed on every sync, such as ephemeral credentials or one-time-use tokens.
+
+A generator is defined as a custom resource (`ClusterGenerator`) within the cluster, which specifies the logic for generating secret values. Generators are stateless, each invocation triggers the creation of a new set of values, with no tracking or persistence of previously generated data.
+
+Because of this behavior, you may want to disable automatic syncing for the `InfisicalPushSecret` resource to avoid continuous regeneration of secrets. This can be done by omitting the `resyncInterval` field from the InfisicalPushSecret CRD.
+
+### Example usage 
+```yaml
+  push:
+    secret:
+      secretName: push-secret-source-secret
+      secretNamespace: dev
+    generators:
+      - destinationSecretName: password-generator # Name of the secret that will be created in Infisical
+        generatorRef:
+          kind: Password # Kind of the resource, must match the generator kind.
+          name: custom-generator # Name of the generator resource
+```
+
+To use a generator, you must specify at least one generator in the `push.generators[]` field.
+
+
+<Accordion title="push.generators[]">
+  This field holds an array of the generators you want to use for your InfisicalPushSecret CRD.
+</Accordion>
+
+<Accordion title="push.generators[].destinationSecretName">
+  The name of the secret that will be created in Infisical.
+</Accordion>
+
+<Accordion title="push.generators[].generatorRef">
+  The reference to the generator resource.
+
+  Valid fields:
+  - `kind`: The kind of the generator resource, must match the generator kind.
+  - `name`: The name of the generator resource.
+</Accordion>
+
+<Accordion title="push.generators[].generatorRef.kind">
+  The kind of the generator resource, must match the generator kind.
+
+  Valid values:
+  - `Password`
+  - `UUID`
+</Accordion>
+
+<Accordion title="push.generators[].generatorRef.name">
+  The name of the generator resource.
+</Accordion>
+
+### Supported Generators
+Below are the currently supported generators for the InfisicalPushSecret CRD. Each generator is a `ClusterGenerator` custom resource that can be used to customize the generated secret.
+
+<Accordion title="Password Generator">
+  ### Password Generator
+
+  The Password generator is a custom resource that is installed on the cluster that defines the logic for generating a password.
+    - `kind`: The kind of the generator resource, must match the generator kind. For the Password generator, the kind is `Password`.
+    - `generator.passwordSpec`: The spec of the password generator.
+
+    <Accordion title="generator.kind">
+    The `generator.kind` field must match the kind of the generator resource. For the Password generator, the kind should always be set to  `Password`.
+    </Accordion>
+    <Accordion title="generator.passwordSpec">
+    - `length`: The length of the password.
+    - `digits`: The number of digits in the password.
+    - `symbols`: The number of symbols in the password.
+    - `symbolCharacters`: The characters to use for the symbols in the password.
+    - `noUpper`: Whether to include uppercase letters in the password.
+    - `allowRepeat`: Whether to allow repeating characters in the password.
+    </Accordion>
+
+  ```yaml password-cluster-generator.yaml
+  apiVersion: secrets.infisical.com/v1alpha1
+  kind: ClusterGenerator
+  metadata:
+    name: password-generator
+  spec:
+    kind: Password
+    generator:
+      passwordSpec:
+        length: 10
+        digits: 5
+        symbols: 5
+        symbolCharacters: "-_$@"
+        noUpper: false
+        allowRepeat: true
+  ```
+
+  Example InfisicalPushSecret CRD using the Password generator:
+  ```yaml infisical-push-secret-crd.yaml
+    push:
+      generators:
+        - destinationSecretName: password-generator-test
+          generatorRef:
+            kind: Password
+            name: password-generator
+  ```
+</Accordion>
+<Accordion title="UUID Generator">
+  ### UUID Generator
+
+  The UUID generator is a custom resource that is installed on the cluster that defines the logic for generating a UUID.
+  - `kind`: The kind of the generator resource, must match the generator kind. For the UUID generator, the kind is `UUID`.
+  - `generator.uuidSpec`: The spec of the UUID generator. For UUID's, this can be left empty.
+
+  <Accordion title="generator.kind">
+    The `generator.kind` field must match the kind of the generator resource. For the UUID generator, the kind should always be set to  `UUID`.
+  </Accordion>
+
+  <Accordion title="generator.uuidSpec">
+    The spec of the UUID generator. For UUID's, this can be left empty.
+  </Accordion>
+
+  ```yaml uuid-cluster-generator.yaml
+    apiVersion: secrets.infisical.com/v1alpha1
+    kind: ClusterGenerator
+    metadata:
+      name: uuid-generator
+    spec:
+      kind: UUID
+      generator:
+        uuidSpec:
+  ```
+
+  Example InfisicalPushSecret CRD using the UUID generator:
+
+  ```yaml infisical-push-secret-crd.yaml
+    push:
+      generators:
+        - destinationSecretName: uuid-generator-test
+          generatorRef:
+            kind: UUID
+            name: uuid-generator
+  ```
+</Accordion>
+
+
+
+
 ## Applying the InfisicalPushSecret CRD to your cluster
 
 Once you have configured the `InfisicalPushSecret` CRD with the required fields, you can apply it to your cluster.

docs/integrations/platforms/kubernetes/infisical-secret-crd.mdx

@@ -832,7 +832,7 @@ The namespace of the managed Kubernetes secret to be created.
 Override the default Opaque type for managed secrets with this field. Useful for creating kubernetes.io/dockerconfigjson secrets.
 </Accordion>
 <Accordion title="managedKubeSecretReferences[].creationPolicy">
-Creation polices allow you to control whether or not owner references should be added to the managed Kubernetes secret that is generated by the Infisical operator. 
+Creation policies allow you to control whether or not owner references should be added to the managed Kubernetes secret that is generated by the Infisical operator.
 This is useful for tools such as ArgoCD, where every resource requires an owner reference; otherwise, it will be pruned automatically.
 
 #### Available options
@@ -940,7 +940,7 @@ The Infisical operator will automatically create the Kubernetes config map in th
   The namespace of the managed Kubernetes config map that your Infisical data will be stored in. 
 </Accordion>
 <Accordion title="managedKubeConfigMapReferences[].creationPolicy">
-  Creation polices allow you to control whether or not owner references should be added to the managed Kubernetes config map that is generated by the Infisical operator. 
+  Creation policies allow you to control whether or not owner references should be added to the managed Kubernetes config map that is generated by the Infisical operator.
   This is useful for tools such as ArgoCD, where every resource requires an owner reference; otherwise, it will be pruned automatically.
 
   #### Available options