mirror of
https://github.com/awatertrevi/infisical.git
synced 2026-09-22 13:39:35 +00:00
Merge branch 'main' into ENG-3925
This commit is contained in:
x032205
239
docs/documentation/guides/kubernetes-operator.mdx
Normal file
239
docs/documentation/guides/kubernetes-operator.mdx
Normal file
@@ -0,0 +1,239 @@
|
||||
---
|
||||
title: "Managing Secrets With Kubernetes Operator"
|
||||
sidebarTitle: "Kubernetes Operator"
|
||||
description: "How to use the Infisical Kubernetes Operator to Push Secrets, Pull Secrets, and Generate Dynamic Secrets within your clusters."
|
||||
---
|
||||
|
||||
Infisical's Kubernetes Operator provides a seamless, secure, and automated way to synchronize secrets between your Infisical instance and your Kubernetes clusters. The Operator's three Custom Resource Definitions (CRDs) make this possible. In this guide, we provide the necessary CRDs and configurations for your kubernetes cluster, but you can customize them to fit your use-case.
|
||||
|
||||
In this guide, we'll walk through how to:
|
||||
|
||||
1. **Install the Infisical Operator on your Kubernetes cluster**.
|
||||
2. **Configure Authentication using Kubernetes Service Accounts**.
|
||||
3. **Use Each of the three CRDs**.
|
||||
- **InfisicalSecret** [Sync secrets from Infisical to Kubernetes]
|
||||
- **InfisicalPushSecret** [Sync secrets from Kubernetes to Infisical]
|
||||
- **InfisicalDynamicSecret** [Manage Dynamic Secrets and automatically create time-bound leases]
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before we begin, make sure your environment is ready
|
||||
1. Installed tools
|
||||
- [helm](https://helm.sh/docs/intro/install/), [git](https://git-scm.com/downloads), [kubectl](https://kubernetes.io/docs/tasks/tools/)
|
||||
2. Kubernetes Cluster
|
||||
- Ensure you have access to a running cluster and connect with kubectl
|
||||
3. PostgreSQL Cluster (for InfisicalDynamicSecret)
|
||||
- Ensure you have a running database that you have access to
|
||||
4. Clone [infisical-guides-source-code](https://github.com/Infisical/infisical-guides-source-code) repository
|
||||
5. Access to an Infisical instance (cloud or self-hosted)
|
||||
|
||||
## Step-By-Step Guide
|
||||
<Steps titleSize="h2">
|
||||
|
||||
<Step title="Install the Infisical Operator">
|
||||
|
||||
The [Infisical Operator](https://infisical.com/docs/integrations/platforms/kubernetes/overview) runs inside your cluster and is responsible for handling secret synchronization events.
|
||||
|
||||
```console
|
||||
helm repo add infisical-helm-charts 'https://dl.cloudsmith.io/public/infisical/helm-charts/helm/charts/'
|
||||
helm repo update
|
||||
helm install infisical-operator infisical-helm-charts/secrets-operator
|
||||
```
|
||||
|
||||
Verify the operator pod is running:
|
||||
|
||||
```console
|
||||
kubectl get pods -n default
|
||||
```
|
||||
</Step>
|
||||
<Step title="Create a Machine Identity and Set Up a Project">
|
||||
|
||||
The operator uses a [Machine Identity](https://infisical.com/docs/documentation/platform/identities/machine-identities) to authenticate with Infisical through the Kubernetes Auth Method
|
||||
1. Login to [Infisical](https://app.infisical.com/)
|
||||
2. Select **Organization Access** from the left navigational pane
|
||||
3. Create an Identity and give it a name and a role
|
||||
4. Once the Machine Identity is created, copy the **Identity ID** (will be used later)
|
||||
5. Select the created Machine Identity, and add a [Kubernetes Authentication Method](https://infisical.com/docs/documentation/platform/identities/kubernetes-auth). Use these configurations:
|
||||
- **Allowed Service Account Names**: infisical-service-account, default
|
||||
- **Allowed Namespaces**: default
|
||||
- **Kubernetes Host URL** can be found by running ```kubectl cluster-info```
|
||||
- **Token Reviewer JWT / CA Certificate**: We will be generating these two later and adding them in later, leave it blank for now
|
||||
6. Once the Machine Identity has been created, navigate back to **Overview**
|
||||
7. Now select **Add New Project**
|
||||
- Add a **Project Name**, and select **Secrets Management** as the product type
|
||||
- Add a description (Optional).
|
||||
8. Once the Project is created, navigate into the Project to **Add Secrets**. You can add any key-value pair for this example, however if you want to use the InfisicalSecret CRD example provided in this demo, use the following configurations:
|
||||
- **Key**: SMTP_HOST
|
||||
- **Value**: smtp@gmail.com
|
||||
- **Tags**: N/A (Not needed for this demonstration)
|
||||
- **Environments**: Production
|
||||
9. Now lets navigate to the **Project Access** tab on the left hand navigation pane.
|
||||
- Add the machine identity we created, and give it Admin permissions (just for demonstration purposes)
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Set Up RBAC, Service Accounts, and Create Tokens">
|
||||
|
||||
Now we will be interacting with the local repository you cloned earlier. Make sure you are in the directory that contains the yaml configurations. Assuming you are in your root user directory:
|
||||
|
||||
```console
|
||||
cd infisical-guides-source-code/kubernetes-operator-demo
|
||||
```
|
||||
|
||||
1. Create the ```infisical-token-reviewer``` service account. This Manifest creates a **service account** that the Infisical Operator uses to authenticate with Kubernetes for token reviews. It allows Infisical to validate Kubernetes tokens securely during the Machine Identity authentication process.
|
||||
```console
|
||||
kubectl apply -f infisical-reviewer-service-account.yaml
|
||||
```
|
||||
2. Create the token for the reviewer service account. This Yaml defines a **service account token secret** linked to the reviewer account created above. It generates a JWT token that Infisical uses for the Kubernetes Auth Method in your Machine Identity configuration.
|
||||
```console
|
||||
kubectl apply -f service-account-reviewer-token.yaml
|
||||
```
|
||||
3. This file binds the ```infisical-token-reviewer``` service account to the built-in ```system:auth-delegator``` ClusterRole. That role allows the service account to perform **token review** and **authentication delegation** requests on behalf of other service accounts - a key part of Kubernetes-based identity verification. Without this binding, the Infisical Operator wouldn't have permission to validate tokens.
|
||||
```console
|
||||
kubectl apply -f cluster-role-binding.yaml
|
||||
```
|
||||
4. Create the service account that will be used by the InfisicalSecret. This file creates a **dedicated service account** ```infisical-service-account``` that the Infisical Operator uses to access and sync secrets within your cluster. It operates as the Operator's working identity in your cluster, separate from the token reviewer.
|
||||
```console
|
||||
kubectl apply -f infisical-service-account.yaml
|
||||
```
|
||||
5. Create the token for the Infisical service account. This manifest defines a **token secret** for the ```infisical-service-account```. It allows the Infisical operator to authenticate against Infisical's API when syncing secrets. The token will then be manually patched and associated with the service account to make sure Kubernetes mains it persistently.
|
||||
```console
|
||||
kubectl apply -f infisical-service-account-token.yaml
|
||||
```
|
||||
6. Apply the patch to manually associate the token secret
|
||||
```console
|
||||
kubectl patch serviceaccount infisical-service-account -p '{"secrets": [{"name": "infisical-service-account-token"}]}' -n default
|
||||
```
|
||||
7. Create the **JWT Token** and **Certificate** and add it to the **Machine Identity** we created under **Kubernetes Auth**. For the generated CA, navigate to the **Advanced** tab to paste the certificate:
|
||||
- JWT Command
|
||||
```console
|
||||
kubectl get secret infisical-token-reviewer-token -n default -o jsonpath='{.data.token}' | base64 -d
|
||||
```
|
||||
|
||||
- CA Command
|
||||
```console
|
||||
kubectl get secret infisical-token-reviewer-token -n default -o jsonpath='{.data.ca\.crt}' | base64 -d
|
||||
```
|
||||
</Step>
|
||||
<Step title="Verify Service Accounts and Tokens">
|
||||
|
||||
1. Check to see if the service accounts were created
|
||||
|
||||
```console
|
||||
kubectl get serviceaccount -n default | grep infisical
|
||||
```
|
||||
|
||||
2. Verify the tokens were created and linked
|
||||
|
||||
```console
|
||||
kubectl get secrets -n default | grep infisical
|
||||
```
|
||||
</Step>
|
||||
<Step title="Create the InfisicalSecret CRD">
|
||||
|
||||
The [InfisicalSecret](https://infisical.com/docs/integrations/platforms/kubernetes/infisical-secret-crd) CRD tells the operator to sync secrets from Infisical to Kubernetes. By referencing your ```identityID```, ```projectSlug```, and ```envSlug```, this CRD tells the Infisical Operator which Infisical secrets to fetch and how to format them into a Kubernetes Secret. Make sure to edit the provided CRD to match your specific Machine Identity ID, Project ID, and which environment your secrets are being pulled from (default is prod).
|
||||
- **Project Slug**: Can be found when you select your project and navigate to settings
|
||||
- **Identity ID**: Can be found when you select your machine identity from your organization's access control
|
||||
|
||||
1. After editing the ```example-infisical-secret-crd.yaml``` to contain your demo-specific values, apply the yaml in your cluster
|
||||
```console
|
||||
kubectl apply -f example-infisical-secret-crd.yaml
|
||||
```
|
||||
|
||||
</Step>
|
||||
<Step title="Verify the InfisicalSecret Status">
|
||||
|
||||
1. Check that the ```InfisicalSecret``` was created successfully
|
||||
```console
|
||||
kubectl get infisicalsecret -n default
|
||||
```
|
||||
2. Check that the operator created the ```managed-secret```
|
||||
```console
|
||||
kubectl get secret managed-secret -n default
|
||||
```
|
||||
3. View the secret contents (base64 encoded)
|
||||
```console
|
||||
kubectl get secret managed-secret -n default -o jsonpath='{.data}' | jq
|
||||
```
|
||||
</Step>
|
||||
<Step title="Deploy the Demo Application">
|
||||
|
||||
1. Deploy the nginx demo deployment that will use the managed secret.
|
||||
```console
|
||||
kubectl apply -f demo-deployment.yaml
|
||||
```
|
||||
2. Wait 15-20 seconds and then verify the deployments
|
||||
```console
|
||||
kubectl get deployments
|
||||
kubectl get pods -l app=nginx
|
||||
```
|
||||
</Step>
|
||||
<Step title="Verify the Secret is Injected Into the Pod">
|
||||
|
||||
1. Check that the environment variable is in the running pod. If everything was successful, at this point you should be able to see the secret populate in the kubernetes pod and have a successful **sync** from Infisical to Kubernetes.
|
||||
```console
|
||||
kubectl exec -it $(kubectl get pod -l app=nginx -o jsonpath='{.items[0].metadata.name}') -- env | grep SMTP
|
||||
```
|
||||
</Step>
|
||||
<Step title="Create a Kubernetes Secret to Push Up to Infisical">
|
||||
|
||||
Now that we have successfully synced secrets from Infisical to Kubernetes, lets explore how we can push **Kubernetes Secrets** to Infisical.
|
||||
|
||||
1. Either create a **Kubernetes Secret** via yaml, or use the one in the repository.
|
||||
```console
|
||||
kubectl apply -f source-secret.yaml
|
||||
```
|
||||
2. Verify creation of the secret
|
||||
```console
|
||||
kubectl get secret push-secret-demo -n default -o yaml
|
||||
```
|
||||
</Step>
|
||||
<Step title="Create the InfisicalPushSecret CRD">
|
||||
|
||||
The [InfisicalPushSecret](https://infisical.com/docs/integrations/platforms/kubernetes/infisical-push-secret-crd) CRD tells the operator to sync secrets from Kubernetes to Infisical. Make sure you edit the CRD to include the specific **Project Slug**, and **Identity ID**. The other values present in ```example-push-secret.yaml``` should be configured based on the previously committed yaml configurations.
|
||||
|
||||
1. Apply the InfisicalPushSecret CRD provided after making the necessary changes
|
||||
```console
|
||||
kubectl apply -f example-push-secret-crd.yaml
|
||||
```
|
||||
|
||||
2. Once your CRD has been configured, go back to your project within Infisical and check to see if your secrets have populated there.
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Create the InfisicalDynamicSecret CRD">
|
||||
|
||||
The [InfisicalDynamicSecret](https://infisical.com/docs/integrations/platforms/kubernetes/infisical-dynamic-secret-crd) CRD allows you to sync dynamic secrets and create leases automatically in Kubernetes as native **Kubernetes Secret** resources Any Pod, Deployment, or other Kubernetes resource can make use of dynamic secrets from Infisical just like any other Kubernetes secret.
|
||||
|
||||
1. Navigate to your Infisical **Project** and click on the dropdown next to **Add Secret**. From here you will select **Add Dynamic Secret**
|
||||
- Select **SQL Database** as the service you would like to connect to.
|
||||
- Select **PostegreSQL** as the database service. Enter in the connection details for your database, specifically the **Host**, **Port**, **User**, **Password**, and **Database Name**.
|
||||
- For the **Secret Name**, if you want to use the same name as the one in the cloned **InfisicalDynamicSecret** CRD, use the name **dynamic-secret-lease**. Otherwise you will need to change the **dynamicSecret.secretName** config in the InfisicalDynamicSecret CRD to whatever you name the secret here.
|
||||
- In the CA (SSL) section, make sure to upload the **CA Certificate** for your database.
|
||||
- Finally, select **Prod** as the environment (we are keeping this configuration as part of the demonstration).
|
||||
|
||||
|
||||
|
||||
2. Edit the ```dynamic-secret-crd``` with the proper machine **Identity ID**, **Project Slug**, **dynamicSecret.secretName** (same as the **Secret Name** you gave to the dynamic secret in Infisical), and managedSecretReference.secretName (name of the kubernetes secret that Infisical Operator will create/populate in the cluster).
|
||||
- If you want to keep the **managedSecretReference.secretName** then you can leave it as **dynamic-secret-test**
|
||||
|
||||
3. Once the changes have been saved, apply the yaml:
|
||||
|
||||
```console
|
||||
kubectl apply -f dynamic-secret-crd.yaml
|
||||
```
|
||||
|
||||
4. After applying the CRD, you should notice that the dynamic secret lease has been created and synced with your cluster. Verify by running:
|
||||
|
||||
```console
|
||||
kubectl get secret dynamic-secret-test -n default -o yaml
|
||||
```
|
||||
|
||||
5. Once the dynamic secret lease has been created, you should see that the secret has data that contains the lease credentials.
|
||||
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
**Congratulations! You successfully managed secrets with Kubernetes.**
|
||||
@@ -1,16 +1,22 @@
|
||||
---
|
||||
title: "External Migrations"
|
||||
sidebarTitle: "Overview"
|
||||
description: "Learn how to migrate secrets from third-party secrets management platforms to Infisical."
|
||||
description: "Learn how to migrate resources from third-party secrets management platforms to Infisical."
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Infisical supports migrating secrets from third-party secrets management platforms to Infisical. This is useful if you're looking to easily switch to Infisical and wish to move over your existing secrets from a different platform.
|
||||
Infisical supports migrating resources from third-party secrets management platforms to Infisical. This is useful if you're looking to easily switch to Infisical and wish to move over your existing resources from a different platform.
|
||||
|
||||
Infisical offers two types of migration approaches:
|
||||
|
||||
- **In-Platform Migration Tooling**: Configure platform connections to enable granular, on-demand imports of secrets, policies, and configurations directly within the Infisical UI. This allows you to migrate resources incrementally as needed.
|
||||
|
||||
- **Bulk Data Import**: Perform one-time organization-level migrations to import all resources from external platforms at once. This is ideal for initial migrations when moving entirely to Infisical.
|
||||
|
||||
## Supported Platforms
|
||||
|
||||
- [EnvKey](./envkey)
|
||||
- [Vault](./vault)
|
||||
|
||||
We're always looking to add more migration paths for other providers. If we're missing a platform, please open an issue on our [GitHub repository](https://github.com/infisical/infisical/issues).
|
||||
We're always looking to add more migration paths for other providers. If we're missing a platform, please open an issue on our [GitHub repository](https://github.com/infisical/infisical/issues).
|
||||
|
||||
@@ -1,40 +1,239 @@
|
||||
---
|
||||
title: "Migrating from Vault to Infisical"
|
||||
sidebarTitle: "Vault"
|
||||
description: "Learn how to migrate secrets from Vault to Infisical."
|
||||
description: "Learn how to migrate resources from Vault to Infisical."
|
||||
---
|
||||
|
||||
## Migrating from Vault
|
||||
Infisical provides two approaches for migrating from HashiCorp Vault.
|
||||
|
||||
Migrating from Vault Self-Hosted or Dedicated Vault is a straight forward process with our inbuilt migration option. In order to migrate from Vault, you'll need to provide Infisical an access token to your Vault instance.
|
||||
### Which approach should I use?
|
||||
|
||||
Currently the Vault migration only supports migrating secrets from the KV V2 and V1 secrets engine. If you're using a different secrets engine, please open an issue on our [GitHub repository](https://github.com/infisical/infisical/issues).
|
||||
**Choose In-Platform Migration Tooling if you want to:**
|
||||
|
||||
- Migrate specific secrets, not everything at once
|
||||
- Import secrets into existing Infisical projects
|
||||
- Translate Vault policies to Infisical access controls
|
||||
- Import Kubernetes authentication configurations
|
||||
- Have more control over the migration process
|
||||
|
||||
### Prerequisites
|
||||
**Choose Bulk Data Import if you want to:**
|
||||
|
||||
- A Vault instance with the KV secret engine enabled.
|
||||
- An access token to your Vault instance.
|
||||
|
||||
|
||||
### Project Mapping
|
||||
|
||||
When migrating from Vault, you'll need to choose how you want to map your Vault resources to Infisical projects.
|
||||
|
||||
There are two options for project mapping:
|
||||
|
||||
- `Namespace`: This will map your selected Vault namespace to a single Infisical project. When you select this option, each KV secret engine within the namespace will be mapped to a single Infisical project. Each KV secret engine will be mapped to a Infisical environment within the project. This means if you have 3 KV secret engines, you'll have 3 environments inside the same project, where the name of the environments correspond to the name of the KV secret engines.
|
||||
- `Key Vault`: This will map all the KV secret engines within your Vault instance to a Infisical project. Each KV engine will be created as a Infisical project. This means if you have 3 KV secret engines, you'll have 3 Infisical projects. For each of the created projects, a single default environment will be created called `Production`, which will contain all your secrets from the corresponding KV secret engine.
|
||||
- Migrate all secrets from Vault in one go
|
||||
- Automatically create new Infisical projects from your Vault structure
|
||||
- Perform a one-time migration when moving entirely from Vault to Infisical
|
||||
|
||||
## In-Platform Migration Tooling
|
||||
|
||||
This migration approach lets you set up a connection to your Vault instance once, then import specific resources as needed throughout Infisical.
|
||||
|
||||
### Step 1: Set Up Your Vault Connection
|
||||
|
||||
<Steps>
|
||||
<Step title="Create a Vault policy">
|
||||
In order to migrate from Vault, you'll need to create a Vault policy that allows Infisical to read the secrets and metadata from the KV v2 secrets engines within your Vault instance.
|
||||
In your Vault instance, create a policy that allows Infisical to read your secrets, policies, and authentication configurations. This policy grants read-only access and doesn't allow Infisical to modify anything in Vault.
|
||||
|
||||
<Accordion title="View the complete policy">
|
||||
```hcl
|
||||
# System endpoints - for listing namespaces, policies, mounts, and auth methods
|
||||
path "sys/namespaces" {
|
||||
capabilities = ["list"]
|
||||
}
|
||||
|
||||
```python
|
||||
path "sys/policy" {
|
||||
capabilities = ["read", "list"]
|
||||
}
|
||||
|
||||
path "sys/policy/*" {
|
||||
capabilities = ["read"]
|
||||
}
|
||||
|
||||
path "sys/mounts" {
|
||||
capabilities = ["read"]
|
||||
}
|
||||
|
||||
path "sys/auth" {
|
||||
capabilities = ["read"]
|
||||
}
|
||||
|
||||
# KV v2 secrets - for listing and reading secrets
|
||||
# Replace '+' with your actual KV v2 mount paths (e.g., "secret", "kv")
|
||||
path "+/metadata/*" {
|
||||
capabilities = ["list", "read"]
|
||||
}
|
||||
|
||||
path "+/data/*" {
|
||||
capabilities = ["read"]
|
||||
}
|
||||
|
||||
# KV v1 secrets - for listing and reading secrets
|
||||
# Replace '+' with your actual KV v1 mount paths (e.g., "secret", "kv-v1")
|
||||
# WARNING: This is broad - ideally specify exact mount names
|
||||
path "+/*" {
|
||||
capabilities = ["list", "read"]
|
||||
}
|
||||
|
||||
# Kubernetes auth - for reading auth configuration and roles
|
||||
path "auth/+/config" {
|
||||
capabilities = ["read"]
|
||||
}
|
||||
|
||||
path "auth/+/role" {
|
||||
capabilities = ["list"]
|
||||
}
|
||||
|
||||
path "auth/+/role/*" {
|
||||
capabilities = ["read"]
|
||||
}
|
||||
```
|
||||
</Accordion>
|
||||
|
||||
Save this policy in Vault with the name `infisical-in-platform-migration`.
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Create an App Connection in Infisical">
|
||||
In Infisical, navigate to **Organization Settings > App Connections** and create a new HashiCorp Vault connection.
|
||||
|
||||
Follow the [HashiCorp Vault App Connection documentation](/integrations/app-connections/hashicorp-vault) for detailed setup instructions. When configuring authentication (Token or AppRole), make sure it uses the `infisical-in-platform-migration` policy you created.
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Add Vault Namespaces for Migration">
|
||||
Navigate to **Organization Settings > External Migrations** in Infisical.
|
||||
|
||||
Under the "In-Platform Migration Tooling" section for HashiCorp Vault, click **"+ Add Namespace"**.
|
||||
|
||||
|
||||
|
||||
Configure your namespace:
|
||||
|
||||
|
||||
|
||||
- **Namespace**: Enter your Vault namespace path (e.g., `admin/namespace1`). If you intend to use the root namespace, set the namespace value to "root".
|
||||
- **Connection**: Select the App Connection you created in the previous step.
|
||||
|
||||
<Note>
|
||||
You can add multiple namespaces with different connections if you have multiple Vault instances or namespaces to migrate from.
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
### Step 2: Import Your Resources
|
||||
|
||||
Once your Vault connection is configured, you'll see import options throughout Infisical wherever relevant. Here's what you can import:
|
||||
|
||||
#### Import Secrets into a Project
|
||||
|
||||
You can import secrets from Vault directly into a specific environment and secret path:
|
||||
|
||||
1. Navigate to your project and select a specific environment (e.g., Development, Production)
|
||||
2. In the secrets view, click the dropdown icon (caret) next to the **"+ Add Secret"** button
|
||||
3. Select **"Add from HashiCorp Vault"**
|
||||
|
||||
|
||||
|
||||
4. Choose your Vault namespace and the secret path you want to import
|
||||
5. Click **"Import Secrets"**
|
||||
|
||||
The secrets will be imported into your current environment and folder path.
|
||||
|
||||
#### Import Kubernetes Authentication Configurations
|
||||
|
||||
When setting up Kubernetes authentication for a machine identity, you can import the configuration from Vault:
|
||||
|
||||
1. Navigate to **Access Control > Machine Identities** and select an identity
|
||||
2. Click **"Add Authentication Method"** and choose **Kubernetes Auth**
|
||||
3. In the configuration modal, click **"Load from Vault"**
|
||||
|
||||
|
||||
|
||||
4. Select your Vault namespace and the Kubernetes role
|
||||
5. Click **"Load"**
|
||||
|
||||
|
||||
|
||||
The authentication settings (service accounts, TTL, policies, etc.) will be automatically populated from your Vault configuration.
|
||||
|
||||
<Note>
|
||||
Sensitive values like service account JWTs cannot be retrieved from Vault and
|
||||
must be manually provided in the form after importing the configuration.
|
||||
</Note>
|
||||
|
||||
#### Import and Translate Access Control Policies
|
||||
|
||||
When configuring project role-based access control, you can import Vault HCL policies and automatically translate them to Infisical permissions.
|
||||
|
||||
<Note>
|
||||
Policy translation is best-effort and provides a starting point based on your
|
||||
Vault configuration. The translated permissions should be reviewed and
|
||||
adjusted as needed since Vault and Infisical have different access control
|
||||
models. Infisical will analyze path patterns and capabilities to suggest
|
||||
equivalent permissions.
|
||||
</Note>
|
||||
|
||||
**To import and translate a policy:**
|
||||
|
||||
1. Navigate to your project, then go to **Access Control > Roles** and create or edit a role
|
||||
2. In the policy configuration, click **"Add from HashiCorp Vault"**
|
||||
|
||||
|
||||
|
||||
3. Select your Vault namespace
|
||||
4. Either choose an existing policy from the dropdown or paste your own HCL policy
|
||||
|
||||
|
||||
|
||||
5. Review the automatically translated Infisical permissions
|
||||
6. Make any adjustments and save
|
||||
|
||||
<Tip>
|
||||
**How policy translation works:**
|
||||
|
||||
- Vault path patterns are analyzed to identify KV secret engines and environments
|
||||
- Vault capabilities (`read`,`list`, `create`, etc.) are mapped to Infisical permissions
|
||||
- Wildcards in paths are converted to glob patterns
|
||||
- Secret paths are preserved for granular access control
|
||||
|
||||
Always review the translated permissions carefully, as Vault's capability-based model may not map 1:1 with Infisical's permission structure.
|
||||
</Tip>
|
||||
|
||||
---
|
||||
|
||||
## Bulk Data Import
|
||||
|
||||
This migration approach imports all secrets from your Vault instance in one operation and automatically creates new Infisical projects based on your Vault structure.
|
||||
|
||||
### Understanding Project Mapping
|
||||
|
||||
Before starting the bulk import, you need to decide how your Vault structure will map to Infisical projects:
|
||||
|
||||
<Accordion title="Namespace Mapping (One Project Per Namespace)">
|
||||
Each Vault namespace becomes a single Infisical project, with each KV secret engine becoming an environment within that project.
|
||||
|
||||
**Example:** If you have a namespace with 3 KV secret engines (`dev-secrets`, `staging-secrets`, `prod-secrets`):
|
||||
|
||||
- Creates: 1 Infisical project
|
||||
- Environments: 3 (`dev-secrets`, `staging-secrets`, `prod-secrets`)
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Key Vault Mapping (One Project Per KV Engine)">
|
||||
Each KV secret engine becomes its own Infisical project with a single `Production` environment.
|
||||
|
||||
**Example:** If you have 3 KV secret engines (`dev-secrets`, `staging-secrets`, `prod-secrets`):
|
||||
|
||||
- Creates: 3 Infisical projects (`dev-secrets`, `staging-secrets`, `prod-secrets`)
|
||||
- Each project has: 1 environment (`Production`)
|
||||
</Accordion>
|
||||
|
||||
### How to Perform a Bulk Import
|
||||
|
||||
<Steps>
|
||||
<Step title="Create a Vault policy for bulk import">
|
||||
In your Vault instance, create a policy that allows Infisical to read all secrets and metadata. This policy grants read-only access.
|
||||
|
||||
<Accordion title="View the bulk import policy">
|
||||
```hcl
|
||||
# Allow listing secret engines/mounts
|
||||
path "sys/mounts" {
|
||||
capabilities = ["read", "list"]
|
||||
@@ -63,65 +262,54 @@ There are two options for project mapping:
|
||||
capabilities = ["read", "list"]
|
||||
}
|
||||
```
|
||||
</Accordion>
|
||||
|
||||
Save this policy with the name `infisical-migration`.
|
||||
Save this policy in Vault with the name `infisical-bulk-migration`.
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Generate an access token">
|
||||
You can use the Vault CLI to easily generate an access token for the new `infisical-migration` policy that you created in the previous step.
|
||||
Use the Vault CLI to generate an access token:
|
||||
|
||||
```bash
|
||||
vault token create --policy="infisical-migration"
|
||||
vault token create --policy="infisical-bulk-migration"
|
||||
```
|
||||
|
||||
After generating the token, you should see the following output:
|
||||
Copy the `token` value from the output - you'll need it in the next step.
|
||||
|
||||
```t
|
||||
$ vault token create --policy="infisical-migration"
|
||||
|
||||
Key Value
|
||||
--- -----
|
||||
token <your-access-token>
|
||||
token_accessor p6kJDiBSzYYdabJUIpGCsCBm
|
||||
token_duration 768h
|
||||
token_renewable true
|
||||
token_policies ["default" "infisical-migration"]
|
||||
identity_policies []
|
||||
policies ["default" "infisical-migration"]
|
||||
```
|
||||
|
||||
Copy the `token` field and save it for later, as you'll need this when configuring the migration to Infisical.
|
||||
</Step>
|
||||
|
||||
<Step title="Navigate to Infisical external migrations">
|
||||
Open the Infisical dashboard and go to Organization Settings > External Migrations.
|
||||
<Step title="Start the import in Infisical">
|
||||
In Infisical, navigate to **Organization Settings > External Migrations**.
|
||||
|
||||
|
||||
|
||||
Under the "Bulk Data Import" section, click **"+ Import"**.
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Select the Vault platform">
|
||||
Select the Vault platform and click on Next.
|
||||
<Step title="Select Vault as the source">
|
||||
Select **HashiCorp Vault** as the migration source and click **Next**.
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Configure the Vault migration">
|
||||
Enter the Vault access token that you generated in the previous step and click Import data.
|
||||
<Step title="Configure and start the migration">
|
||||
Fill in your Vault connection details:
|
||||
|
||||
|
||||
|
||||
- `Vault URL`: The URL of your Vault instance.
|
||||
- `Vault Namespace`: The namespace of your Vault instance. This is optional, and can be left blank if you're not using namespaces for your Vault instance.
|
||||
- `Vault Access Token`: The access token that you generated in the previous step.
|
||||
- **Vault URL**: Your Vault instance URL (e.g., `https://vault.example.com`)
|
||||
- **Vault Namespace**: Optional - only needed if using Vault Enterprise namespaces
|
||||
- **Vault Access Token**: The token you generated in step 2
|
||||
- **Project Mapping**: Choose how to structure your Infisical projects (see [Understanding Project Mapping](#understanding-project-mapping))
|
||||
|
||||
- `Project Mapping`: Choose how you want to map your Vault resources to Infisical projects. You can review the mapping options in the [Project Mapping](#project-mapping) section.
|
||||
Click **"Import Data"** to start the migration.
|
||||
|
||||
Click on Import data to start the migration.
|
||||
<Note>
|
||||
The import runs in the background and may take several minutes. You'll receive an email when it completes.
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
<Note>
|
||||
It may take several minutes to complete the migration. You will receive an email when the migration is complete, or if there were any errors during the migration process.
|
||||
</Note>
|
||||
Reference in New Issue
Block a user