mirror of
https://github.com/awatertrevi/infisical.git
synced 2026-09-22 13:39:35 +00:00
Finish update for platform docs
This commit is contained in:
Tuan Dang
@@ -42,7 +42,7 @@ In the above image, you can already see that:
|
||||
### Dashboard
|
||||
|
||||
The secrets dashboard lets you manage secrets for a specific environment in a project.
|
||||
Here, developers can [override secrets](//project#personal-overrides), [version secrets](/documentation/platform/secret-versioning), [rollback projects to any point in time](/documentation/platform/pit-recovery), and much more.
|
||||
Here, developers can override secrets, version secrets, rollback projects to any point in time and much more.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ With this feature, teams can track 25+ different events;
|
||||
filter audit logs by event, actor, source, date or any combination of these filters;
|
||||
and inspect extensive metadata in the event of any suspicious activity or incident review.
|
||||
|
||||
|
||||
|
||||
|
||||
Each log contains the following data:
|
||||
|
||||
|
||||
@@ -3,28 +3,50 @@ title: "Folders"
|
||||
description: "Organize your secrets with folders"
|
||||
---
|
||||
|
||||
Folders provide a powerful and intuitive way to structure your secrets.
|
||||
They offer a system to keep your secrets organized and easily accessible, which becomes increasingly important as your collection of secrets grows.
|
||||
Infisical's folder feature lets you store secrets at a specific folder; we also call this **path-based secret storage**.
|
||||
This is great for organizing secrets around hierarchies when multiple services, types of secrets, etc. are involved at great quantities.
|
||||
With folders that can go infinitely deep, you can mirror your application architecture (be it microservices or monorepos)
|
||||
or any logical grouping that best suits your needs.
|
||||
|
||||
With folders in Infisical, you can now create a hierarchy of folders to organize your secrets, mirroring your application's architecture or any logical grouping that suits your needs.
|
||||
Whether you follow a microservices architecture or work with monorepos, folders make it simpler to locate, manage and collaborate between teams.
|
||||
Consider the following structure for a microservice architecture:
|
||||
|
||||
```
|
||||
| service1
|
||||
|---- envars
|
||||
|---- users
|
||||
|-------- tokens1
|
||||
|-------- tokens2
|
||||
| service2
|
||||
|---- envars
|
||||
...
|
||||
```
|
||||
|
||||
## Creating a folder
|
||||
In this example, we store environment variables for each microservice under each respective `/envars` folder.
|
||||
We also store user-specific secrets for micro-service 1 under `/service1/users`. With this folder structure in place, your applications only need to specify a path like `/microservice1/envars` to fetch secrets from there.
|
||||
By extending this example, you can see how path-based secret storage provides a versatile approach to manage secrets for any architecture.
|
||||
|
||||
To create a folder, head over to the environment where you'd like to create the folder. Once there, click the `Add folder` button as shown below.
|
||||
If you wish to create nested folders, simply click into the folder of choice and click `Add folder` button again.
|
||||
## Folders
|
||||
|
||||
|
||||
### Managing folders
|
||||
|
||||
To add a folder, press the downward chevron to the right of the **Add Secret** button; then press on the **Add Folder** button.
|
||||
|
||||
<Info>
|
||||
Folder names can only contain alphabets, numbers, and dashes
|
||||
</Info>
|
||||
|
||||
## Compare folders across environments
|
||||
|
||||
|
||||
The overview screen provides a comprehensive view of all your secrets and folders, organized by environment.
|
||||
To delete a folder, hover over it and press the **X** button that appears on the right side.
|
||||
|
||||
|
||||
|
||||
|
||||
When you click on a folder, the overview will be updated to show only the secrets and folders in that folder. This allows you to compare secrets across environment regardless of how deeply nested your folders are.
|
||||
### Comparing folders
|
||||
|
||||
It's possible to compare the contents of folders across environments in the **Secrets Overview** page.
|
||||
When you click on a folder, the table will display the items within it across environments.
|
||||
|
||||
In the image below, you can see that the **Development** environment is the only one that contains items
|
||||
in the `/users` folder, being other folders `/user-a`, `/user-b`, ... `/user-f`.
|
||||
|
||||
|
||||
@@ -27,7 +27,7 @@ For enhanced security, we strongly recommend replacing the default entry with yo
|
||||
You must be a project `admin` to manage your project's IP whitelist.
|
||||
</Note>
|
||||
|
||||
|
||||
|
||||
|
||||
## Creating a trusted IP entry
|
||||
|
||||
@@ -35,4 +35,4 @@ To create a trusted IP entry, head over to the **IP Whitelist** tab in your proj
|
||||
you can specify either a specific IP address like `192.0.2.1` or a CIDR range like `2001:db8::/32`; both IPv4 and IPv6
|
||||
formats are accepted.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -3,26 +3,37 @@ title: "Point-in-Time Recovery"
|
||||
description: "How to rollback secrets and configs to any commit with Infisical."
|
||||
---
|
||||
|
||||
Point-in-time recovery allows secrets to be rolled back to any point in time.
|
||||
It's powered by snapshots that get created after every mutations to a secret within a given [folder](./folder) and environment.
|
||||
<Info>
|
||||
Point-in-Time Recovery is a paid feature.
|
||||
|
||||
If you're using Infisical Cloud, then it is available under the **Team Tier**. If you're self-hosting Infisical,
|
||||
then you should contact team@infisical.com to purchase an enterprise license to use it.
|
||||
</Info>
|
||||
|
||||
## Commits
|
||||
Infisical's point-in-time recovery feature allows secrets to be rolled back to any point in time for any given [folder](./folder).
|
||||
Under the hood, snapshots, capturing the state of the folder, get taken after any mutation an item within that folder.
|
||||
|
||||
Similar to Git, a commit in Infisical is a snapshot of your project's secrets at a specific point in time scoped to the environment and [folder](./folder) it is in. You can browse and view your project's snapshots via the "Point-in-Time Recovery" sidebar.
|
||||
## Snapshots
|
||||
|
||||
|
||||
|
||||
Similar to Git, a commit (aka snapshot) in Infisical is the state of your project's secrets at a specific point in time scoped to
|
||||
an environment and [folder](./folder) within it.
|
||||
|
||||
To view a list of snapshots for the current folder, press the **Commits** button.
|
||||
|
||||
|
||||
|
||||
This opens up a sidebar from which you can select to view a particular snapshot:
|
||||
|
||||
|
||||
|
||||
## Rolling back
|
||||
|
||||
Secrets can be rolled back to any point in time via the "Rollback to this snapshot" button. This will roll back the changes within the given [folder](./folder) and environment to the chosen time.
|
||||
After pressing on a snapshot from the sidebar, you can view it and even roll back the state
|
||||
of the folder to that point in time by pressing the **Rollback** button.
|
||||
|
||||
It's important to note that this rollback action is localized and does not affect other folders within the same environment. This means each [folder](./folder) maintains its own independent history of changes, offering precise and isolated control over rollback actions.
|
||||
In essence, every [folder](./folder) possesses a distinct and separate timeline, providing granular control when managing your secrets.
|
||||
|
||||
|
||||
|
||||
Rolling back secrets to a past snapshot creates a creates a snapshot at the top of the stack and updates secret versions.
|
||||
|
||||
<Note>
|
||||
Rolling back secrets to a past snapshot creates a new commit,
|
||||
creates a snapshot at the top of the stack and updates secret versions.
|
||||
</Note>
|
||||
Note that rollbacks are localized to not affect other folders within the same environment. This means each [folder](./folder) maintains its own independent history of changes, offering precise and isolated control over rollback actions.
|
||||
Put differently, every [folder](./folder) possesses a distinct and separate timeline, providing granular control when managing your secrets.
|
||||
|
||||
@@ -14,50 +14,90 @@ This is useful for comparing secrets, identifying if anything is missing, and ma
|
||||
|
||||
## Secrets Dashboard
|
||||
|
||||
The **Secrets Dashboard** page appears when you press to manage the secrets of a particular environment.
|
||||
The **Secrets Dashboard** page appears when you press to manage the secrets of a specific environment.
|
||||
|
||||
|
||||
|
||||
### Secrets
|
||||
|
||||
Secrets can be added to or removed from a project. By default, they are pre-populated in your first project for demonstration.
|
||||
For any subsequent project, if applicable, it can be convenient to add items by dragging and dropping a .env file containing them.
|
||||
To add a secret, press **Add Secret** button at the top of the dashboard.
|
||||
|
||||
Here's what dragging and dropping a .env looks like:
|
||||
|
||||
|
||||
|
||||
For a new project, it can be convenient to populate the dashboard by dropping a `.env` file into the provided pane as shown below:
|
||||
|
||||
### Environments
|
||||
|
||||
|
||||
In most cases, environment variables belong to specific environments: development, staging, testing, and production. You can input environment variables for each environment that your project uses.
|
||||
To delete a secret, hover over it and press the **X** button that appears on the right side.
|
||||
|
||||
|
||||
|
||||
|
||||
### Personal overrides
|
||||
To delete multiple secrets at once, hover over and select the secrets you'd like to delete
|
||||
and press the **Delete** button that appears at the top.
|
||||
|
||||
Every environment variable value can be overridden with a custom value.
|
||||
|
||||
- An overridden value can only be read and accessed by the user that overrode the original shared value.
|
||||
- A (default) shared value can be read and accessed by other users in a project.
|
||||
|
||||
You can turn overrides on/off by toggling the override/branch icon:
|
||||
|
||||
|
||||
|
||||
|
||||
### Search
|
||||
|
||||
You can search for any environment variable by its key.
|
||||
To search for specific secrets by their key name, you can use the search bar.
|
||||
|
||||
|
||||
|
||||
|
||||
To assist you with finding secrets, you can also group them by similar prefixes and filter them by tags (if applicable).
|
||||
|
||||
|
||||
|
||||
### Hide/Un-hide
|
||||
|
||||
You can hide or un-hide the values of your environment variables. By default, the values are hidden for your privacy.
|
||||
To view/hide all secrets at once, toggle the hide or un-hide button.
|
||||
|
||||
|
||||
|
||||
|
||||
### Download as .env
|
||||
|
||||
You can download your environment variables back in a .env file.
|
||||
To download/export secrets back into a `.env` file, press the download button.
|
||||
|
||||
|
||||
|
||||
### Tags
|
||||
|
||||
To better organize similar secrets, hover over them and label them with a tag.
|
||||
|
||||
|
||||
|
||||
### Comments
|
||||
|
||||
To provide more context about a given secret, especially for your team, hover over it and press the comment button.
|
||||
|
||||
|
||||
|
||||
### Personal overrides
|
||||
|
||||
Infisical employs the concept of **shared** and **personal** secrets to address the need
|
||||
for common and custom secret values, or branching, amongst members of a team during software development.
|
||||
To provide a helpful analogy: A shared value is to a `main` branch as a personal value is to a custom branch.
|
||||
|
||||
Consider:
|
||||
|
||||
- A team with users A, B, user C.
|
||||
- A project with an environment containing a shared secret called D with the value E.
|
||||
|
||||
Suppose user A overrides the value of secret D with the value F.
|
||||
|
||||
Then:
|
||||
|
||||
- If user A fetches the secret D back, they get the value F.
|
||||
- If users B and C fetch the secret D back, they both get the value E.
|
||||
|
||||
|
||||
|
||||
### Drawer
|
||||
|
||||
To view the full details of each secret, you can hover over it and press on the ellipses button.
|
||||
|
||||
|
||||
|
||||
This opens up a side-drawer:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,23 +1,39 @@
|
||||
---
|
||||
title: "Reference and Import Secrets"
|
||||
title: "Secret Referencing / Importing"
|
||||
description: "How to use reference secrets in Infisical"
|
||||
---
|
||||
|
||||
Secret referencing is a powerful feature that allows you to values of other secrets. This way, you just need to update the secret value once for it to be propagated to all the references.
|
||||
## Secret Referencing
|
||||
|
||||
Consider a scenario where you have a database password. In order to utilize this password, you may need to incorporate it into a database connection string.
|
||||
With secret referencing, you can easily construct these more intricate secrets by directly referencing the base secret.
|
||||
This centralizes the management of your base secret, as any updates made to it will automatically propagate to all the secrets that depend on it.
|
||||
Infisical's secret referencing feature lets you reference the value of a "base" secret when defining the value of another secret.
|
||||
This means that updating the value of a base secret propagates directly to other secrets whose values depend on the base secret.
|
||||
|
||||
## Referencing syntax
|
||||
<img src="../../images/example-secret-referencing.png" />
|
||||
<Note>
|
||||
Currently, the secret referencing feature is only supported by the
|
||||
[Infisical CLI](/cli/overview) and [native integrations](/integrations/overview).
|
||||
|
||||
Secret referencing relies on interpolation syntax. This syntax allows you to reference a secret in any environment or [folder](./folder).
|
||||
We intend to add support for it to the [Node SDK](https://github.com/Infisical/infisical-node)
|
||||
and [Python SDK](https://github.com/Infisical/infisical-python) this quarter.
|
||||
</Note>
|
||||
|
||||
To reference a secret named 'mysecret' in the same [folder](./folder) and environment, you'd use `${mysecret}`.
|
||||
However, to reference the same secret at the root of a different environment, for instance `dev` environment, you'd use `${dev.mysecret}`.
|
||||
|
||||
|
||||
Here are a few more examples to help you understand how to reference secrets in different contexts:
|
||||
Since secret referencing works by reconstructing values back on the client side, the client, be it a user or service token, fetching back secrets
|
||||
must be permissioned access to all base and dependent secrets.
|
||||
|
||||
For example, to access some secret `A` whose values depend on secrets `B` and `C` from different scopes, a client must have `read` access to the scopes of secrets `A`, `B`, and `C`.
|
||||
|
||||
### Syntax
|
||||
|
||||
When defining a secret reference, interpolation syntax is used to define references to secrets in other environments and [folders](./folder).
|
||||
|
||||
Suppose you have some secret `MY_SECRET` at the root of some environment and want to reference part of its value from another base secret `BASE_SECRET` located elsewhere.
|
||||
Then consider the following scenarios:
|
||||
|
||||
- If `BASE_SECRET` is in the same environment and folder as `MY_SECRET`, then you'd reference it using `${BASE_SECRET}`.
|
||||
- If `BASE_SECRET` is at the root of another environment with the slug `dev`, then you'd reference it using `${dev.MY_SECRET}`.
|
||||
|
||||
Here are a few more helpful examples for how to reference secrets in different contexts:
|
||||
|
||||
| Reference syntax | Environment | Folder | Secret Key |
|
||||
| --------------------- | ----------- | ------------ | ---------- |
|
||||
@@ -25,29 +41,29 @@ Here are a few more examples to help you understand how to reference secrets in
|
||||
| `${dev.KEY2}` | `dev` | `/` (root of dev environment) | KEY2 |
|
||||
| `${prod.frontend.KEY2}` | `prod` | `/frontend` | KEY2 |
|
||||
|
||||
## Fetching fully constructed values
|
||||
## Secret Imports
|
||||
|
||||
Secret referencing combines multiple secrets into one unified value, reconstructed only on the client side. To retrieve this value, you need access to read the environment and [folder](./folder) from where the secrets originate.
|
||||
For instance, to access a secret 'A' composed of secrets 'B' and 'C' from different environments, you must have read access to both 'A' and 'B'
|
||||
Infisical's secret imports feature lets you import the items of another environment or folder into the current folder context.
|
||||
This can be useful if you have common secrets that need to be available across multiple environments/folders.
|
||||
|
||||
When using [service tokens](./token) to fetch referenced secrets, ensure the service token has read access to all referenced environments and folders.
|
||||
Without proper permissions, the final secret value may be incomplete.
|
||||
To add a secret import, press the downward chevron to the right of the **Add Secret** button; then press on the **Add Import** button.
|
||||
|
||||
## Import entire folders/environments
|
||||
|
||||
|
||||
While secret referencing effectively minimizes duplication, there might be instances where you need to import or replicate an entire folder's secrets into another. This can be achieved using the 'Import' feature.
|
||||
Once added, a secret import will show up with a green import icon on the secrets dashboard.
|
||||
In the example below, you can see that the items in the path `/some-folder` are being imported into
|
||||
the current folder context.
|
||||
|
||||
This feature allows you to link secrets from one environment/folder into another environment/folder. It proves beneficial when you have common secrets that need to be available across multiple environments/folders.
|
||||
|
||||
|
||||
To add an import, simply click on the `Add import` button and provide the environment and secret path from where the secrets should be imported.
|
||||
To delete a secret import, hover over it and press the **X** button that appears on the right side.
|
||||
|
||||
|
||||
|
||||
|
||||
The hierarchy of importing secrets is governed by a "last-one-wins" rule. This means the sequence in which you import matters - the final folder imported will override secrets from any prior folders.
|
||||
Additionally, any secrets you define directly in your environment will override any secrets that are imported with the same name.
|
||||
Lastly, note that the order of secret imports matters. If two secret imports contain secrets with the same name, then the secret value from the bottom-most secret import is taken — "the last one wins."
|
||||
|
||||
You can modify the order of folders to control overrides using the `Change Order` drag handle.
|
||||
To reorder a secret import, hover over it and drag the arrows handle to the position you want.
|
||||
|
||||
|
||||
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/o11bMU0pXRs?si=dCprt3xLWPrSOJxy" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
|
||||
|
||||
Reference in New Issue
Block a user