merge main

docs/documentation/platform/ssh.mdx

@@ -0,0 +1,242 @@
+---
+title: "Infisical SSH"
+sidebarTitle: "Infisical SSH"
+description: "Learn how to generate SSH credentials to provide secure and centralized SSH access control for your infrastructure."
+---
+
+## Concept
+
+Infisical can be used to issue SSH certificates to clients to provide short-lived, secure SSH access to infrastructure;
+this improves on many limitations of traditional SSH key-based authentication via mitigation of private key compromise, static key management,
+unauthorized access, and SSH key sprawl.
+
+The following concepts are useful to know when working with Infisical SSH:
+
+- SSH Certificate Authority (CA): A trusted authority that issues SSH certificates.
+- Certificate Template: A set of policies bound to a SSH CA for certificates issued under that template; a CA can possess multiple templates, each with different policies for a different purpose (e.g. for admin versus developer access).
+- SSH Certificate: A short-lived, credential issued by the SSH CA granting time-bound access to infrastructure.
+
+<div align="center">
+
+```mermaid
+graph TD
+    A[SSH CA]
+    A --> B[Certificate Template A]
+    A --> C[Certificate Template N]
+    B --> D[SSH Certificate A]
+    C --> E[SSH Certificate N]
+
+```
+
+</div>
+
+When using Infisical SSH to provision client access to a remote host, an operator must create a SSH CA in Infisical; a certificate template under it,
+specifying policies such as allowed users that can be requested under that template by a client; and configure the host to trust certificates issued by the Infisical SSH CA.
+
+When a client needs access to a host, they authenticate with Infisical and request a SSH certificate (and optionally key pair)
+to be used to access the host for a time-bound session as part of the SSH operation.
+
+## Client Workflow
+
+The following sequence diagram illustrates the client workflow for accessing a remote host using an SSH certificate (and optionally key pair)
+supplied by Infisical.
+
+```mermaid
+sequenceDiagram
+  participant Client as Client
+  participant Infisical as Infisical (SSH CA)
+  participant Host as Remote Host
+
+  Note over Client,Client: Step 1: Client Authentication with Infisical
+  Client->>Infisical: Send credential(s) to authenticate with Infisical
+
+  Infisical-->>Client: Return access token
+
+  Note over Client,Infisical: Step 2: SSH Certificate Request
+  Client->>Infisical: Make authenticated request for SSH certificate via either /api/v1/ssh/issue or /api/v1/ssh/sign
+
+  Infisical-->>Client: Return signed SSH certificate (and optionally key pair)
+
+  Note over Client,Client: Step 3: SSH Operation
+  Client->>Host: SSH into Host using the SSH certificate
+
+  Host-->>Client: Grant access to the host
+```
+
+At a high-level, Infisical issues a signed SSH certificate to a client that can be used to access a remote host.
+
+To be more specific:
+
+1. The client authenticates with Infisical; this can be done using a machine identity [authentication method](/documentation/platform/identities/machine-identities) or a user [authentication method](/documentation/platform/identities/user-identities).
+2. The client makes an authenticated request for an SSH certificate via either the `/api/v1/ssh/issue` or `/api/v1/ssh/sign` endpoints. Note that if the client wishes to use an existing SSH key pair, it can use the `/api/v1/ssh/sign` endpoint; otherwise, it can use the `/api/v1/ssh/issue` endpoint to have Infisical issue a new SSH key pair in conjunction with the certificate.
+3. The client uses the issued SSH certificate (and potentially SSH key pair) to temporarily access the host.
+
+<Note>
+  Note that the workflow above requires an operator to perform additional
+  configuration on the remote host to trust SSH certificates issued by
+  Infisical.
+</Note>
+
+## Guide to Configuring Infisical SSH
+
+In the following steps, we explore how to configure Infisical SSH to start issuing SSH certificates to clients as well as a remote host to trust these certificates
+as part of the SSH operation.
+
+<Steps>
+  <Step title="Configuring Infisical SSH">
+    1.1. Start by creating a SSH project in the SSH tab of your organization.
+    
+    ![ssh project create](/images/platform/ssh/ssh-project.png)
+    
+    1.2. Next, create a CA in the **Certificate Authorities** tab of the
+    project.
+    
+    ![ssh create ca](/images/platform/ssh/ssh-create-ca-1.png)
+    
+    ![ssh create ca popup](/images/platform/ssh/ssh-create-ca-2.png)
+    
+    Here's some guidance on each field:
+
+    - Friendly Name: A friendly name for the CA; this is only for display.
+    - Key Algorithm: The type of public key algorithm and size, in bits, of the key pair for the CA. Supported key algorithms are `RSA 2048`, `RSA 4096`, `ECDSA P-256`, and `ECDSA P-384` with the default being `RSA 2048`.
+
+    1.3. Next, create a certificate template in the **Certificate Templates** section of the newly-created CA.
+
+    A certificate template is a set of policies for certificates issued under that template; each template is bound to a specific CA.
+
+    With certificate templates, you can specify, for example, that certificates issued under a template are only allowed for users with a specific username like `ec2-user` or perhaps that the max TTL requested cannot exceed 1 year.
+
+    ![ssh create template](/images/platform/ssh/ssh-create-template-1.png)
+
+    ![ssh create template popup](/images/platform/ssh/ssh-create-template-2.png)
+
+    Here's some guidance on each field:
+
+    - SSH Template Name: A name for the certificate template; this must be a valid slug.
+    - Allowed Users: A comma-separated list of valid usernames (e.g. `ec2-user`) on the remote host for which a client can request a certificate for. If you wish to allow a client to request a certificate for any username, set this to `*`; alternatively, if left blank, the template will not allow issuance of certificates under any username.
+    - Allowed Hosts: A comma-separated list of valid hostnames/domains on the remote host for which a client can request a certificate for. Each item in the list can be either a wildcard hostname (e.g. `*.acme.com`), a specific hostname (e.g. `example.com`), an IPv4 address (e.g. `192.168.1.1`), or an IPv6 address. If left empty, the template will not allow any hostnames; if set to `*`, the template will allow any hostname.
+    - Default TTL: The default Time-to-Live (TTL) for certificates issued under this template when a client does not explicitly specify a TTL in the certificate request.
+    - Max TTL: The maximum TTL for certificates issued under this template.
+    - Allow User Certificates: Whether or not to allow issuance of user certificates.
+    - Allow Host Certificates: Whether or not to allow issuance of host certificates.
+    - Allow Custom Key IDs: Whether or not to allow clients to specify a custom key ID to be included on the certificate as part of the certificate request.
+
+    1.4. Finally, add the user(s) you wish to be able to request a SSH certificate to the SSH project through the **Access Control** tab.
+
+  </Step>
+  <Step title="Configuring the remote host">
+  
+    2.1. Begin by downloading the CA's public key from the CA's details section.
+    
+    ![ssh ca public key](/images/platform/ssh/ssh-ca-public-key.png)
+    
+    <Note>
+      The CA's public key can also be retrieved programmatically via API by making a `GET` request to the `/ssh/ca/<ca-id>/public-key` endpoint.
+    </Note>
+    
+    2.2. Next, create a file containing this public key in the SSH folder of the remote host; we'll call the file `ca.pub`.
+
+    This would result in the file at the path `/etc/ssh/ca.pub`.
+
+    2.3. Next, add the following lines to the `/etc/ssh/sshd_config` file on the remote host.
+
+    ```bash
+    TrustedUserCAKeys /etc/ssh/ca.pub
+
+    PubkeyAcceptedKeyTypes=+ssh-rsa,ssh-rsa-cert-v01@openssh.com
+    ```
+
+    2.4. Finally, reload the SSH daemon on the remote host to apply the changes.
+
+    ```bash
+    sudo systemctl reload sshd
+    ```
+
+    At this point, the remote host is configured to trust SSH certificates issued by the Infisical SSH CA.
+
+  </Step>
+</Steps>
+
+## Guide to Using Infisical SSH to Access a Host
+
+We show how to obtain a SSH certificate (and optionally a new SSH key pair) for a client to access a host via CLI:
+
+<Steps>
+  <Step title="Authenticate with Infisical">
+
+```bash
+infisical login
+```
+
+  </Step>
+  <Step title="Obtain a SSH certificate (and optionally new key-pair)">
+    Depending on the use-case, a client may either request a SSH certificate along with a new SSH key pair or obtain a SSH certificate for an existing SSH key pair to access a host.
+
+    <AccordionGroup>
+      <Accordion title="Using New Key Pair (Recommended)">
+        If you wish to obtain a new SSH key pair in conjunction with the SSH certificate, then you can use the `infisical ssh issue-credentials` command.
+
+        ```bash
+        infisical ssh issue-credentials --certificateTemplateId=<certificate-template-id> --principals=<username>
+        ```
+
+        The following flags may be relevant:
+
+        - `certificateTemplateId`: The ID of the certificate template to use for issuing the SSH certificate.
+        - `principals`: The comma-delimited username(s) or hostname(s) to include in the SSH certificate.
+        - `outFilePath` (optional): The path to the file to write the SSH certificate to.
+
+        <Note>
+          If `outFilePath` is not specified, the SSH certificate will be written to the current working directory where the command is run.
+        </Note>
+
+      </Accordion>
+      <Accordion title="Using Existing Key Pair">
+        If you have an existing SSH key pair, then you can use the `infisical ssh sign-key` command with either
+        the `--publicKey` flag or the `--publicKeyFilePath` flag to obtain a SSH certificate corresponding to
+        the existing credential.
+
+        ```bash
+        infisical ssh sign-key --publicKeyFilePath=<public-key-file-path> --certificateTemplateId=<certificate-template-id> --principals=<username>
+        ```
+
+        The following flags may be relevant:
+
+        - `publicKey`: The public key to sign.
+        - `publicKeyFilePath`: The path to the public key file to sign.
+        - `certificateTemplateId`: The ID of the certificate template to use for issuing the SSH certificate.
+        - `principals`: The comma-delimited username(s) or hostname(s) to include in the SSH certificate.
+        - `outFilePath` (optional): The path to the file to write the SSH certificate to.
+
+        <Note>
+          If `outFilePath` is not specified but `publicKeyFilePath` is then the SSH certificate will be written to the directory of the public key file; if the public key file is called `id_rsa.pub`, then the file containing the SSH certificate will be called `id_rsa-cert.pub`.
+
+          Otherwise, if `outFilePath` is not specified, the SSH certificate will be written to the current working directory where the command is run.
+        </Note>
+
+      </Accordion>
+    </AccordionGroup>
+
+  </Step>
+  <Step title="SSH into the host">
+    Once you have obtained the SSH certificate, you can use it to SSH into the desired host.
+
+    ```bash
+    ssh -i /path/to/private_key.pem \
+    -o CertificateFile=/path/to/ssh-cert.pub \
+    username@hostname
+    ```
+
+    <Note>
+      We recommend setting up aliases so you can more easily SSH into the desired host.
+
+      For example, you may set up an SSH alias using the SSH client configuration file (usually `~/.ssh/config`), defining a host alias including the file path to the issued SSH credential(s).
+    </Note>
+
+  </Step>
+</Steps>
+
+<Note>
+  Note that the above workflow can be executed via API or other client methods
+  such as SDK.
+</Note>

