diff --git a/.github/workflows/release-standalone-docker-img-postgres-offical.yml b/.github/workflows/release-standalone-docker-img-postgres-offical.yml index 9dc767e31..5d9f384f7 100644 --- a/.github/workflows/release-standalone-docker-img-postgres-offical.yml +++ b/.github/workflows/release-standalone-docker-img-postgres-offical.yml @@ -135,7 +135,9 @@ jobs: TAG_NAME="${{ github.ref_name }}" echo "Checking for tag: $TAG_NAME" - if gh api repos/Infisical/infisical-omnibus/git/refs/tags/$TAG_NAME --silent 2>/dev/null; then + EXACT_MATCH=$(gh api repos/Infisical/infisical-omnibus/git/refs/tags/$TAG_NAME | jq -r 'if type == "array" then .[].ref else .ref end' | grep -x "refs/tags/$TAG_NAME") + + if [ "$EXACT_MATCH" == "refs/tags/$TAG_NAME" ]; then echo "Tag $TAG_NAME already exists, skipping..." else echo "Creating tag in Infisical/infisical-omnibus: $TAG_NAME" diff --git a/Dockerfile.fips.standalone-infisical b/Dockerfile.fips.standalone-infisical index 1c03f752a..4dbf7872b 100644 --- a/Dockerfile.fips.standalone-infisical +++ b/Dockerfile.fips.standalone-infisical @@ -6,7 +6,7 @@ ARG CAPTCHA_SITE_KEY=captcha-site-key FROM node:20.19.5-trixie-slim AS base # Fixes NPM vulnerability: https://security.snyk.io/vuln/SNYK-JS-CROSSSPAWN-8303230 -RUN npm install -g npm@11 +RUN npm install -g npm@10.9.0 FROM base AS frontend-dependencies WORKDIR /app diff --git a/Dockerfile.standalone-infisical b/Dockerfile.standalone-infisical index bea94d6b6..bc80130be 100644 --- a/Dockerfile.standalone-infisical +++ b/Dockerfile.standalone-infisical @@ -6,7 +6,7 @@ ARG CAPTCHA_SITE_KEY=captcha-site-key FROM node:20.19.5-trixie-slim AS base # Fixes NPM vulnerability: https://security.snyk.io/vuln/SNYK-JS-CROSSSPAWN-8303230 -RUN npm install -g npm@11 +RUN npm install -g npm@10.9.0 FROM base AS frontend-dependencies diff --git a/backend/src/ee/services/hsm/hsm-fns.ts b/backend/src/ee/services/hsm/hsm-fns.ts index 8eec7ceb7..1afccdafe 100644 --- a/backend/src/ee/services/hsm/hsm-fns.ts +++ b/backend/src/ee/services/hsm/hsm-fns.ts @@ -25,7 +25,9 @@ export const initializeHsmModule = (envConfig: Pick { // count org identities const identityDoc = await (tx || db.replicaNode())(TableName.Membership) - .where({ status: OrgMembershipStatus.Accepted, scope: AccessScope.Organization }) + .where({ scope: AccessScope.Organization }) .whereNotNull(`${TableName.Membership}.actorIdentityId`) .where((bd) => { if (orgId) { diff --git a/backend/src/services/org/org-dal.ts b/backend/src/services/org/org-dal.ts index 288926f90..d987c890c 100644 --- a/backend/src/services/org/org-dal.ts +++ b/backend/src/services/org/org-dal.ts @@ -5,6 +5,7 @@ import { AccessScope, OrganizationsSchema, OrgMembershipRole, + OrgMembershipStatus, TableName, TMemberships, TMembershipsInsert, @@ -346,6 +347,7 @@ export const orgDALFactory = (db: TDbClient) => { .replicaNode()(TableName.Membership) .where(`${TableName.Membership}.scopeOrgId`, orgId) .where(`${TableName.Membership}.scope`, AccessScope.Organization) + .where(`${TableName.Membership}.status`, OrgMembershipStatus.Accepted) .whereNotNull(`${TableName.Membership}.actorUserId`) .count("*") .join(TableName.Users, `${TableName.Membership}.actorUserId`, `${TableName.Users}.id`) diff --git a/docs/CONTRIBUTING.MD b/docs/CONTRIBUTING.MD index a74f0985e..6983ad8f4 100644 --- a/docs/CONTRIBUTING.MD +++ b/docs/CONTRIBUTING.MD @@ -1,24 +1,24 @@ # Contributing to the documentation ## Getting familiar with Mintlify -New to Mintlify. [Start Here](https://mintlify.com/docs/quickstart) +New to Mintlify. [Start Here](https://mintlify.com/docs/quickstart) ## 👩‍💻 Development -Install the [Mintlify CLI](https://www.npmjs.com/package/mintlify) to preview the documentation changes locally. To install, use the following command +Install the [Mint CLI](https://www.npmjs.com/package/mint) to preview the documentation changes locally. To install, use the following command ``` -npm i -g mintlify +npm i -g mint ``` Run the following command at the root of your documentation (where mint.json is) ``` -mintlify dev +mint dev ``` ## Troubleshooting -- Mintlify dev isn't running - Run `mintlify install` it'll re-install dependencies. +- `mint dev` isn't running - Run `mint update` to update the Mint CLI. - Page loads as a 404 - Make sure you are running in a folder with `mint.json`. Check the `/docs` folder diff --git a/docs/contributing/platform/developing.mdx b/docs/contributing/platform/developing.mdx index 68add4603..69710baf3 100644 --- a/docs/contributing/platform/developing.mdx +++ b/docs/contributing/platform/developing.mdx @@ -43,23 +43,23 @@ docker compose -f docker-compose.dev.yml down We use [Mintlify](https://mintlify.com/) for our docs. -#### Install Mintlify CLI. +#### Install Mint CLI. ```bash -npm i -g mintlify +npm i -g mint ``` or ```bash -yarn global add mintlify +yarn global add mint ``` #### Running the docs -Go to `docs` directory and run `mintlify dev`. This will start up the docs on `localhost:3000` +Go to `docs` directory and run `mint dev`. This will start up the docs on `localhost:3000` ```bash # From the root directory -cd docs; mintlify dev; +cd docs; mint dev; ``` diff --git a/docs/docs.json b/docs/docs.json index 65db476f0..1129aa923 100644 --- a/docs/docs.json +++ b/docs/docs.json @@ -317,6 +317,7 @@ "self-hosting/deployment-options/linux-upgrade" ] }, + "self-hosting/guides/replication", "self-hosting/guides/upgrading-infisical", "self-hosting/configuration/envars", "self-hosting/guides/releases", diff --git a/docs/documentation/platform/kms/hsm-integration.mdx b/docs/documentation/platform/kms/hsm-integration.mdx index c7d4d32fa..45d883977 100644 --- a/docs/documentation/platform/kms/hsm-integration.mdx +++ b/docs/documentation/platform/kms/hsm-integration.mdx @@ -36,7 +36,6 @@ Enabling HSM encryption has a set of key benefits: ### Requirements - An Infisical instance with a version number that is equal to or greater than `v0.91.0`. -- If you are using Docker, your instance must be using the `infisical/infisical-fips` image. - An HSM device from a provider such as [Thales Luna HSM](https://cpl.thalesgroup.com/encryption/data-protection-on-demand/services/luna-cloud-hsm), [AWS CloudHSM](https://aws.amazon.com/cloudhsm/), [Fortanix HSM](https://www.fortanix.com/platform/data-security-manager), or others. @@ -238,7 +237,7 @@ Enabling HSM encryption has a set of key benefits: -e DB_CONNECTION_URI="<>" \ -e REDIS_URL="<>" \ -e SITE_URL="<>" \ - infisical/infisical-fips: # Replace with the version you want to use + infisical/infisical: # Replace with the version you want to use ``` We recommend reading further about [using Infisical with Docker](/self-hosting/deployment-options/standalone-infisical). @@ -309,7 +308,7 @@ Enabling HSM encryption has a set of key benefits: -e DB_CONNECTION_URI="<>" \ -e REDIS_URL="<>" \ -e SITE_URL="<>" \ - infisical/infisical-fips: # Replace with the version you want to use + infisical/infisical: # Replace with the version you want to use ``` @@ -319,6 +318,192 @@ Enabling HSM encryption has a set of key benefits: After following these steps, your Docker setup will be ready to use Fortanix HSM encryption. + + + + + + ### Prerequisites + + - An [activated AWS CloudHSM cluster](https://docs.aws.amazon.com/cloudhsm/latest/userguide/activate-cluster.html) with at least 1 HSM device. + - A [HSM user with the `Crypto User` role](https://docs.aws.amazon.com/cloudhsm/latest/userguide/cloudhsm_cli-user-create.html). In this guide we are using a user with the username `testUser` and the password `testPassword`. + + + + + + Before using the CloudHSM client, it must be configured properly so Infisical can use it for cryptographic operations. + + + **1. Download the AWS CloudHSM client** + + You can download the AWS CloudHSM client from [the AWS documentation](https://docs.aws.amazon.com/cloudhsm/latest/userguide/pkcs11-library-install.html). + + + Note that the AWS CloudHSM client is only available for Linux and Windows. + If you're on a different operating system, you'll need to access a Linux machine to configure the client, such as an AWS EC2 Debian instance. + + + **2. Configure the CloudHSM client** + + After installing the CloudHSM client, you should see all related files in the `/opt/cloudhsm/` directory on your machine. + + You need to run the `configure-pkcs11` binary which will configure the client to connect with your AWS CloudHSM cluster. Depending on if you have multiple HSM's inside your cluster, you'll need to run the command with different arguments. Below you'll find the appropriate command for your use case: + + + + + + ```bash + sudo /opt/cloudhsm/bin/configure-pkcs11 -a --disable-key-availability-check + ``` + + + To use a single HSM, you must first manage client key durability settings by setting `disable_key_availability_check` to true by passing the `--disable-key-availability-check` flag. For more information read the [Key Synchronization](https://docs.aws.amazon.com/cloudhsm/latest/userguide/manage-key-sync.html) section in the AWS CloudHSM documentation. + + + + + ```bash + sudo /opt/cloudhsm/bin/configure-pkcs11 -a ... --disable-key-availability-check + ``` + + + + At this point you should have: + 1. [Activated the CloudHSM cluster](https://docs.aws.amazon.com/cloudhsm/latest/userguide/activate-cluster.html) + 2. [Created a Crypto User HSM user](https://docs.aws.amazon.com/cloudhsm/latest/userguide/cloudhsm_cli-user-create.html) + 3. Downloaded and configured the CloudHSM client as described in the previous steps. + + **3. Download the configured HSM client files** + + After configuring the CloudHSM client, you should notice that the PKCS11 configuration file has been updated to include the HSM's ENI IP address. You can find this file in the `/opt/cloudhsm/etc/cloudhsm-pkcs11.cfg` directory, and it should look like this: + + ```json cloudhsm-pkcs11.cfg + { + "clusters": [ + { + "type": "hsm1", + "cluster": { + // Your issuing CA certificate. + // As per AWS documentation, this defaults to `/opt/cloudhsm/etc/customerCA.crt`. + "hsm_ca_file": "/opt/cloudhsm/etc/customerCA.crt", + "servers": [ + { + "hostname": "", + "port": 2223, + "enable": true + }, + { + "hostname": "", + "port": 2223, + "enable": true + } + ], + // Only relevant if you passed the --disable-key-availability-check flag + "options": { + "disable_key_availability_check": true + } + } + } + ], + "logging": { + "log_type": "file", + "log_file": "/opt/cloudhsm/run/cloudhsm-pkcs11.log", + "log_level": "info", + "log_interval": "daily" + } + } + ``` + + Save the entire `/opt/cloudhsm` folder, as you will need to mount this to your Infisical Docker container in the later steps. In this guide we will be saving all the files from the folder as `/etc/cloudhsm` and mounting it to the `/etc/cloudhsm` directory in the Docker container. + + + + + On the same machine that you configured the CloudHSM client, you can use `pkcs11-tool` to find the HSM slot number and to verify that the client is working correctly. + + First, install the `pkcs11-tool` package: + + ```bash + sudo apt-get install opensc -y + ``` + + Then, run the following command to find the HSM slot number: + + ```bash + pkcs11-tool --module /opt/cloudhsm/lib/libcloudhsm_pkcs11.so --list-slots --login + ``` + + It'll prompt you to log in with your PIN, which is your username and password separated by a colon. Example: `testUser:testPassword`. + + This will output the HSM slot number like so: + + ```bash + ubuntu@ec-2:~$ pkcs11-tool --module /opt/cloudhsm/lib/libcloudhsm_pkcs11.so --list-slots + Available slots: + Slot 0 (0x2000000000000001): hsm1 + token label : hsm1 + token manufacturer : Marvell Semiconductors, Inc. + token model : LS2 + token flags : login required, rng, token initialized + hardware version : 66.48 + firmware version : 10.2 + serial num : + pin min/max : 8/32 + ``` + + In this case we see that the HSM has a slot in the position of `0`. This slot number will be used in the later steps to set the `HSM_SLOT` environment variable. + + + + When you initialized your HSM, you were prompted to download the cluster CSR and sign it. + In order to use the HSM with Infisical, you need to obtain the issuer CA certificate that was used to sign the cluster CSR. + + If you followed [the official AWS documentation](https://docs.aws.amazon.com/cloudhsm/latest/userguide/initialize-cluster.html), you should have a CA certificate called `customerCA.crt`. + + Save the CA certificate to a path, as this will need to be mounted as a Docker volume in the next step. For this example, we'll save it to `/aws-files/customerCA.crt`. + + + + Running Docker with HSM encryption requires setting the HSM-related environment variables as mentioned previously in the [HSM setup instructions](#setup-instructions). You can set these environment variables in your Docker run command. + + We are setting the environment variables for Docker via the command line in this example, but you can also pass in a `.env` file to set these environment variables. + + + If no key is found with the provided key label, the HSM will create a new key with the provided label. + Infisical depends on an AES and HMAC key to be present in the HSM. If these keys are not present, Infisical will create them. The AES key label will be the value of the `HSM_KEY_LABEL` environment variable, and the HMAC key label will be the value of the `HSM_KEY_LABEL` environment variable with the suffix `_HMAC`. + + + ```bash + docker run -p 80:8080 \ + + # Mount the HSM client files to "/opt/cloudhsm" + -v /etc/cloudhsm:/opt/cloudhsm \ + # Mount the issuer CA certificate to "/opt/cloudhsm/etc/customerCA.crt" + -v /aws-files/customerCA.crt:/opt/cloudhsm/etc/customerCA.crt \ + + # Set the HSM library path to whats expected within Docker (/opt/cloudhsm/lib/libcloudhsm_pkcs11.so) + -e HSM_LIB_PATH="/opt/cloudhsm/lib/libcloudhsm_pkcs11.so" \ + # Set the HSM PIN to the username and password of the HSM user, separated by a colon + -e HSM_PIN=CryptoUserUsername:CryptoUserPassword \ + # Set the HSM slot number to the slot number of the HSM device as found in the previous step + -e HSM_SLOT= \ + # Set the HSM key label to a label that will be used to identify the encryption key in the HSM. This key label does not need to exist before hand. + -e HSM_KEY_LABEL=infisical-crypto-key \ + + # The rest of your environment variables ... + # -e ... + infisical/infisical: # Replace with the version you want to use + ``` + + We recommend reading further about [using Infisical with Docker](/self-hosting/deployment-options/standalone-infisical). + + + + After following these steps, your Docker setup will be ready to use HSM encryption. + + @@ -326,8 +511,9 @@ Enabling HSM encryption has a set of key benefits: + - This is only supported on helm chart version `1.4.1` and above. Please see the [Helm Chart Changelog](https://github.com/Infisical/infisical/blob/main/helm-charts/infisical-standalone-postgres/CHANGELOG.md#141-march-19-2025) for more information. + This is only supported on helm chart version `1.7.1` and above. Please see the [Helm Chart Changelog](https://github.com/Infisical/infisical/blob/main/helm-charts/infisical-standalone-postgres/CHANGELOG.md#141-march-19-2025) for more information. @@ -591,13 +777,11 @@ Enabling HSM encryption has a set of key benefits: After we've successfully configured the PVC and updated our environment variables, we are ready to update the deployment configuration so that the pods it creates can access the HSM client files. - We need to update the Docker image of the deployment to use `infisical/infisical-fips`. The `infisical/infisical-fips` image is a functionally identical image to the `infisical/infisical` image, but it is built with HSM support. - ```yaml # ... The rest of the values.yaml file ... image: - repository: infisical/infisical-fips # Very important: Must use "infisical/infisical-fips" + repository: infisical/infisical tag: "v0.117.1-postgres" pullPolicy: IfNotPresent @@ -757,13 +941,13 @@ Enabling HSM encryption has a set of key benefits: - Update your Helm values to use the FIPS-compliant image and mount the Fortanix HSM files: + Update your Helm values to mount the Fortanix HSM files: ```yaml # ... The rest of the values.yaml file ... image: - repository: infisical/infisical-fips # Must use "infisical/infisical-fips" + repository: infisical/infisical tag: "v0.117.1-postgres" pullPolicy: IfNotPresent @@ -800,6 +984,493 @@ Enabling HSM encryption has a set of key benefits: After following these steps, your Kubernetes setup will be ready to use Fortanix HSM encryption. + + + + ### Prerequisites + + - An [activated AWS CloudHSM cluster](https://docs.aws.amazon.com/cloudhsm/latest/userguide/activate-cluster.html) with at least 1 HSM device. + - A [HSM user with the `Crypto User` role](https://docs.aws.amazon.com/cloudhsm/latest/userguide/cloudhsm_cli-user-create.html). In this guide we are using a user with the username `testUser` and the password `testPassword`. + - A Kubernetes cluster + + + AWS CloudHSM is supported on helm chart version `1.7.1` and above. Please see the [Helm Chart Changelog](https://github.com/Infisical/infisical/blob/main/helm-charts/infisical-standalone-postgres/CHANGELOG.md#141-march-19-2025) for more information. + + + + + + + If you're using AWS EKS, you need to specify a storage class for the PVC and ensure that the EBS CSI Driver is installed and running. + + By default, EKS exposes `gp2` as the default storage class. Below are the steps required for setting the default storage class and ensuring the EBS CSI Driver is installed and running: + + + + + + Enable OIDC authentication for the EKS cluster: + ```bash + eksctl utils associate-iam-oidc-provider \ + --region \ + --cluster \ + --approve + ``` + + * Replace `` with your AWS region. + * Replace `` with your cluster name. + + + + + + 1. Check if EBS CSI Driver is installed and running by running the following command: + + ```bash + kubectl get pods -n kube-system | grep ebs-csi + ``` + + If you see no pods, you need to install the EBS CSI Driver as seen in the next step. + + + + Create a new IAM service account for the EBS CSI Driver: + + ```bash + eksctl create iamserviceaccount \ + --name ebs-csi-controller-sa \ + --namespace kube-system \ + --region \ + --cluster \ + --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \ + --approve \ + --role-name AmazonEKS_EBS_CSI_DriverRole + ``` + + * Replace `` with your cluster name. + * Replace `` with your AWS region. + + Install the EBS CSI Driver: + + ```bash + eksctl create addon \ + --name aws-ebs-csi-driver \ + --cluster \ + --region \ + --service-account-role-arn arn:aws:iam:::role/AmazonEKS_EBS_CSI_DriverRole \ + --force + ``` + + * Replace `` with your cluster name. + * Replace `` with your AWS region. + * Replace `` with your actual account ID. Can be obtained by running `aws sts get-caller-identity --query Account --output text`. + + + + Verify the EBS CSI Driver is installed and running by running the following command: + + ```bash + kubectl get pods -n kube-system | grep ebs-csi + ``` + + You should see an output like this: + + ```bash + kubectl get pods -n kube-system | grep ebs-csi + ebs-csi-controller-6b6bbf996-rvf8r 6/6 Running 0 21s + ebs-csi-controller-6b6bbf996-vk4ng 6/6 Running 0 21s + ebs-csi-node-c6vbb 3/3 Running 0 21s + ebs-csi-node-s9zlr 3/3 Running 0 21s + ``` + + + + You can find the enabled storage class by running the following command: + + ```bash + kubectl get storageclass + ``` + + You should see an output like this: + + ```bash + $ kubectl get storageclass + + NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE + gp2 kubernetes.io/aws-ebs Delete WaitForFirstConsumer false 65m + ``` + + In this case, the enabled storage class is `gp2`. + + + + You can set the default PVC storage class by patching the storage class with the following command: + + ```bash + kubectl patch storageclass gp2 -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' + ``` + + This will set the `gp2` storage class as the default storage class. + + + Now when you run `kubectl get storageclass`, you should see that `gp2` is the default storage class. + + ```bash + $ kubectl get storageclass + + NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE + gp2 (default) kubernetes.io/aws-ebs Delete WaitForFirstConsumer false 68m + ``` + + Notice the `(default)` next to the `gp2` storage class. + + + + + You need to create a Persistent Volume Claim (PVC) to mount the HSM client files to the Infisical deployment. + + ```bash + kubectl apply -f - < + + + + We need to configure the PVC to work with the CloudHSM, so Infisical can consume the HSM client files. + + **2.1. Start a shell in the PVC pod:** + + This will allow us to run commands directly within the setup pod. We'll use this to configure the CloudHSM client and to validate that it's working correctly. + + ```bash + kubectl exec -it cloudhsm-setup-pod -- /bin/sh + ``` + + **2.2. Install the necessary packages:** + + This will install the necessary packages to allow us to test and install the CloudHSM client. + + ```bash + apt-get update -y + apt-get install opensc telnet wget -y + ``` + + **2.3. Try to reach the HSM device:** + + We need to validate that we're able to reach the HSM device from within Kubernetes. You can use telnet to ping the HSM device like so: + + ```bash + telnet 2223 + ``` + + You should see an output like this: + ```bash + $ telnet 2223 + Trying ... + Connected to . + ``` + + If it gets stuck on `Trying ....`, you may have configured your HSM client's security group incorrectly. Make sure you configure the security group to allow traffic from EKS on port 2223-2225. + + **2.4. Install the AWS CloudHSM client:** + + The Infisical images run on Debian, so we need to install a Debian-compatible version of the AWS CloudHSM client. + + ```bash + wget https://s3.amazonaws.com/cloudhsmv2-software/CloudHsmClient/Jammy/cloudhsm-pkcs11_latest_u22.04_amd64.deb + apt-get install ./cloudhsm-pkcs11_latest_u22.04_amd64.deb -y + ``` + + **2.5. Configure the CloudHSM client:** + + After installing the CloudHSM client, you should see all related files in the `/opt/cloudhsm/` directory on the CloudHSM setup pod. + + You need to run the `configure-pkcs11` binary which will configure the client to connect with your AWS CloudHSM cluster. Depending on if you have multiple HSM's inside your cluster, you'll need to run the command with different arguments. Below you'll find the appropriate command for your use case: + + + + + ```bash + /opt/cloudhsm/bin/configure-pkcs11 -a --disable-key-availability-check + ``` + + + To use a single HSM, you must first manage client key durability settings by setting `disable_key_availability_check` to true by passing the `--disable-key-availability-check` flag. For more information read the [Key Synchronization](https://docs.aws.amazon.com/cloudhsm/latest/userguide/manage-key-sync.html) section in the AWS CloudHSM documentation. + + + + + ```bash + /opt/cloudhsm/bin/configure-pkcs11 -a ... --disable-key-availability-check + ``` + + + + **2.6. Verify the CloudHSM client is configured correctly:** + + You can verify the CloudHSM client is configured correctly by running the following command: + ```bash + cat /opt/cloudhsm/etc/cloudhsm-pkcs11.cfg + ``` + + You should see an output like this: + + ```json + { + "clusters": [ + { + "type": "hsm1", + "cluster": { + "hsm_ca_file": "/opt/cloudhsm/etc/customerCA.crt", + "servers": [ + { + "hostname": "172.31.39.155", + "port": 2223, + "enable": true + } + ], + "options": { + "disable_key_availability_check": true + } + } + } + ], + "logging": { + "log_type": "file", + "log_file": "/opt/cloudhsm/run/cloudhsm-pkcs11.log", + "log_level": "info", + "log_interval": "daily" + } + } + ``` + + **2.7. Exit the pod:** + + Exit the pod by running the following command: + ```bash + exit + ``` + + **2.8. Copy your issuer CA certificate to the PVC:** + + When you initialized your HSM, you were prompted to download the cluster CSR and sign it. + In order to use the HSM with Infisical, you need to obtain the issuer CA certificate that was used to sign the cluster CSR. + + If you followed [the official AWS documentation](https://docs.aws.amazon.com/cloudhsm/latest/userguide/initialize-cluster.html), you should have a CA certificate called `customerCA.crt`. + + Copy the CA certificate from your local machine to the setup pod: + + ```bash + kubectl cp /path/to/customerCA.crt cloudhsm-setup-pod:/opt/cloudhsm/etc/customerCA.crt + ``` + + Ensure that the file is at `/opt/cloudhsm/etc/customerCA.crt` inside the setup pod by running the following command: + ```bash + kubectl exec -it cloudhsm-setup-pod -- cat /opt/cloudhsm/etc/customerCA.crt + ``` + + **2.9. Test the HSM client:** + + Finally, after we're done configuring the HSM client, we need to test it to ensure that it's working correctly. + + First, start a new shell into the setup pod by running the same shell command as before: + ```bash + kubectl exec -it cloudhsm-setup-pod -- /bin/sh + ``` + + Next, try generating a random 32 bytes long string by running the following command: + ```bash + pkcs11-tool --module /opt/cloudhsm/lib/libcloudhsm_pkcs11.so \ + --login --pin : \ + --generate-random 32 | base64 + ``` + + You should see an output like this: + ```bash + Using slot 0 with a present token (0x2000000000000001) + av1dlhVEsssjpcTNS+ysGUoKWH6+/PCaEDIdal5oQc0= + ``` + + + Replace the `:` with your username and password combination of the Crypto user you have created that you want to use to perform cryptographic operations. + + In AWS CloudHSM, the PIN is always the username and password separated by a colon. + + + + + **2.10. Copy the configured client to the PVC:** + + Copy from the HSM files into the `/data` directory in the PVC, which is what will be mounted for the Infisical deployment. + ```bash + cp -r /opt/cloudhsm/. /data/ + ``` + + Verify the files were copied correctly by running the following command: + ```bash + ls -la /data/ + ``` + + You should see an output like this: + ```bash + drwxr-xr-x. 8 root root 4096 Oct 13 18:50 . + drwxr-xr-x. 1 root root 131 Oct 13 18:29 .. + drwxr-xr-x. 2 root root 4096 Oct 13 18:50 bin + drwxr-xr-x. 3 root root 4096 Oct 13 18:50 doc + drwxr-xr-x. 2 root root 4096 Oct 13 18:50 etc + drwxr-xr-x. 3 root root 4096 Oct 13 18:50 include + drwxr-xr-x. 2 root root 4096 Oct 13 18:50 lib + drwxr-xr-t. 2 root root 4096 Oct 13 18:50 run + ``` + + **2.11. Set the correct permissions for the HSM client files:** + + ```bash + chmod -R 755 /data/ + ``` + + **2.12. Exit the pod:** + + Exit the pod by running the following command: + ```bash + exit + ``` + + **2.13. Delete the setup pod:** + + Delete the setup pod by running the following command: + ```bash + kubectl delete pod cloudhsm-setup-pod + ``` + + + + + Next we need to update the environment variables used for the deployment. If you followed the [setup instructions for Kubernetes deployments](/self-hosting/deployment-options/kubernetes-helm), you should have a Kubernetes secret called `infisical-secrets`. + We need to update the secret with the following environment variables: + + - `HSM_LIB_PATH` - The path to the CloudHSM PKCS#11 library _(mapped to `/opt/cloudhsm/lib/libcloudhsm_pkcs11.so`)_ + - `HSM_PIN` - The PIN for the HSM device, which is the username and password of your Crypto User separated by a colon (e.g., `testUser:testPassword`) + - `HSM_SLOT` - The slot number for the HSM device that you found in the previous step + - `HSM_KEY_LABEL` - The label for the HSM key. If no key is found with the provided key label, the HSM will create a new key with the provided label. + + The following is an example of the secret that you should update: + + ```yaml + apiVersion: v1 + kind: Secret + metadata: + name: infisical-secrets + type: Opaque + stringData: + # ... Other environment variables ... + HSM_LIB_PATH: "/opt/cloudhsm/lib/libcloudhsm_pkcs11.so" + HSM_PIN: "testUser:testPassword" # Replace with your actual Crypto User credentials + HSM_SLOT: "0" # Replace with your actual slot number + HSM_KEY_LABEL: "infisical-crypto-key" + ``` + + Save the file after updating the environment variables, and apply the secret changes + + ```bash + kubectl apply -f ./secret-file-name.yaml + ``` + + + + After we've successfully configured the PVC and updated our environment variables, we are ready to update the deployment configuration so that the pods it creates can access the HSM client files. + + ```yaml + # ... The rest of the values.yaml file ... + infisical: + image: + repository: infisical/infisical + tag: "v0.151.0-nightly-20251013.1" + pullPolicy: IfNotPresent + + extraVolumeMounts: + - name: cloudhsm-data + mountPath: /opt/cloudhsm # The path we will mount the HSM client files to + + extraVolumes: + - name: cloudhsm-data + persistentVolumeClaim: + claimName: cloudhsm-data-pvc # The PVC we created in the previous step + + # ... The rest of the values.yaml file ... + ``` + + + Make sure to set the `tag` to **`v0.151.0-nightly-20251013.1` or above**, as this is the minimum Infisical version that supports AWS CloudHSM. + + + + Ensure that the configuration file at `/opt/cloudhsm/etc/cloudhsm-pkcs11.cfg` references the correct path for the issuer CA certificate (`/opt/cloudhsm/etc/customerCA.crt`). This should already be configured correctly if you followed the previous steps. + + + + + + After updating the values.yaml file, you need to upgrade the Helm chart in order for the changes to take effect. + + ```bash + helm repo update + helm upgrade --install infisical infisical-helm-charts/infisical-standalone --values /path/to/values.yaml + ``` + + + After upgrading the Helm chart, you need to restart the deployment in order for the changes to take effect. + + ```bash + kubectl rollout restart deployment/infisical-infisical-standalone-infisical + ``` + + + After following these steps, your Kubernetes setup will be ready to use AWS CloudHSM encryption. + diff --git a/docs/self-hosting/guides/replication.mdx b/docs/self-hosting/guides/replication.mdx new file mode 100644 index 000000000..4767da6fa --- /dev/null +++ b/docs/self-hosting/guides/replication.mdx @@ -0,0 +1,162 @@ +--- + +title: "Replication" +description: "Learn how Infisical supports multi-region replication" + +--- + + + Infisical replication 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 team@infisical.com to purchase an enterprise license to use it. + + +Multi-region replication is available in Infisical Enterprise to support globally distributed deployments. Understanding the architecture, use cases, and operational considerations is essential before implementing this feature in production environments. + +Infisical uses a primary/secondary (1:N) architecture with asynchronous PostgreSQL replication. This design prioritizes high availability and minimal read latency for applications deployed across multiple geographic regions. + +## Use cases + +- **Multi-Region Deployments**: Serving secrets to applications distributed across continents from a single region introduces unacceptable latency. A centralized deployment also creates a single point of failure: regional outages can render secrets inaccessible globally, and network connectivity issues impact availability. + +- **Geographic Data Locality**: Global organizations need to minimize the time it takes for applications to retrieve secrets and configurations. Regional replicas enable applications to fetch data from nearby instances rather than making cross-continental requests. + +- **Disaster Recovery**: Organizations need resilience against primary region failures. Secondary regions with read replicas can be promoted to primary status when needed, maintaining operations during outages or disasters. + +## Design Goals + +In order to address the common use cases, the implementation reflects several core goals: + +- **Optimized Read Performance**: Applications need fast access to secrets regardless of their location. Regional instances use Redis for aggressive caching and read from local PostgreSQL replicas, eliminating cross-region round trips for most read operations. + +- **Conflict-Free Architecture**: All mutations flow through the primary instance exclusively. This prevents write conflicts and split-brain scenarios that plague multi-master systems. The trade-off ensures data integrity without requiring conflict resolution strategies. + +- **Zero Client Changes**: Existing Infisical integrations, SDKs, and CLI tools work without modification. Regional instances route write operations to the primary while handling reads locally. Authentication tokens and API keys function identically across all instances. + +- **Operational Simplicity**: Deploying additional regions requires minimal configuration. PostgreSQL handles replication complexity, and the stateless application tier scales horizontally without coordination overhead. + +# Architecture + +Infisical distinguishes between _primary_ and _secondary_ instances. The primary holds write authority and is the sole instance permitted to modify the PostgreSQL database. Secondary instances handle read traffic locally and proxy write operations to the primary. + +## Infrastructure components + +Two data stores form Infisical's persistence layer: + +- **PostgreSQL** maintains the authoritative dataset including secrets with their version history, authentication credentials, user identities, project configurations, access policies, audit trails, and integration settings. All persistent state lives in PostgreSQL. + +- **Redis** accelerates read operations through caching and manages asynchronous job queues. Each regional deployment maintains an independent Redis instance optimized for local access patterns. + +The Infisical application servers are stateless and therefore hold no persistent data internally. This design simplifies regional deployment and horizontal scaling. + + + + + A primary deployment consists of three core components: + + - **Application Servers**: Process all API requests directly, handling both read and write operations without forwarding + - **PostgreSQL Primary Database**: Accepts read and write queries, serving as the authoritative source of truth + - **Redis Cache**: Stores frequently accessed data and executes all background jobs including secret synchronization, scheduled tasks, and audit log processing + + + + Each secondary deployment mirrors the primary structure with key differences: + + - **Application Servers**: Service read requests from local infrastructure but forward any write requests to the primary region + - **PostgreSQL Read Replica**: Continuously streams changes from the primary database via PostgreSQL replication + - **PostgreSQL Primary Database**: Connection string to the primary database for write forwarding + - **Redis Cache**: Maintains a local cache but processes only audit logs (other background jobs remain disabled) + + Configuring a secondary region requires four main environment variables: + + 1. `INFISICAL_PRIMARY_INSTANCE_URL`: The primary region's Infisical API endpoint + 2. Postgres primary instance connection details. View related [environment variables](/self-hosting/configuration/envars#postgresql). + 3. Postgres read replica connection details. View related [environment variables](/self-hosting/configuration/envars#postgresql). + 4. Redis connection details. View related [environment variables](/self-hosting/configuration/envars#redis). + + + + +## How requests are processed + +When a client sends a read request to a secondary instance, the application first checks the local Redis cache for the requested data. If the data exists in cache, it's returned immediately to the client. Otherwise, the application queries the local PostgreSQL read replica, caches the result in Redis for future requests, and returns the response to the client. + +Write operations follow a different path. When a secondary receives a write request, it forwards the complete request to the primary instance URL. The primary processes the mutation against the authoritative database and returns a response, which the secondary then forwards back to the client. PostgreSQL subsequently streams these changes to all replicas asynchronously. + +Operations against the primary instance are more straightforward, as both reads and writes execute directly against local infrastructure without any forwarding. + +## Replication mechanism + +PostgreSQL streaming replication handles all data synchronization. When transactions commit on the primary, changes are written to the write-ahead log (WAL) and streamed to all configured replicas, which apply the entries to maintain consistency. Replication lag typically remains under one second. + +This approach replicates all data stored in PostgreSQL: secrets and their version histories, user accounts and permissions, authentication tokens, project configurations, access policies, audit logs, integration settings, and all other application metadata. Replicas are eventually consistent. This means that all replicas eventually converge to the same state, typically under 1 second. The application layer remains unaware of replication mechanics and operates identically across all instances. + +## Caching behavior + +Redis caches are regional and independent (no coordination occurs between instances): + +- Secondary instances populate caches on demand from read requests +- Cache hits serve data without touching PostgreSQL +- Cache misses fetch from the local replica and populate the cache +- Each region maintains its own hot dataset based on local access patterns + +Secrets use versioned caching. When a secret changes, its version identifier changes, causing automatic cache misses. This ensures subsequent reads fetch the updated value from PostgreSQL without requiring active cache invalidation. + +# Technical Details + +Understanding the implementation details can help evaluate whether Infisical's replication characteristics align with your requirements. +The following sections provide deeper insight into performance behavior, failure modes, and the underlying mechanisms that drive the replication system. + +### PostgreSQL streaming replication + +Infisical relies on PostgreSQL's native replication, which provides: + +- **Asynchronous operation**: The primary commits transactions immediately without waiting for replicas to confirm receipt. Replicas receive and apply changes continuously with typical lag measured in milliseconds to low seconds, depending on network conditions and write volume. + +- **Binary-level consistency**: Replication occurs at the storage layer using write-ahead logs, guaranteeing replicas are byte-for-byte identical to the primary at the block level. + +- **Promotion capability**: Read replicas can be promoted to primary during disaster recovery. Promotion requires updating Infisical configuration to designate the promoted instance as primary and reconfiguring other secondaries. + +Consult PostgreSQL's official documentation for replication setup instructions specific to your hosting environment (RDS, Cloud SQL, self-managed, etc.). + +### Version management + +All Infisical instances must run identical versions (mixing versions risks database schema mismatches or incompatible API behavior). Database migrations execute only on the primary and replicate to secondaries through standard PostgreSQL mechanisms. + +During upgrades: +1. Upgrade the primary instance (migrations run automatically) +2. Upgrade secondary instances to match +3. All instances can continue running during the upgrade process since database migrations don't immediately drop tables/columns + +### Request proxying + +When a secondary receives a mutation request (POST, PUT, PATCH, DELETE), it functions as a transparent proxy: + +1. Preserve the original request completely (headers, authentication context, request body) +2. Forward to the primary instance URL specified in configuration +3. Primary processes the request as a direct client request +4. Return the primary's response unmodified to the client + +### Cache management + +Infisical uses versioned caching rather than active invalidation: + +1. Secrets and other cached entities include version identifiers +2. When data mutates, its version changes in the database +3. Cache lookups include the version in the cache key +4. Version changes cause automatic cache misses +5. Cache misses fetch updated data from PostgreSQL +6. Fresh data populates the cache with the new version + +This strategy ensures correctness without requiring cross-region cache invalidation protocols. + +### Background job processing + +Secondary instances run with restricted background job capabilities: + +**Active**: Audit log processing +**Disabled**: Secret synchronization to third-party systems, scheduled tasks, cron jobs, time-triggered operations + +Limiting background jobs to the primary prevents duplicate processing and ensures integrations execute once. + diff --git a/frontend/public/locales/en/translations.json b/frontend/public/locales/en/translations.json index fdfefcf93..de3b99f11 100644 --- a/frontend/public/locales/en/translations.json +++ b/frontend/public/locales/en/translations.json @@ -270,7 +270,7 @@ "description": "This page shows the members of the selected project, and allows you to modify their permissions." }, "org": { - "title": "Organization Settings", + "title": "Settings", "description": "Manage members of your organization. These users could afterwards be formed into projects." }, "personal": { @@ -290,7 +290,7 @@ } }, "project": { - "title": "Project Settings", + "title": "Settings", "description": "These settings only apply to the currently selected Project.", "danger-zone": "Danger Zone", "delete-project": "Delete Project", diff --git a/frontend/src/components/tags/CreateTagModal/CreateTagModal.tsx b/frontend/src/components/tags/CreateTagModal/CreateTagModal.tsx index 1c2891f42..3c38926af 100644 --- a/frontend/src/components/tags/CreateTagModal/CreateTagModal.tsx +++ b/frontend/src/components/tags/CreateTagModal/CreateTagModal.tsx @@ -17,6 +17,7 @@ import { } from "@app/components/v2"; import { useProject } from "@app/context"; import { useCreateWsTag } from "@app/hooks/api"; +import { SecretV3RawSanitized, WsTag } from "@app/hooks/api/types"; import { slugSchema } from "@app/lib/schemas"; export const secretTagsColors = [ @@ -85,6 +86,8 @@ const isValidHexColor = (hexColor: string) => { type Props = { isOpen?: boolean; onToggle: (isOpen: boolean) => void; + append: (data: WsTag) => void; + currentSecret?: SecretV3RawSanitized; }; const createTagSchema = z.object({ @@ -100,7 +103,7 @@ type TagColor = { name: string; }; -export const CreateTagModal = ({ isOpen, onToggle }: Props): JSX.Element => { +export const CreateTagModal = ({ isOpen, onToggle, append, currentSecret }: Props): JSX.Element => { const { control, reset, @@ -128,11 +131,12 @@ export const CreateTagModal = ({ isOpen, onToggle }: Props): JSX.Element => { const onFormSubmit = async ({ slug, color }: FormData) => { try { - await createWsTag({ + const data = await createWsTag({ projectId, tagColor: color, tagSlug: slug }); + append(data); onToggle(false); reset(); createNotification({ @@ -151,8 +155,12 @@ export const CreateTagModal = ({ isOpen, onToggle }: Props): JSX.Element => { return (
{ isDisabled={isSubmitting} isLoading={isSubmitting} > - Create + {currentSecret ? "Create and Add" : "Create"} diff --git a/frontend/src/pages/secret-manager/CommitDetailsPage/components/RollbackPreviewTab/RollbackPreviewTab.tsx b/frontend/src/pages/secret-manager/CommitDetailsPage/components/RollbackPreviewTab/RollbackPreviewTab.tsx index 89124e3b9..a3a25b1cc 100644 --- a/frontend/src/pages/secret-manager/CommitDetailsPage/components/RollbackPreviewTab/RollbackPreviewTab.tsx +++ b/frontend/src/pages/secret-manager/CommitDetailsPage/components/RollbackPreviewTab/RollbackPreviewTab.tsx @@ -307,6 +307,7 @@ export const RollbackPreviewTab = (): JSX.Element => {
diff --git a/frontend/src/pages/secret-manager/CommitsPage/CommitsPage.tsx b/frontend/src/pages/secret-manager/CommitsPage/CommitsPage.tsx index 2dba8ad55..e456bbdf3 100644 --- a/frontend/src/pages/secret-manager/CommitsPage/CommitsPage.tsx +++ b/frontend/src/pages/secret-manager/CommitsPage/CommitsPage.tsx @@ -49,6 +49,7 @@ export const CommitsPage = () => {
diff --git a/frontend/src/pages/secret-manager/IntegrationsDetailsByIDPage/IntegrationsDetailsByIDPage.tsx b/frontend/src/pages/secret-manager/IntegrationsDetailsByIDPage/IntegrationsDetailsByIDPage.tsx index 98dc087ea..0eaa7dfac 100644 --- a/frontend/src/pages/secret-manager/IntegrationsDetailsByIDPage/IntegrationsDetailsByIDPage.tsx +++ b/frontend/src/pages/secret-manager/IntegrationsDetailsByIDPage/IntegrationsDetailsByIDPage.tsx @@ -94,6 +94,7 @@ export const IntegrationDetailsByIDPage = () => { {integration ? (
diff --git a/frontend/src/pages/secret-manager/IntegrationsListPage/IntegrationsListPage.tsx b/frontend/src/pages/secret-manager/IntegrationsListPage/IntegrationsListPage.tsx index 647af2039..4e2a0a703 100644 --- a/frontend/src/pages/secret-manager/IntegrationsListPage/IntegrationsListPage.tsx +++ b/frontend/src/pages/secret-manager/IntegrationsListPage/IntegrationsListPage.tsx @@ -48,6 +48,7 @@ export const IntegrationsListPage = () => {
diff --git a/frontend/src/pages/secret-manager/OverviewPage/OverviewPage.tsx b/frontend/src/pages/secret-manager/OverviewPage/OverviewPage.tsx index 860f161e9..022b33f88 100644 --- a/frontend/src/pages/secret-manager/OverviewPage/OverviewPage.tsx +++ b/frontend/src/pages/secret-manager/OverviewPage/OverviewPage.tsx @@ -914,6 +914,7 @@ export const OverviewPage = () => {
diff --git a/frontend/src/pages/secret-manager/OverviewPage/components/SecretOverviewTableRow/SecretEditRow.tsx b/frontend/src/pages/secret-manager/OverviewPage/components/SecretOverviewTableRow/SecretEditRow.tsx index b0f9f7666..1a33bbca1 100644 --- a/frontend/src/pages/secret-manager/OverviewPage/components/SecretOverviewTableRow/SecretEditRow.tsx +++ b/frontend/src/pages/secret-manager/OverviewPage/components/SecretOverviewTableRow/SecretEditRow.tsx @@ -82,6 +82,7 @@ type Props = { isImported: boolean; }[]; }[]; + isSecretPresent?: boolean; }; export const SecretEditRow = ({ @@ -101,7 +102,8 @@ export const SecretEditRow = ({ isRotatedSecret, importedBy, importedSecret, - isEmpty + isEmpty, + isSecretPresent }: Props) => { const { handlePopUpOpen, handlePopUpToggle, handlePopUpClose, popUp } = usePopUp([ "editSecret" @@ -113,20 +115,21 @@ export const SecretEditRow = ({ const [isFieldFocused, setIsFieldFocused] = useToggle(); - const fetchSecretValueParams = importedSecret - ? { - environment: importedSecret.environment, - secretPath: importedSecret.secretPath, - secretKey: importedSecret.secret?.key ?? "", - projectId: currentProject.id - } - : { - environment, - secretPath, - secretKey: secretName, - projectId: currentProject.id, - isOverride - }; + const fetchSecretValueParams = + importedSecret && !isSecretPresent + ? { + environment: importedSecret.environment, + secretPath: importedSecret.secretPath, + secretKey: importedSecret.secret?.key ?? "", + projectId: currentProject.id + } + : { + environment, + secretPath, + secretKey: secretName, + projectId: currentProject.id, + isOverride + }; // scott: only fetch value if secret exists, has non-empty value and user has permission const canFetchValue = Boolean(importedSecret ?? secretId) && !isEmpty && !secretValueHidden; diff --git a/frontend/src/pages/secret-manager/OverviewPage/components/SecretOverviewTableRow/SecretOverviewTableRow.tsx b/frontend/src/pages/secret-manager/OverviewPage/components/SecretOverviewTableRow/SecretOverviewTableRow.tsx index 2a2e1a76a..2099d812d 100644 --- a/frontend/src/pages/secret-manager/OverviewPage/components/SecretOverviewTableRow/SecretOverviewTableRow.tsx +++ b/frontend/src/pages/secret-manager/OverviewPage/components/SecretOverviewTableRow/SecretOverviewTableRow.tsx @@ -284,6 +284,7 @@ export const SecretOverviewTableRow = ({ environment={slug} isRotatedSecret={secret?.isRotatedSecret} importedBy={importedBy} + isSecretPresent={Boolean(secret)} /> diff --git a/frontend/src/pages/secret-manager/SecretApprovalsPage/SecretApprovalsPage.tsx b/frontend/src/pages/secret-manager/SecretApprovalsPage/SecretApprovalsPage.tsx index 77106a57c..6813aac07 100644 --- a/frontend/src/pages/secret-manager/SecretApprovalsPage/SecretApprovalsPage.tsx +++ b/frontend/src/pages/secret-manager/SecretApprovalsPage/SecretApprovalsPage.tsx @@ -40,6 +40,7 @@ export const SecretApprovalsPage = () => {
diff --git a/frontend/src/pages/secret-manager/SecretDashboardPage/SecretDashboardPage.tsx b/frontend/src/pages/secret-manager/SecretDashboardPage/SecretDashboardPage.tsx index 2760e8626..da31fcf09 100644 --- a/frontend/src/pages/secret-manager/SecretDashboardPage/SecretDashboardPage.tsx +++ b/frontend/src/pages/secret-manager/SecretDashboardPage/SecretDashboardPage.tsx @@ -762,6 +762,7 @@ const Page = () => { return (
diff --git a/frontend/src/pages/secret-manager/SecretDashboardPage/components/SecretListView/SecretItem.tsx b/frontend/src/pages/secret-manager/SecretDashboardPage/components/SecretListView/SecretItem.tsx index 0398baf95..a57995b72 100644 --- a/frontend/src/pages/secret-manager/SecretDashboardPage/components/SecretListView/SecretItem.tsx +++ b/frontend/src/pages/secret-manager/SecretDashboardPage/components/SecretListView/SecretItem.tsx @@ -79,7 +79,7 @@ type Props = { isSelected?: boolean; onToggleSecretSelect: (secret: SecretV3RawSanitized) => void; tags: WsTag[]; - onCreateTag: () => void; + onCreateTag: (secret?: SecretV3RawSanitized) => void; environment: string; secretPath: string; onShareSecret: (sec: SecretV3RawSanitized) => void; @@ -731,7 +731,7 @@ export const SecretItem = memo( className="h-3 w-3" /> } - onClick={onCreateTag} + onClick={() => onCreateTag(secret)} > Create a tag @@ -924,7 +924,7 @@ export const SecretItem = memo( className="h-3 w-3" /> } - onClick={onCreateTag} + onClick={() => onCreateTag(secret)} > Create a tag diff --git a/frontend/src/pages/secret-manager/SecretDashboardPage/components/SecretListView/SecretListView.tsx b/frontend/src/pages/secret-manager/SecretDashboardPage/components/SecretListView/SecretListView.tsx index 4fc314bdd..bd43e1271 100644 --- a/frontend/src/pages/secret-manager/SecretDashboardPage/components/SecretListView/SecretListView.tsx +++ b/frontend/src/pages/secret-manager/SecretDashboardPage/components/SecretListView/SecretListView.tsx @@ -465,6 +465,22 @@ export const SecretListView = ({ [environment, secretPath, isProtectedBranch, isBatchMode, projectId, addPendingChange] ); + // Function to append newly created tag to the current secret + const append = useCallback( + (newTag: WsTag) => { + const currentSecret = popUp.createTag.data as SecretV3RawSanitized; + if (!currentSecret) return; + + const updatedTags = [...(currentSecret.tags || []), { id: newTag.id, slug: newTag.slug }]; + + handleSaveSecret(currentSecret, { + ...currentSecret, + tags: updatedTags + }); + }, + [popUp.createTag.data, handleSaveSecret] + ); + const handleSecretDelete = useCallback(async () => { const { key, @@ -552,7 +568,13 @@ export const SecretListView = ({ ]); // for optimization on minimise re-rendering of secret items - const onCreateTag = useCallback(() => handlePopUpOpen("createTag"), []); + const onCreateTag = useCallback((secret?: SecretV3RawSanitized) => { + if (secret) { + handlePopUpOpen("createTag", secret); + } else { + handlePopUpOpen("createTag"); + } + }, []); const onDeleteSecret = useCallback( (sec: SecretV3RawSanitized) => handlePopUpOpen("deleteSecret", sec), [] @@ -640,6 +662,8 @@ export const SecretListView = ({ handlePopUpToggle("createTag", isOpen)} + append={append} + currentSecret={popUp.createTag.data} /> diff --git a/frontend/src/pages/secret-manager/SecretRotationPage/SecretRotationPage.tsx b/frontend/src/pages/secret-manager/SecretRotationPage/SecretRotationPage.tsx index 0b9263803..f4b474b9e 100644 --- a/frontend/src/pages/secret-manager/SecretRotationPage/SecretRotationPage.tsx +++ b/frontend/src/pages/secret-manager/SecretRotationPage/SecretRotationPage.tsx @@ -147,6 +147,7 @@ const Page = () => { return (
diff --git a/frontend/src/pages/secret-manager/SettingsPage/SettingsPage.tsx b/frontend/src/pages/secret-manager/SettingsPage/SettingsPage.tsx index ad037b125..a97775013 100644 --- a/frontend/src/pages/secret-manager/SettingsPage/SettingsPage.tsx +++ b/frontend/src/pages/secret-manager/SettingsPage/SettingsPage.tsx @@ -42,6 +42,7 @@ export const SettingsPage = () => {
diff --git a/frontend/src/pages/secret-scanning/SecretScanningDataSourcesPage/SecretScanningDataSourcesPage.tsx b/frontend/src/pages/secret-scanning/SecretScanningDataSourcesPage/SecretScanningDataSourcesPage.tsx index d681c34af..71ffd8286 100644 --- a/frontend/src/pages/secret-scanning/SecretScanningDataSourcesPage/SecretScanningDataSourcesPage.tsx +++ b/frontend/src/pages/secret-scanning/SecretScanningDataSourcesPage/SecretScanningDataSourcesPage.tsx @@ -26,6 +26,7 @@ export const SecretScanningDataSourcesPage = () => {
diff --git a/frontend/src/pages/secret-scanning/SecretScanningFindingsPage/SecretScanningFindingsPage.tsx b/frontend/src/pages/secret-scanning/SecretScanningFindingsPage/SecretScanningFindingsPage.tsx index 1eddf5eee..320d29428 100644 --- a/frontend/src/pages/secret-scanning/SecretScanningFindingsPage/SecretScanningFindingsPage.tsx +++ b/frontend/src/pages/secret-scanning/SecretScanningFindingsPage/SecretScanningFindingsPage.tsx @@ -23,7 +23,11 @@ export const SecretScanningFindingsPage = () => {
- +
diff --git a/frontend/src/pages/secret-scanning/SettingsPage/SettingsPage.tsx b/frontend/src/pages/secret-scanning/SettingsPage/SettingsPage.tsx index 07161c360..84a885cff 100644 --- a/frontend/src/pages/secret-scanning/SettingsPage/SettingsPage.tsx +++ b/frontend/src/pages/secret-scanning/SettingsPage/SettingsPage.tsx @@ -19,6 +19,7 @@ export const SettingsPage = () => {
diff --git a/frontend/src/pages/ssh/SettingsPage/SettingsPage.tsx b/frontend/src/pages/ssh/SettingsPage/SettingsPage.tsx index 841bb119f..e820e1488 100644 --- a/frontend/src/pages/ssh/SettingsPage/SettingsPage.tsx +++ b/frontend/src/pages/ssh/SettingsPage/SettingsPage.tsx @@ -17,7 +17,11 @@ export const SettingsPage = () => { {t("common.head-title", { title: t("settings.project.title") })}
- + General diff --git a/frontend/src/pages/ssh/SshCaByIDPage/SshCaByIDPage.tsx b/frontend/src/pages/ssh/SshCaByIDPage/SshCaByIDPage.tsx index 06567b121..4f8325594 100644 --- a/frontend/src/pages/ssh/SshCaByIDPage/SshCaByIDPage.tsx +++ b/frontend/src/pages/ssh/SshCaByIDPage/SshCaByIDPage.tsx @@ -70,7 +70,7 @@ const Page = () => {
{data && (
- +
diff --git a/frontend/src/pages/ssh/SshCasPage/SshCasPage.tsx b/frontend/src/pages/ssh/SshCasPage/SshCasPage.tsx index 669e26404..1156de3f0 100644 --- a/frontend/src/pages/ssh/SshCasPage/SshCasPage.tsx +++ b/frontend/src/pages/ssh/SshCasPage/SshCasPage.tsx @@ -16,6 +16,7 @@ export const SshCasPage = () => {
diff --git a/frontend/src/pages/ssh/SshCertsPage/SshCertsPage.tsx b/frontend/src/pages/ssh/SshCertsPage/SshCertsPage.tsx index 617f480a3..0078bd4b2 100644 --- a/frontend/src/pages/ssh/SshCertsPage/SshCertsPage.tsx +++ b/frontend/src/pages/ssh/SshCertsPage/SshCertsPage.tsx @@ -16,6 +16,7 @@ export const SshCertsPage = () => {
diff --git a/frontend/src/pages/ssh/SshHostGroupDetailsByIDPage/SshHostGroupDetailsByIDPage.tsx b/frontend/src/pages/ssh/SshHostGroupDetailsByIDPage/SshHostGroupDetailsByIDPage.tsx index 1605286a8..8cbca6848 100644 --- a/frontend/src/pages/ssh/SshHostGroupDetailsByIDPage/SshHostGroupDetailsByIDPage.tsx +++ b/frontend/src/pages/ssh/SshHostGroupDetailsByIDPage/SshHostGroupDetailsByIDPage.tsx @@ -71,7 +71,7 @@ const Page = () => {
{data && (
- +
diff --git a/frontend/src/pages/ssh/SshHostsPage/SshHostsPage.tsx b/frontend/src/pages/ssh/SshHostsPage/SshHostsPage.tsx index c6efa9670..7c83eff1d 100644 --- a/frontend/src/pages/ssh/SshHostsPage/SshHostsPage.tsx +++ b/frontend/src/pages/ssh/SshHostsPage/SshHostsPage.tsx @@ -16,6 +16,7 @@ export const SshHostsPage = () => {