docs/integrations/platforms/kubernetes.mdx

@@ -43,13 +43,28 @@ The operator can be install via [Helm](https://helm.sh) or [kubectl](https://git
 
     **Namespace-scoped Installation**
 
-    The operator can be configured to watch and manage secrets in a specific namespace instead of having cluster-wide access.
+    The operator can be configured to watch and manage secrets in a specific namespace instead of having cluster-wide access. This is useful for:
+
+    - **Enhanced Security**: Limit the operator's permissions to only specific namespaces instead of cluster-wide access
+    - **Multi-tenant Clusters**: Run separate operator instances for different teams or applications
+    - **Resource Isolation**: Ensure operators in different namespaces don't interfere with each other
+    - **Development & Testing**: Run development and production operators side by side in isolated namespaces
+
+    **Note**: For multiple namespace-scoped installations, only the first installation should install CRDs. Subsequent installations should set `installCRDs: false` to avoid conflicts.
 
     ```bash
-    helm install operator infisical-helm-charts/secrets-operator \
-      --namespace your-namespace \
-      --set scopedNamespace=your-namespace \
+    # First namespace installation (with CRDs)
+    helm install operator-namespace1 infisical-helm-charts/secrets-operator \
+      --namespace first-namespace \
+      --set scopedNamespace=first-namespace \
       --set scopedRBAC=true
+
+    # Subsequent namespace installations
+    helm install operator-namespace2 infisical-helm-charts/secrets-operator \
+      --namespace another-namespace \
+      --set scopedNamespace=another-namespace \
+      --set scopedRBAC=true \
+      --set installCRDs=false
     ```
 
     When scoped to a namespace, the operator will:
@@ -61,14 +76,19 @@ The operator can be install via [Helm](https://helm.sh) or [kubectl](https://git
     The default configuration gives cluster-wide access:
 
     ```yaml
+    installCRDs: true # Install CRDs (set to false for additional namespace installations)
     scopedNamespace: "" # Empty for cluster-wide access
     scopedRBAC: false # Cluster-wide permissions
     ```
 
+    If you want to install operators in multiple namespaces simultaneously:
+    - Make sure to set `installCRDs: false` for all but one of the installations to avoid conflicts, as CRDs are cluster-wide resources.
+    - Use unique release names for each installation (e.g., operator-namespace1, operator-namespace2).
+
    </Tab>
-	 <Tab title="Kubectl">
-   For production deployments, it is highly recommended to set the version of the Kubernetes operator manually instead of pointing to the latest version.
-   Doing so will help you avoid accidental updates to the newest release which may introduce unintended breaking changes. View all application versions [here](https://hub.docker.com/r/infisical/kubernetes-operator/tags).
+  <Tab title="Kubectl">
+  For production deployments, it is highly recommended to set the version of the Kubernetes operator manually instead of pointing to the latest version.
+  Doing so will help you avoid accidental updates to the newest release which may introduce unintended breaking changes. View all application versions [here](https://hub.docker.com/r/infisical/kubernetes-operator/tags).
 
 The command below will install the most recent version of the Kubernetes operator.
 However, to set the version manually, download the manifest and set the image tag version of `infisical/kubernetes-operator` according to your desired version.
@@ -714,6 +734,7 @@ Define secret keys and their corresponding templates.
 Each data value uses a Golang template with access to all secrets retrieved from the specified scope.
 
 Secrets are structured as follows:
+
 ```golang
 type TemplateSecret struct {
     Value      string `json:"value"`
@@ -722,6 +743,7 @@ type TemplateSecret struct {
 ```
 
 #### Example template configuration:
+
 ```golang
   managedSecretReference:
     secretName: managed-secret
@@ -733,19 +755,23 @@ type TemplateSecret struct {
 ```
 
 When you run the following command:
+
 ```bash
 kubectl get secret managed-secret -o jsonpath='{.data}'
 ```
 
 You'll receive Kubernetes secrets output that includes the NEW_KEY:
+
 ```bash
 {... "KEY":"d29ybGQ=","NEW_KEY":"LyBoZWxsbw=="}
 ```
 
 When you set `includeAllSecrets` as `false` the Kubernetes secrets outputs will be:
+
 ```bash
 {"NEW_KEY":"LyBoZWxsbw=="}
 ```
+
 </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. 
@@ -805,9 +831,9 @@ type: Opaque
 
 </Accordion>
 
-### Apply the Infisical CRD to your cluster
+### Apply the InfisicalSecret CRD to your cluster
 
-Once you have configured the Infisical CRD with the required fields, you can apply it to your cluster.
+Once you have configured the InfisicalSecret CRD with the required fields, you can apply it to your cluster.
 After applying, you should notice that the managed secret has been created in the desired namespace your specified.
 
 ```
@@ -1006,12 +1032,12 @@ stringData:
     -----END CERTIFICATE-----
 ```
 
-## Auto redeployment
+### Auto redeployment
 
 Deployments using managed secrets don't reload automatically on updates, so they may use outdated secrets unless manually redeployed.
 To address this, we added functionality to automatically redeploy your deployment when its managed secret updates.
 
-### Enabling auto redeploy
+#### Enabling auto redeploy
 
 To enable auto redeployment you simply have to add the following annotation to the deployment that consumes a managed secret
 
@@ -1054,6 +1080,419 @@ spec:
   When a secret change occurs, the operator will check to see which deployments are using the operator-managed Kubernetes secret that received the update. 
   Then, for each deployment that has this annotation present, a rolling update will be triggered.
 </Info>
+
+## Push Secrets to Infisical
+
+
+### Example usage
+
+Below is a sample InfisicalPushSecret CRD that pushes secrets defined in a Kubernetes secret to Infisical.
+
+After filling out the fields in the InfisicalPushSecret CRD, you can apply it directly to your cluster.
+
+Before applying the InfisicalPushSecret CRD, you need to create a Kubernetes secret containing the secrets you want to push to Infisical. An example can be seen below the InfisicalPushSecret CRD.
+
+```bash
+  kubectl apply -f source-secret.yaml
+```
+
+After applying the soruce-secret.yaml file, you are ready to apply the InfisicalPushSecret CRD.
+
+```bash
+  kubectl apply -f infisical-push-secret.yaml
+```
+
+After applying the InfisicalPushSecret CRD, you should notice that the secrets you have defined in your source-secret.yaml file have been pushed to your specified destination in Infisical.
+
+```yaml infisical-push-secret.yaml
+  apiVersion: secrets.infisical.com/v1alpha1
+  kind: InfisicalPushSecret
+  metadata:
+    name: infisical-push-secret-demo
+  spec:
+    resyncInterval: 1m
+    hostAPI: https://app.infisical.com/api
+
+    # Optional, defaults to no replacement.
+    updatePolicy: Replace # If set to replace, existing secrets inside Infisical will be replaced by the value of the PushSecret on sync.
+
+    # Optional, defaults to no deletion.
+    deletionPolicy: Delete # If set to delete, the secret(s) inside Infisical managed by the operator, will be deleted if the InfisicalPushSecret CRD is deleted.
+
+    destination:
+      projectId: <project-id>
+      environmentSlug: <env-slug>
+      secretsPath: <secret-path>
+
+    push:
+      secret:
+        secretName: push-secret-demo # Secret CRD
+        secretNamespace: default
+
+    # Only have one authentication method defined or you are likely to run into authentication issues.
+    # Remove all except one authentication method.
+    authentication:
+      awsIamAuth:
+        identityId: <machine-identity-id>
+      azureAuth:
+        identityId: <machine-identity-id>
+      gcpIamAuth:
+        identityId: <machine-identity-id>
+        serviceAccountKeyFilePath: </path-to-service-account-key-file.json>
+      gcpIdTokenAuth:
+        identityId: <machine-identity-id>
+      kubernetesAuth:
+        identityId: <machine-identity-id>
+        serviceAccountRef:
+          name: <secret-name>
+          namespace: <secret-namespace>
+      universalAuth:
+        credentialsRef:
+          secretName: <secret-name> # universal-auth-credentials
+          secretNamespace: <secret-namespace> # default
+```
+
+```yaml source-secret.yaml
+  apiVersion: v1
+  kind: Secret
+  metadata:
+    name: push-secret-demo
+    namespace: default
+  stringData: # can also be "data", but needs to be base64 encoded
+    API_KEY: some-api-key
+    DATABASE_URL: postgres://127.0.0.1:5432
+    ENCRYPTION_KEY: fabcc12-a22-facbaa4-11aa568aab
+```
+
+### InfisicalPushSecret CRD properties
+
+<Accordion title="hostAPI">
+  If you are fetching secrets from a self-hosted instance of Infisical set the value of `hostAPI` to 
+  ` https://your-self-hosted-instace.com/api`
+
+  When `hostAPI` is not defined the operator fetches secrets from Infisical Cloud.
+
+  <Accordion title="Advanced use case">
+    If you have installed your Infisical instance within the same cluster as the Infisical operator, you can optionally access the Infisical backend's service directly without having to route through the public internet. 
+    To achieve this, use the following address for the hostAPI field:
+    
+    ``` bash
+    http://<backend-svc-name>.<namespace>.svc.cluster.local:4000/api
+    ```
+
+    Make sure to replace `<backend-svc-name>` and `<namespace>` with the appropriate values for your backend service and namespace.
+
+  </Accordion>
+</Accordion>
+
+<Accordion title="resyncInterval">
+
+  The `resyncInterval` is a string-formatted duration that defines the time between each resync.
+
+  The format of the field is `[duration][unit]` where `duration` is a number and `unit` is a string representing the unit of time.
+
+  The following units are supported:
+  - `s` for seconds (must be at least 5 seconds)
+  - `m` for minutes
+  - `h` for hours
+  - `d` for days
+  - `w` for weeks
+
+  The default value is `1m` (1 minute).
+
+  Valid intervals examples:
+  ```yaml
+  resyncInterval: 5s # 10 seconds
+  resyncInterval: 10s # 10 seconds
+  resyncInterval: 5m # 5 minutes
+  resyncInterval: 1h # 1 hour
+  resyncInterval: 1d # 1 day
+  ```
+</Accordion>
+
+<Accordion title="updatePolicy">
+
+  The field is optional and will default to `None` if not defined.
+
+  The update policy defines how the operator should handle conflicting secrets when pushing secrets to Infisical.
+
+  Valid values are `None` and `Replace`.
+
+  Behavior of each policy:
+  - `None`: The operator will not override existing secrets in Infisical. If a secret with the same key already exists, the operator will skip pushing that secret, and the secret will not be managed by the operator.
+  - `Replace`: The operator will replace existing secrets in Infisical with the new secrets. If a secret with the same key already exists, the operator will update the secret with the new value.
+
+  ```yaml
+  spec:
+    updatePolicy: Replace
+  ```
+</Accordion>
+
+<Accordion title="deletionPolicy">
+
+  This field is optional and will default to `None` if not defined.
+
+  The deletion policy defines what the operator should do in case the InfisicalPushSecret CRD is deleted.
+
+  Valid values are `None` and `Delete`.
+
+  Behavior of each policy:
+  - `None`: The operator will not delete the secrets in Infisical when the InfisicalPushSecret CRD is deleted.
+  - `Delete`: The operator will delete the secrets in Infisical that are managed by the operator when the InfisicalPushSecret CRD is deleted.
+
+  ```yaml
+  spec:
+    deletionPolicy: Delete
+  ```
+</Accordion>
+
+<Accordion title="destination">
+  The `destination` field is used to specify where you want to create the secrets in Infisical. The required fields are `projectId`, `environmentSlug`, and `secretsPath`.
+  
+  ```yaml
+  spec:
+    destination:
+      projectId: <project-id>
+      environmentSlug: <env-slug>
+      secretsPath: <secrets-path>
+  ```
+
+  <Accordion title="destination.projectId">
+    The project ID where you want to create the secrets in Infisical.
+  </Accordion>
+
+  <Accordion title="destination.environmentSlug">
+    The environment slug where you want to create the secrets in Infisical.
+  </Accordion>
+
+  <Accordion title="destination.secretsPath">
+    The path where you want to create the secrets in Infisical. The root path is `/`.
+  </Accordion>
+
+</Accordion>
+
+<Accordion title="push">
+  The `push` field is used to define what you want to push to Infisical. Currently the operator only supports pushing Kubernetes secrets to Infisical. An example of the `push` field is shown below.
+  
+
+
+  <Accordion title="secret">
+    The `secret` field is used to define the Kubernetes secret you want to push to Infisical. The required fields are `secretName` and `secretNamespace`.
+
+
+
+    Example usage of the `push.secret` field: 
+
+    ```yaml infisical-push-secret.yaml
+      push:
+        secret:
+          secretName: push-secret-demo
+          secretNamespace: default
+    ```
+
+    ```yaml push-secret-demo.yaml
+      apiVersion: v1
+      kind: Secret
+      metadata:
+        name: push-secret-demo
+        namespace: default
+      # Pass in the secrets you wish to push to Infisical
+      stringData:
+        API_KEY: some-api-key
+        DATABASE_URL: postgres://127.0.0.1:5432
+        ENCRYPTION_KEY: fabcc12-a22-facbaa4-11aa568aab
+    ```
+
+  </Accordion>
+</Accordion>
+
+<Accordion title="authentication">
+
+  The `authentication` field dictates which authentication method to use when pushing secrets to Infisical.
+  The available authentication methods are `universalAuth`, `kubernetesAuth`, `awsIamAuth`, `azureAuth`, `gcpIdTokenAuth`, and `gcpIamAuth`.
+
+
+  <Accordion title="universalAuth">
+    The universal authentication method is one of the easiest ways to get started with Infisical. Universal Auth works anywhere and is not tied to any specific cloud provider.
+    [Read more about Universal Auth](/documentation/platform/identities/universal-auth).
+
+    Valid fields:
+    - `identityId`: The identity ID of the machine identity you created.
+    - `credentialsRef`: The name and namespace of the Kubernetes secret that stores the service token.
+    - `credentialsRef.secretName`: The name of the Kubernetes secret.
+    - `credentialsRef.secretNamespace`: The namespace of the Kubernetes secret.
+
+    Example:
+
+    ```yaml
+      # infisical-push-secret.yaml
+      spec:
+        universalAuth:
+          credentialsRef:
+            secretName: <secret-name> 
+            secretNamespace: <secret-namespace>
+    ```
+
+    ```yaml
+      # machine-identity-credentials.yaml
+      apiVersion: v1
+      kind: Secret
+      metadata:
+        name: universal-auth-credentials
+      type: Opaque
+      stringData:
+        clientId: <machine-identity-client-id>
+        clientSecret: <machine-identity-client-secret>
+    ```
+
+  </Accordion>
+  <Accordion title="kubernetesAuth">
+    The Kubernetes machine identity authentication method is used to authenticate with Infisical. The identity ID is stored in a field in the InfisicalSecret resource. This authentication method can only be used within a Kubernetes environment.
+    [Read more about Kubernetes Auth](/documentation/platform/identities/kubernetes-auth).
+    Valid fields:
+    - `identityId`: The identity ID of the machine identity you created.
+    - `serviceAccountRef`: The name and namespace of the service account that will be used to authenticate with Infisical.
+    - `serviceAccountRef.name`: The name of the service account.
+    - `serviceAccountRef.namespace`: The namespace of the service account.
+
+    Example:
+
+    ```yaml
+      spec:
+        kubernetesAuth:
+          identityId: <machine-identity-id>
+          serviceAccountRef:
+            name: <secret-name>
+            namespace: <secret-namespace>
+    ```
+  </Accordion>
+
+  <Accordion title="awsIamAuth">
+    The AWS IAM machine identity authentication method is used to authenticate with Infisical.
+    [Read more about AWS IAM Auth](/documentation/platform/identities/aws-auth).
+
+    Valid fields:
+    - `identityId`: The identity ID of the machine identity you created.
+
+    Example:
+
+    ```yaml
+      spec:
+        authentication:
+          awsIamAuth:
+            identityId: <machine-identity-id>
+    ```
+
+  </Accordion>
+  <Accordion title="azureAuth">
+    The AWS IAM machine identity authentication method is used to authenticate with Infisical. Azure Auth can only be used from within an Azure environment.
+    [Read more about Azure Auth](/documentation/platform/identities/azure-auth).
+
+    Valid fields:
+    - `identityId`: The identity ID of the machine identity you created.
+
+    Example:
+
+    ```yaml
+      spec:
+        authentication:
+          azureAuth:
+            identityId: <machine-identity-id>
+    ```
+  </Accordion>
+  <Accordion title="gcpIamAuth">
+    The GCP IAM machine identity authentication method is used to authenticate with Infisical. The identity ID is stored in a field in the InfisicalSecret resource. This authentication method can only be used both within and outside GCP environments.
+    [Read more about Azure Auth](/documentation/platform/identities/gcp-auth).
+
+
+    Valid fields:
+    - `identityId`: The identity ID of the machine identity you created.
+    - `serviceAccountKeyFilePath`: The path to the GCP service account key file.
+
+    Example:
+
+    ```yaml
+      spec:
+        gcpIamAuth:
+          identityId: <machine-identity-id>
+          serviceAccountKeyFilePath: </path-to-service-account-key-file.json>
+    ```
+  </Accordion>
+  <Accordion title="gcpIdTokenAuth">
+    The GCP ID Token machine identity authentication method is used to authenticate with Infisical. The identity ID is stored in a field in the InfisicalSecret resource. This authentication method can only be used within GCP environments.
+    [Read more about Azure Auth](/documentation/platform/identities/gcp-auth).
+
+    Valid fields:
+    - `identityId`: The identity ID of the machine identity you created.
+
+    Example:
+
+    ```yaml
+      spec:
+        gcpIdTokenAuth:
+          identityId: <machine-identity-id>
+    ```
+  </Accordion>
+
+</Accordion>
+
+
+<Accordion title="tls">
+  This block defines the TLS settings to use for connecting to the Infisical
+  instance.
+  
+  Fields:
+  <Accordion title="caRef">
+    This block defines the reference to the CA certificate to use for connecting to the Infisical instance with SSL/TLS.
+
+    Valid fields:
+    - `secretName`: The name of the Kubernetes secret containing the CA certificate to use for connecting to the Infisical instance with SSL/TLS.
+    - `secretNamespace`: The namespace of the Kubernetes secret containing the CA certificate to use for connecting to the Infisical instance with SSL/TLS.
+    - `key`: The name of the key in the Kubernetes secret which contains the value of the CA certificate to use for connecting to the Infisical instance with SSL/TLS.
+
+    Example:
+
+    ```yaml
+      tls:
+        caRef:
+          secretName: custom-ca-certificate
+          secretNamespace: default
+          key: ca.crt
+    ```
+  </Accordion>
+
+</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.
+After applying, you should notice that the secrets have been pushed to Infisical.
+
+```bash
+  kubectl apply -f source-push-secret.yaml # The secret that you're referencing in the InfisicalPushSecret CRD push.secret field
+  kubectl apply -f example-infisical-push-secret-crd.yaml # The InfisicalPushSecret CRD itself
+```
+
+### Connecting to instances with private/self-signed certificate
+
+To connect to Infisical instances behind a private/self-signed certificate, you can configure the TLS settings in the `InfisicalPushSecret` CRD
+to point to a CA certificate stored in a Kubernetes secret resource.
+
+```yaml
+spec:
+  hostAPI: https://app.infisical.com/api
+  resyncInterval: 30s
+  tls:
+    caRef:
+      secretName: custom-ca-certificate
+      secretNamespace: default
+      key: ca.crt
+  authentication:
+    # ... 
+```
+
+
 ## Global configuration
 
 To configure global settings that will apply to all instances of `InfisicalSecret`, you can define these configurations in a Kubernetes ConfigMap.

docs/mint.json

@@ -114,6 +114,7 @@
             "documentation/platform/pki/alerting"
           ]
         },
+        "documentation/platform/ssh",
         {
           "group": "Key Management (KMS)",
           "pages": [