Fix merge conflicts
@@ -7,8 +7,7 @@ in plaintext. Effectively, this means each such secret operation only requires 1
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Retrieve secrets">
|
||||
Retrieve all secrets for an Infisical project and environment.
|
||||
|
||||
Retrieve all secrets for an Infisical project and environment.
|
||||
<Tabs>
|
||||
<Tab title="cURL">
|
||||
```bash
|
||||
@@ -18,7 +17,12 @@ in plaintext. Effectively, this means each such secret operation only requires 1
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
####
|
||||
<Info>
|
||||
When using a [service token](../../../documentation/platform/token) with access to a single environment and path, you don't need to provide request parameters because the server will automatically scope the request to the defined environment/secrets path of the service token used.
|
||||
For all other cases, request parameters are required.
|
||||
</Info>
|
||||
####
|
||||
<ParamField query="workspaceId" type="string" required>
|
||||
The ID of the workspace
|
||||
</ParamField>
|
||||
|
||||
@@ -4,6 +4,28 @@ title: "Changelog"
|
||||
|
||||
The changelog below reflects new product developments and updates on a monthly basis; it will be updated later this quarter to include issues-addressed on a weekly basis.
|
||||
|
||||
## July 2023
|
||||
|
||||
- Released [secret referencing and importing](https://infisical.com/docs/documentation/platform/secret-reference) across folders and environments.
|
||||
- Redesigned the project/organization experience.
|
||||
- Added native [Laravel Forge integration](https://infisical.com/docs/integrations/cloud/laravel-forge).
|
||||
- Added native [Codefresh integration](https://infisical.com/docs/integrations/cicd/codefresh)
|
||||
- Added native [Bitbucket integration](https://infisical.com/docs/integrations/cicd/bitbucket)
|
||||
- Added native [DigitalOcean App Platform integration](https://infisical.com/docs/integrations/cloud/digital-ocean-app-platform)
|
||||
- Added native [Cloud66 integration](https://infisical.com/docs/integrations/cloud/cloud-66)
|
||||
- Added support for Google SSO.
|
||||
- Added support for [Okta SAML 2.0 authentication](https://infisical.com/docs/documentation/platform/saml)
|
||||
- Released [folders / path-based secret storage](https://infisical.com/docs/documentation/platform/folder)
|
||||
- Released [webhooks](https://infisical.com/docs/documentation/platform/webhooks)
|
||||
|
||||
## June 2023
|
||||
|
||||
- Released the [Terraform Provider](https://infisical.com/docs/integrations/frameworks/terraform#5-run-terraform).
|
||||
- Updated the usage and billing page. Added the free trial for the professional tier.
|
||||
- Added the intergation with [Checkly](https://infisical.com/docs/integrations/cloud/checkly), [Hashicorp Vault](https://infisical.com/docs/integrations/cloud/hashicorp-vault), and [Cloudflare Pages](https://infisical.com/docs/integrations/cloud/cloudflare-pages).
|
||||
- Completed a penetration test with a `very good` result.
|
||||
- Added support for multi-line secrets.
|
||||
|
||||
## May 2023
|
||||
|
||||
- Released secret scanning capability for the CLI.
|
||||
@@ -11,8 +33,7 @@ The changelog below reflects new product developments and updates on a monthly b
|
||||
- Completed penetration test.
|
||||
- Released new landing page.
|
||||
- Started SOC 2 (Type II) compliance certification preparation.
|
||||
|
||||
More coming soon.
|
||||
- Released new deployment options for Fly.io, Digital Ocean and Render.
|
||||
|
||||
## April 2023
|
||||
|
||||
@@ -107,4 +128,4 @@ More coming soon.
|
||||
- Added search bar to dashboard to query for keys on client-side.
|
||||
- Added capability to rename a project.
|
||||
- Added user roles for projects.
|
||||
- Added incident contacts.
|
||||
- Added incident contacts.
|
||||
|
||||
@@ -99,6 +99,15 @@ Export environment variables from the platform into a file format.
|
||||
Default value: `true`
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="--path">
|
||||
The `--path` flag indicates which project folder secrets will be injected from.
|
||||
|
||||
```bash
|
||||
# Example
|
||||
infisical export --path="/path/to/folder" --env=dev
|
||||
```
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="--tags">
|
||||
When working with tags, you can use this flag to filter and retrieve only secrets that are associated with a specific tag(s).
|
||||
|
||||
|
||||
@@ -51,6 +51,14 @@ This command enables you to perform CRUD (create, read, update, delete) operatio
|
||||
|
||||
Default value: `dev`
|
||||
</Accordion>
|
||||
<Accordion title="--path">
|
||||
The `--path` flag indicates which project folder secrets will be injected from.
|
||||
|
||||
```bash
|
||||
# Example
|
||||
infisical secrets --path="/" --env=dev
|
||||
```
|
||||
</Accordion>
|
||||
|
||||
</Accordion>
|
||||
|
||||
@@ -90,6 +98,14 @@ $ infisical secrets set STRIPE_API_KEY=sjdgwkeudyjwe DOMAIN=example.com HASH=jeb
|
||||
|
||||
Default value: `dev`
|
||||
</Accordion>
|
||||
<Accordion title="--path">
|
||||
Used to select the project folder in which the secrets will be set. This is useful when creating new secrets under a particular path.
|
||||
|
||||
```bash
|
||||
# Example
|
||||
infisical secrets set DOMAIN=example.com --path="common/backend"
|
||||
```
|
||||
</Accordion>
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="infisical secrets delete">
|
||||
@@ -108,6 +124,14 @@ $ infisical secrets set STRIPE_API_KEY=sjdgwkeudyjwe DOMAIN=example.com HASH=jeb
|
||||
|
||||
Default value: `dev`
|
||||
</Accordion>
|
||||
<Accordion title="--path">
|
||||
The `--path` flag indicates which project folder secrets will be injected from.
|
||||
|
||||
```bash
|
||||
# Example
|
||||
infisical secrets delete <keyName1> <keyName2>... --path="/"
|
||||
```
|
||||
</Accordion>
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="infisical secrets generate-example-env">
|
||||
|
||||
@@ -3,9 +3,8 @@ title: 'Install'
|
||||
description: "Infisical's CLI is one of the best way to manage environments and secrets. Install it here"
|
||||
---
|
||||
|
||||
Prerequisite: Set up an account with [Infisical Cloud](https://app.infisical.com) or via a [self-hosted installation](/self-hosting/overview).
|
||||
|
||||
The Infisical CLI provides a way to inject environment variables from the platform into your apps and infrastructure.
|
||||
The Infisical CLI is powerful command line tool that can be used to retrieve, modify, export and inject secrets into any process or application as environment variables.
|
||||
You can use it across various environments, whether it's local development, CI/CD, staging, or production.
|
||||
|
||||
## Installation
|
||||
|
||||
@@ -59,7 +58,10 @@ The Infisical CLI provides a way to inject environment variables from the platfo
|
||||
```bash
|
||||
apk update && sudo apk add infisical
|
||||
```
|
||||
|
||||
###
|
||||
<Tip>
|
||||
If you are installing the CLI in production environments, we highly recommend to set the version of the CLI to a specific version. This will help keep your CLI version consistent across reinstalls. [View versions](https://cloudsmith.io/~infisical/repos/infisical-cli/packages/)
|
||||
</Tip>
|
||||
</Tab>
|
||||
<Tab title="RedHat/CentOs/Amazon">
|
||||
Add Infisical repository
|
||||
@@ -73,7 +75,10 @@ The Infisical CLI provides a way to inject environment variables from the platfo
|
||||
```bash
|
||||
sudo yum install infisical
|
||||
```
|
||||
|
||||
###
|
||||
<Tip>
|
||||
If you are installing the CLI in production environments, we highly recommend to set the version of the CLI to a specific version. This will help keep your CLI version consistent across reinstalls. [View versions](https://cloudsmith.io/~infisical/repos/infisical-cli/packages/)
|
||||
</Tip>
|
||||
</Tab>
|
||||
<Tab title="Debian/Ubuntu">
|
||||
Add Infisical repository
|
||||
@@ -88,7 +93,10 @@ The Infisical CLI provides a way to inject environment variables from the platfo
|
||||
```bash
|
||||
sudo apt-get update && sudo apt-get install -y infisical
|
||||
```
|
||||
|
||||
###
|
||||
<Tip>
|
||||
If you are installing the CLI in production environments, we highly recommend to set the version of the CLI to a specific version. This will help keep your CLI version consistent across reinstalls. [View versions](https://cloudsmith.io/~infisical/repos/infisical-cli/packages/)
|
||||
</Tip>
|
||||
</Tab>
|
||||
<Tab title="Arch Linux">
|
||||
Use the `yay` package manager to install from the [Arch User Repository](https://aur.archlinux.org/packages/infisical-bin)
|
||||
@@ -97,52 +105,9 @@ The Infisical CLI provides a way to inject environment variables from the platfo
|
||||
yay -S infisical-bin
|
||||
```
|
||||
|
||||
###
|
||||
<Tip>
|
||||
If you are installing the CLI in production environments, we highly recommend to set the version of the CLI to a specific version. This will help keep your CLI version consistent across reinstalls. [View versions](https://cloudsmith.io/~infisical/repos/infisical-cli/packages/)
|
||||
</Tip>
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
### Log in to the Infisical CLI
|
||||
|
||||
```bash
|
||||
infisical login
|
||||
```
|
||||
|
||||
<Accordion title="Optional: point CLI to self-hosted">
|
||||
The CLI is set to connect to Infisical Cloud by default, but if you're running your own instance of Infisical, you can direct the CLI to it using one of the methods provided below.
|
||||
|
||||
#### Method 1: Use the updated CLI
|
||||
Beginning with CLI version V0.4.0, it is now possible to choose between logging in through the Infisical cloud or your own self-hosted instance. Simply execute the `infisical login` command and follow the on-screen instructions.
|
||||
|
||||
#### Method 2: Export environment variable
|
||||
You can point the CLI to the self hosted Infisical instance by exporting the environment variable `INFISICAL_API_URL` in your terminal.
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Linux/MacOs">
|
||||
```bash
|
||||
# Set backend host
|
||||
export INFISICAL_API_URL="https://your-self-hosted-infisical.com/api"
|
||||
|
||||
# Remove backend host
|
||||
unset INFISICAL_API_URL
|
||||
```
|
||||
</Tab>
|
||||
<Tab title="Windows Powershell">
|
||||
```bash
|
||||
# Set backend host
|
||||
setx INFISICAL_API_URL "https://your-self-hosted-infisical.com/api"
|
||||
|
||||
# Remove backend host
|
||||
setx INFISICAL_API_URL ""
|
||||
|
||||
# NOTE: Once set or removed, please restart powershell for the change to take effect
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
#### Method 3: Set manually on every command
|
||||
Another option to point the CLI to your self hosted Infisical instance is to set it via a flag on every command you run.
|
||||
|
||||
```bash
|
||||
# Example
|
||||
infisical <any-command> --domain="https://your-self-hosted-infisical.com/api"
|
||||
```
|
||||
</Accordion>
|
||||
|
||||
@@ -1,77 +1,137 @@
|
||||
---
|
||||
title: "Usage"
|
||||
description: "How to manage you secrets with Infisical's CLI?"
|
||||
title: "Quick usage"
|
||||
description: "Manage secrets with Infisical CLI"
|
||||
---
|
||||
|
||||
Prerequisite: [Install the CLI](/cli/overview)
|
||||
The CLI is designed for a variety of applications, ranging from local secret management to CI/CD and production scenarios.
|
||||
The distinguishing factor, however, is the authentication method used.
|
||||
|
||||
## Authenticate
|
||||
<Tabs>
|
||||
<Tab title="Local development">
|
||||
To use the Infisical CLI in your development environment, you can run the command below.
|
||||
This will allow you to access the features and functionality provided by the CLI.
|
||||
To use the Infisical CLI in your development environment, simply run the command below and follow the interactive guide.
|
||||
|
||||
```bash
|
||||
infisical login
|
||||
```
|
||||
|
||||
<Note>
|
||||
If you are in a containerized environment such as WSL 2 or Codespaces, run `infisical login -i` to avoid browser based login
|
||||
</Note>
|
||||
|
||||
## Initialize Infisical for your project
|
||||
|
||||
```bash
|
||||
# navigate to your project
|
||||
cd /path/to/project
|
||||
|
||||
# initialize infisical
|
||||
infisical init
|
||||
```
|
||||
|
||||
This will create `.infisical.json` file at the location the command was executed. This file contains your [local project settings](./project-config). It does not contain any sensitive data.
|
||||
|
||||
</Tab>
|
||||
|
||||
<Tab title="Infisical Token">
|
||||
To use Infisical CLI in environments where you cannot run the `infisical login` command, you can authenticate via a
|
||||
Infisical Token instead. Learn more about [Infisical Token](/documentation/platform/token).
|
||||
<Tab title="CI/CD, Production usage, etc">
|
||||
To use Infisical for non local development scenarios, please create a [service token](../documentation/platform/token). The service token will allow you to authenticate and interact with Infisical.
|
||||
Once you have created a service token with the required permissions, you'll need to feed the token to the CLI.
|
||||
|
||||
#### Pass as flag
|
||||
You may use the --token flag to set the token
|
||||
|
||||
```
|
||||
infisical export --token=<>
|
||||
infisical secrets --token=<>
|
||||
infisical run --token=<> -- npm run dev
|
||||
```
|
||||
|
||||
#### Pass via shell environment variable
|
||||
The CLI is configured to look for an environment variable named `INFISICAL_TOKEN`. If set, it'll attempt to use it for authentication.
|
||||
|
||||
```
|
||||
export INFISICAL_TOKEN=<>
|
||||
```
|
||||
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## Initialize Infisical for your project
|
||||
|
||||
```bash
|
||||
# navigate to your project
|
||||
cd /path/to/project
|
||||
|
||||
# initialize infisical
|
||||
infisical init
|
||||
```
|
||||
|
||||
## Inject environment variables
|
||||
<Tabs>
|
||||
<Tab title="Feed secrets to your application">
|
||||
```bash
|
||||
infisical run -- [your application start command]
|
||||
|
||||
<Accordion title="Injecting environment variables directly" defaultOpen="true">
|
||||
```bash
|
||||
# inject environment variables into app
|
||||
infisical run -- [your application start command]
|
||||
```
|
||||
</Accordion>
|
||||
# example with node (nodemon)
|
||||
infisical run --env=dev --path=/apps/firefly -- nodemon index.js
|
||||
|
||||
<Accordion title="Injecting environment variables in custom aliases">
|
||||
Custom aliases can utilize secrets from Infisical. Suppose there is a custom alias `yd` in `custom.sh` that runs `yarn dev` and needs the secrets provided by Infisical.
|
||||
```bash
|
||||
#!/bin/sh
|
||||
# example with flask
|
||||
infisical run -- flask run
|
||||
|
||||
yd() {
|
||||
yarn dev
|
||||
}
|
||||
```
|
||||
# example with spring boot - maven
|
||||
infisical run -- ./mvnw spring-boot:run --quiet
|
||||
```
|
||||
</Tab>
|
||||
<Tab title="Feed secrets via custom aliases (advanced)">
|
||||
Custom aliases can utilize secrets from Infisical. Suppose there is a custom alias `yd` in `custom.sh` that runs `yarn dev` and needs the secrets provided by Infisical.
|
||||
```bash
|
||||
#!/bin/sh
|
||||
|
||||
To make the secrets available from Infisical to `yd`, you can run the following command:
|
||||
yd() {
|
||||
yarn dev
|
||||
}
|
||||
```
|
||||
|
||||
```bash
|
||||
infisical run --command="source custom.sh && yd"
|
||||
```
|
||||
</Accordion>
|
||||
To make the secrets available from Infisical to `yd`, you can run the following command:
|
||||
|
||||
```bash
|
||||
infisical run --command="source custom.sh && yd"
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
View all available options for `run` command [here](./commands/run)
|
||||
|
||||
## Examples:
|
||||
## Connect CLI to self hosted Infisical
|
||||
|
||||
```bash
|
||||
# example with node
|
||||
infisical run -- node index.js
|
||||
<Accordion title="Optional: point CLI to self-hosted">
|
||||
The CLI is set to connect to Infisical Cloud by default, but if you're running your own instance of Infisical, you can direct the CLI to it using one of the methods provided below.
|
||||
|
||||
# example with node (nodemon)
|
||||
infisical run -- nodemon index.js
|
||||
#### Method 1: Use the updated CLI
|
||||
Beginning with CLI version V0.4.0, it is now possible to choose between logging in through the Infisical cloud or your own self-hosted instance. Simply execute the `infisical login` command and follow the on-screen instructions.
|
||||
|
||||
# example with node (nodemon) pulling in secrets from test environment
|
||||
infisical run --env=test -- nodemon index.js
|
||||
#### Method 2: Export environment variable
|
||||
You can point the CLI to the self hosted Infisical instance by exporting the environment variable `INFISICAL_API_URL` in your terminal.
|
||||
|
||||
# example with flask
|
||||
infisical run -- flask run
|
||||
<Tabs>
|
||||
<Tab title="Linux/MacOs">
|
||||
```bash
|
||||
# Set backend host
|
||||
export INFISICAL_API_URL="https://your-self-hosted-infisical.com/api"
|
||||
|
||||
# Remove backend host
|
||||
unset INFISICAL_API_URL
|
||||
```
|
||||
</Tab>
|
||||
<Tab title="Windows Powershell">
|
||||
```bash
|
||||
# Set backend host
|
||||
setx INFISICAL_API_URL "https://your-self-hosted-infisical.com/api"
|
||||
|
||||
# Remove backend host
|
||||
setx INFISICAL_API_URL ""
|
||||
|
||||
# NOTE: Once set or removed, please restart powershell for the change to take effect
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
#### Method 3: Set manually on every command
|
||||
Another option to point the CLI to your self hosted Infisical instance is to set it via a flag on every command you run.
|
||||
|
||||
```bash
|
||||
# Example
|
||||
infisical <any-command> --domain="https://your-self-hosted-infisical.com/api"
|
||||
```
|
||||
</Accordion>
|
||||
|
||||
@@ -82,4 +82,28 @@ Password: `testInfisical1`
|
||||
```bash
|
||||
# To stop environment use Control+C (on Mac) CTRL+C (on Win) or
|
||||
docker-compose -f docker-compose.dev.yml down
|
||||
```
|
||||
|
||||
## Starting Infisical docs locally
|
||||
|
||||
We use [Mintlify](https://mintlify.com/) for our docs.
|
||||
|
||||
#### Install Mintlify CLI.
|
||||
|
||||
```bash
|
||||
npm i -g mintlify
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```bash
|
||||
yarn global add mintlify
|
||||
```
|
||||
|
||||
#### Running the docs
|
||||
Go to `docs` directory and run `mintlify dev`. This will start up the docs on `localhost:3000`
|
||||
|
||||
```bash
|
||||
# From the root directory
|
||||
cd docs; mintlify dev;
|
||||
```
|
||||
@@ -30,7 +30,7 @@ If you're ever in doubt about whether or not a proposed feature aligns with Infi
|
||||
## Writing and submitting code
|
||||
|
||||
Anyone can contribute code to Infisical. To get started, check out the [local development guide](/contributing/developing), make your changes, and submit a pull request to the main repository
|
||||
adhering to the [pull request guide](/).
|
||||
adhering to the [pull request guide](/contributing/pull-requests).
|
||||
|
||||
|
||||
## Licensing
|
||||
|
||||
@@ -17,10 +17,10 @@ Start syncing environment variables with [Infisical Cloud](https://app.infisical
|
||||
Store secrets like API keys, database credentials, environment variables with Infisical
|
||||
</Card>
|
||||
|
||||
## Integrate with Infisical
|
||||
## Access secrets
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card href="/documentation/getting-started/cli" title="Command Line Interface (CLI)" icon="square-terminal" color="#3775a9">
|
||||
<Card href="../../cli/overview" title="Command Line Interface (CLI)" icon="square-terminal" color="#3775a9">
|
||||
Inject secrets into any application process/environment
|
||||
</Card>
|
||||
<Card
|
||||
@@ -31,11 +31,11 @@ Start syncing environment variables with [Infisical Cloud](https://app.infisical
|
||||
>
|
||||
Fetch secrets with any programming language on demand
|
||||
</Card>
|
||||
<Card href="/documentation/getting-started/docker" title="Docker" icon="docker" color="#0078d3">
|
||||
<Card href="../../integrations/platforms/docker-intro" title="Docker" icon="docker" color="#0078d3">
|
||||
Inject secrets into Docker containers
|
||||
</Card>
|
||||
<Card
|
||||
href="/documentation/getting-started/kubernetes"
|
||||
href="../../integrations/platforms/kubernetes"
|
||||
title="Kubernetes"
|
||||
icon="server"
|
||||
color="#3775a9"
|
||||
|
||||
@@ -61,14 +61,18 @@ metadata:
|
||||
spec:
|
||||
# The host that should be used to pull secrets from. If left empty, the value specified in Global configuration will be used
|
||||
hostAPI: https://app.infisical.com/api
|
||||
resyncInterval:
|
||||
authentication:
|
||||
serviceToken:
|
||||
serviceTokenSecretReference: # <-- The secret's namespaced name that holds the project token for authentication in step 1
|
||||
serviceToken:
|
||||
serviceTokenSecretReference:
|
||||
secretName: service-token
|
||||
secretNamespace: option
|
||||
managedSecretReference:
|
||||
secretsScope:
|
||||
envSlug: dev
|
||||
secretsPath: "/"
|
||||
managedSecretReference:
|
||||
secretName: managed-secret # <-- the name of kubernetes secret that will be created
|
||||
secretNamespace: default # <-- in what namespace it will be created in
|
||||
secretNamespace: default # <-- where the kubernetes secret should be created
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
@@ -1,46 +1,30 @@
|
||||
---
|
||||
title: "Folder"
|
||||
description: "How Infisical structures secrets into folders"
|
||||
title: "Folders"
|
||||
description: "Organize your secrets with folders"
|
||||
---
|
||||
|
||||
Folders can be used to group secrets into multiple levels, which can help organize secrets in monorepos or microservice-based architectures. For example, you could create a folder for each environment, such as production, staging, and development.
|
||||
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 grow.
|
||||
|
||||
Within each environment folder, you could create subfolders for different types of secrets, such as database credentials, API keys, and SSH keys. This can help to keep your secrets organized and easy to find.
|
||||
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.
|
||||
|
||||
## Dashboard
|
||||
|
||||

|
||||
## Creating a folder
|
||||
|
||||
Only alphabets, numbers, and dashes are allowed in folder names. You can create a folder for each environment from the dashboard.
|
||||
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.
|
||||
|
||||

|
||||
|
||||
To create a nested folder or access the secrets of a folder, click on an existing folder to open it. You will then be able to modify the secrets of that folder and create new folders inside it.
|
||||
<Info>
|
||||
Folder names can only contain alphabets, numbers, and dashes
|
||||
</Info>
|
||||
|
||||
## Dashboard Secret Overview
|
||||
## Compare folders across environments
|
||||
|
||||
The overview screen provides a comprehensive view of all your secrets and folders, organized by environment.
|
||||
|
||||

|
||||
|
||||
When you click on a folder, the overview will be updated to show only the secrets and folders in that folder. This makes it easy to find the information you need, no matter how deeply nested it is.
|
||||
|
||||
## Integrations
|
||||
|
||||
You can easily scope injected secrets to a folder during integrations by providing the secret path option.
|
||||
|
||||

|
||||
|
||||
For more information on integrations, [refer infisical integration](/integrations/overview)
|
||||
|
||||
## Service Tokens
|
||||
|
||||
You can scope the secrets that can be read and written using an Infisical token by providing the secret path option when creating the token.
|
||||
|
||||

|
||||
|
||||
For more information, [refer infisical token section.](./token)
|
||||
|
||||
## Point-In-Time Recovery
|
||||
|
||||
For more information on how PIT recovery works on folders, [please refer to this section.](./pit-recovery)
|
||||
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.
|
||||
|
||||
24
docs/documentation/platform/ip-allowlisting.mdx
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "IP Allowlisting"
|
||||
description: "Restrict access to your secrets in Infisical using trusted IPs"
|
||||
---
|
||||
|
||||
Projects in Infisical can be configured to restrict client access to specific IP addresses or CIDR ranges. This applies to any client using service tokens and
|
||||
can be useful, for example, for limiting access to traffic coming from corporate networks.
|
||||
|
||||
By default, each project is initialized with the `0.0.0.0/0` entry, representing all possible IPv4 addresses.
|
||||
For enhanced security, we strongly recommend replacing the default entry with your client IPs to tighten access to your secrets.
|
||||
|
||||
<Note>
|
||||
You must be a project `admin` to manage your project's IP whitelist.
|
||||
</Note>
|
||||
|
||||

|
||||
|
||||
## Creating a trusted IP entry
|
||||
|
||||
To create a trusted IP entry, head over to the **IP Whitelist** tab in your project. When creating an entry,
|
||||
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,28 +3,26 @@ title: "Point-in-Time Recovery"
|
||||
description: "How to rollback secrets and configs to any commit with Infisical."
|
||||
---
|
||||
|
||||
Point-in-time recovery allows environment variables to be rolled back to any point in time. It's powered by snapshots that get captured after mutations to environment variables.
|
||||
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.
|
||||
|
||||
## Commits
|
||||
|
||||
Similar to Git, a commit in Infisical is a snapshot of your project's secrets at a specific point in time. You can browse and view your project's snapshots via the "Point-in-Time Recovery" sidebar.
|
||||
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.
|
||||
|
||||

|
||||

|
||||
|
||||
## Rolling back
|
||||
|
||||
Environment variables can be rolled back to any point in time via the "Rollback to this snapshot" button.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||

|
||||
|
||||
<Note>
|
||||
Rolling back environment variables to a past snapshot creates a new commit and
|
||||
snapshot at the top of the stack and updates secret versions.
|
||||
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>
|
||||
|
||||
## Folders
|
||||
|
||||
Any folder operation, such as creating, updating, or deleting a folder, will create a new commit.
|
||||
|
||||
When you roll back the contents of a folder, the folder will be restored to its latest snapshot. The nested folders will also be restored to their respective latest versions.
|
||||
|
||||
100
docs/documentation/platform/saml.mdx
Normal file
@@ -0,0 +1,100 @@
|
||||
---
|
||||
title: "SSO"
|
||||
description: "Log in to Infisical via SSO protocols"
|
||||
---
|
||||
|
||||
<Warning>
|
||||
Infisical currently only supports SAML SSO authentication with [Okta as the
|
||||
identity provider (IDP)](https://www.okta.com/). We're expanding support for
|
||||
other IDPs in the coming months, so stay tuned with this issue
|
||||
[here](https://github.com/Infisical/infisical/issues/442).
|
||||
</Warning>
|
||||
|
||||
You can configure your organization in Infisical to have members authenticate with the platform via protocols like [SAML 2.0](https://en.wikipedia.org/wiki/SAML_2.0).
|
||||
|
||||
To note, configuring SSO retains the end-to-end encrypted architecture of Infisical because we decouple the **authentication** and **decryption** steps. In all login with SSO implementations,
|
||||
your IDP cannot and will not have access to the decryption key needed to decrypt your secrets.
|
||||
|
||||
## Configuration
|
||||
|
||||
Head over to your organization Settings > Authentication > SAML SSO Configuration.
|
||||
|
||||
Next, press "Set up SAML SSO" in the SAML SSO and follow the instructions
|
||||
below to configure SSO for your identity provider:
|
||||
|
||||
<Note>
|
||||
Note that only members with the `owner` or `admin` roles in an organization
|
||||
can configure SSO for it.
|
||||
</Note>
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Okta SAML 2.0">
|
||||
1. In the Okta Admin Portal, select Applications > Applications from the
|
||||
navigation. On the Applications screen, select the Create App Integration
|
||||
button.
|
||||
|
||||

|
||||
|
||||
2. In the Create a New Application Integration dialog, select the SAML 2.0 radio button:
|
||||
|
||||

|
||||
|
||||
3. On the General Settings screen, give the application a unique, Infisical-specific name and select Next.
|
||||
|
||||
4. On the Configure SAML screen, configure the following fields:
|
||||
|
||||
- Single sign on URL: `https://app.infisical.com/api/v1/sso/saml2/:identifier`; we'll update the `:identifier` part later in step 6.
|
||||
- Audience URI (SP Entity ID): `https://app.infisical.com`
|
||||
|
||||

|
||||
|
||||
<Note>
|
||||
If you're self-hosting Infisical, then you will want to replace `https://app.infisical.com` with your own domain.
|
||||
</Note>
|
||||
|
||||
4. Also on the Configure SAML screen, configure the Attribute Statements to map:
|
||||
|
||||
- `id -> user.id`,
|
||||
- `email -> user.email`,
|
||||
- `firstName -> user.firstName`
|
||||
- `lastName -> user.lastName`
|
||||
|
||||

|
||||
|
||||
Once configured, select the Next button to proceed to the Feedback screen and select Finish.
|
||||
|
||||
5. Get IDP values
|
||||
|
||||
Once your application is created, select the Sign On tab for the app and select the View Setup Instructions button located on the right side of the screen:
|
||||
|
||||
Copy the Identity Provider Single Sign-On URL, the Identity Provider Issuer, and the X.509 Certificate to be pasted into your Infisical SAML SSO configuration details with the following map:
|
||||
|
||||
- `Audience -> Okta Audience URI (SP Entity ID)`
|
||||
- `Entrypoint -> Okta Identity Provider Single Sign-On URL`
|
||||
- `Issuer -> Identity Provider Issuer`
|
||||
- `Certificate -> X.509 Certificate`.
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
6. Create the SSO configuration and copy your SSO identifier in Infisical; update `:identifier` from step 4 earlier to be this value.
|
||||
|
||||

|
||||
|
||||
7. Assignments
|
||||
|
||||
Finally, Navigate to the Assignments tab and select the Assign button:
|
||||
|
||||
You can assign access to the application on a user-by-user basis using the Assign to People option, or in-bulk using the Assign to Groups option.
|
||||
|
||||

|
||||
|
||||
At this point, you have configured everything you need within the context of the Okta Admin Portal.
|
||||
|
||||
8. Return to Infisical and enable SAML SSO.
|
||||
|
||||
Enabling SAML SSO enforces all members in your organization to only be able to log into Infisical via Okta.
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
52
docs/documentation/platform/secret-reference.mdx
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "Reference/Import Secrets"
|
||||
description: "How to use reference secrets in Infisical"
|
||||
---
|
||||
|
||||
Secret referencing is a powerful feature that allows you to create a secret whose value is linked to one or more other secrets.
|
||||
This is useful when you need to use a single secret's value across multiple other secrets.
|
||||
|
||||
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.
|
||||
|
||||
## Referencing syntax
|
||||
<img src="../../images/example-secret-referencing.png" />
|
||||
|
||||
Secret referencing relies on interpolation syntax. This syntax allows you to reference a secret in any environment or [folder](./folder).
|
||||
|
||||
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:
|
||||
|
||||
| Reference syntax | Environment | Folder | Secret Key |
|
||||
| --------------------- | ----------- | ------------ | ---------- |
|
||||
| `${KEY1}` | same env | same folder | KEY1 |
|
||||
| `${dev.KEY2}` | `dev` | `/` (root of dev environment) | KEY2 |
|
||||
| `${prod.frontend.KEY2}` | `prod` | `/frontend` | KEY2 |
|
||||
|
||||
## Fetching fully constructed values
|
||||
|
||||
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'
|
||||
|
||||
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.
|
||||
|
||||
## Import entire folders
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||

|
||||
|
||||
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.
|
||||
|
||||
You can modify the order of folders to control overrides using the `Change Order` drag handle.
|
||||
|
||||

|
||||
@@ -1,21 +1,37 @@
|
||||
---
|
||||
title: "Infisical Token"
|
||||
description: "Use the Infisical Token as one of the authentication methods."
|
||||
title: "Service token"
|
||||
description: "Infisical service tokens allows you to programmatically interact with Infisical"
|
||||
---
|
||||
|
||||
An Infisical Token is useful for:
|
||||
Service tokens play an integral role in allowing programmatic interactions with an Infisical project, functioning as digital token that open access to specific project resources such as secrets.
|
||||
|
||||
- Authenticating the [Infisical CLI](/cli/overview) when there isn't an easy way to input your login credentials.
|
||||
- Granting the [Infisical SDKs](/sdks/overview) access to secrets scoped to a project and environment.
|
||||
When you generate a service token, you can define its access level, not only by specifying the paths and environments it can interact with, but also by determining the level of mutation it can perform, such as read-only, write, or both.
|
||||
|
||||
It's also useful for CI/CD environments and integrations such as [Docker](/integrations/platforms/docker) and [Docker Compose](/integrations/platforms/docker-compose).
|
||||
This level of control not only ensures maximum flexibility but also significantly enhances security as it allows you to define fine grained access to project resources.
|
||||
|
||||
To generate the the token, head over to your project settings as shown below. On creating a service token you can scope it to a path to limit the access.
|
||||
|
||||
## Creating a service token
|
||||
|
||||
To generate the token, head over to your project settings as shown below. On creating a service token you can scope it to a path to limit the access.
|
||||
|
||||

|
||||
|
||||
## Feeding Infisical Token to the CLI
|
||||
### Service token permissions
|
||||

|
||||
|
||||
The Infisical CLI checks for the presence of an environment variable called `INFISICAL_TOKEN`.
|
||||
If it detects this variable in the terminal where it is being run, it will use it to authenticate and retrieve the environment variables that the token is authorized to access.
|
||||
This allows you to use the CLI in environments where you are unable to run the `infisical login` command.
|
||||
|
||||
Service tokens can be scoped to multiple environments and paths. To add a new permission, choose the environment you want to give access to and then choose the path you'd like to give access to within that environment.
|
||||
|
||||
Permissions for paths are powered by [Glob pattern](https://www.malikbrowne.com/blog/a-beginners-guide-glob-patterns/). This means you can create advanced folder permissions with a simple Glob patterns.
|
||||
|
||||
**Examples of common Glob pattens**
|
||||
|
||||
<Accordion title="Examples of common Glob pattens">
|
||||
1. `/**`: This pattern matches all folders at any depth in the directory structure. For example, it would match folders like `/folder1/`, `/folder1/subfolder/`, and so on.
|
||||
|
||||
2. `/*`: This pattern matches all immediate subfolders in the current directory. It does not match any folders at a deeper level. For example, it would match folders like `/folder1/`, `/folder2/`, but not `/folder1/subfolder/`.
|
||||
|
||||
3. `/*/*`: This pattern matches all subfolders at a depth of two levels in the current directory. It does not match any folders at a shallower or deeper level. For example, it would match folders like `/folder1/subfolder/`, `/folder2/subfolder/`, but not `/folder1/` or `/folder1/subfolder/subsubfolder/`.
|
||||
|
||||
4. `/folder1/*`: This pattern matches all immediate subfolders within the `/folder1/` directory. It does not match any folders outside of `/folder1/`, nor does it match any subfolders within those immediate subfolders. For example, it would match folders like `/folder1/subfolder1/`, `/folder1/subfolder2/`, but not `/folder2/subfolder/`.
|
||||
</Accordion>
|
||||
|
||||
36
docs/documentation/platform/webhooks.mdx
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: "Webhooks"
|
||||
description: "How Infisical webhooks works?"
|
||||
---
|
||||
|
||||
Webhooks can be used to trigger changes to your integrations when secrets are modified, providing smooth integration with other third-party applications.
|
||||
|
||||

|
||||
|
||||
To create a webhook for a particular project, go to `Project Settings > Webhooks`.
|
||||
|
||||
When creating a webhook, you can specify an environment and folder path (using glob patterns) to trigger only specific integrations.
|
||||
|
||||
## Secret Key Verification
|
||||
|
||||
A secret key is a way for users to verify that a webhook request was sent by Infisical and is intended for the correct integration.
|
||||
|
||||
When you provide a secret key, Infisical will sign the payload of the webhook request using the key and attach a header called `x-infisical-signature` to the request with a payload.
|
||||
|
||||
The header will be in the format `t=<timestamp>;<signature>`. You can then generate the signature yourself by generating a SHA256 hash of the payload with the secret key that you know.
|
||||
|
||||
If the signature in the header matches the signature that you generated, then you can be sure that the request was sent by Infisical and is intended for your integration. The timestamp in the header ensures that the request is not replayed.
|
||||
|
||||
### Webhook Payload Format
|
||||
|
||||
```json
|
||||
{
|
||||
"event": "secret.modified",
|
||||
"project": {
|
||||
"workspaceId":"the workspace id",
|
||||
"environment": "project environment",
|
||||
"secretPath": "project folder path"
|
||||
},
|
||||
"timestamp": ""
|
||||
}
|
||||
```
|
||||
BIN
docs/images/example-secret-referencing.png
Normal file
|
After Width: | Height: | Size: 246 KiB |
BIN
docs/images/integrations-bitbucket-auth.png
Normal file
|
After Width: | Height: | Size: 245 KiB |
BIN
docs/images/integrations-bitbucket-create.png
Normal file
|
After Width: | Height: | Size: 472 KiB |
BIN
docs/images/integrations-bitbucket.png
Normal file
|
After Width: | Height: | Size: 664 KiB |
BIN
docs/images/integrations-cloud-66-access-token.png
Normal file
|
After Width: | Height: | Size: 890 KiB |
BIN
docs/images/integrations-cloud-66-copy-pat.png
Normal file
|
After Width: | Height: | Size: 814 KiB |
BIN
docs/images/integrations-cloud-66-create.png
Normal file
|
After Width: | Height: | Size: 1.1 MiB |
BIN
docs/images/integrations-cloud-66-dashboard.png
Normal file
|
After Width: | Height: | Size: 742 KiB |
BIN
docs/images/integrations-cloud-66-done.png
Normal file
|
After Width: | Height: | Size: 1.3 MiB |
BIN
docs/images/integrations-cloud-66-infisical-dashboard.png
Normal file
|
After Width: | Height: | Size: 1.4 MiB |
BIN
docs/images/integrations-cloud-66-paste-pat.png
Normal file
|
After Width: | Height: | Size: 1.1 MiB |
BIN
docs/images/integrations-cloud-66-pat-setup.png
Normal file
|
After Width: | Height: | Size: 969 KiB |
BIN
docs/images/integrations-cloud-66-pat.png
Normal file
|
After Width: | Height: | Size: 812 KiB |
BIN
docs/images/integrations-codefresh-auth.png
Normal file
|
After Width: | Height: | Size: 433 KiB |
BIN
docs/images/integrations-codefresh-create.png
Normal file
|
After Width: | Height: | Size: 459 KiB |
BIN
docs/images/integrations-codefresh-dashboard.png
Normal file
|
After Width: | Height: | Size: 468 KiB |
BIN
docs/images/integrations-codefresh-token.png
Normal file
|
After Width: | Height: | Size: 304 KiB |
BIN
docs/images/integrations-codefresh.png
Normal file
|
After Width: | Height: | Size: 663 KiB |
BIN
docs/images/integrations-do-dashboard.png
Normal file
|
After Width: | Height: | Size: 1.1 MiB |
BIN
docs/images/integrations-do-enter-token.png
Normal file
|
After Width: | Height: | Size: 1.2 MiB |
BIN
docs/images/integrations-do-select-projects.png
Normal file
|
After Width: | Height: | Size: 1.2 MiB |
BIN
docs/images/integrations-do-success.png
Normal file
|
After Width: | Height: | Size: 1.4 MiB |
BIN
docs/images/integrations-do-token-modal.png
Normal file
|
After Width: | Height: | Size: 1.0 MiB |
|
Before Width: | Height: | Size: 1.6 MiB After Width: | Height: | Size: 1.4 MiB |
|
Before Width: | Height: | Size: 309 KiB After Width: | Height: | Size: 70 KiB |
BIN
docs/images/project-ip-whitelist-add.png
Normal file
|
After Width: | Height: | Size: 313 KiB |
BIN
docs/images/project-ip-whitelist.png
Normal file
|
After Width: | Height: | Size: 439 KiB |
BIN
docs/images/saml-okta-1.png
Normal file
|
After Width: | Height: | Size: 264 KiB |
BIN
docs/images/saml-okta-2.png
Normal file
|
After Width: | Height: | Size: 381 KiB |
BIN
docs/images/saml-okta-3.png
Normal file
|
After Width: | Height: | Size: 423 KiB |
BIN
docs/images/saml-okta-4.png
Normal file
|
After Width: | Height: | Size: 316 KiB |
BIN
docs/images/saml-okta-5.png
Normal file
|
After Width: | Height: | Size: 598 KiB |
BIN
docs/images/saml-okta-6.png
Normal file
|
After Width: | Height: | Size: 443 KiB |
BIN
docs/images/saml-okta-7.png
Normal file
|
After Width: | Height: | Size: 563 KiB |
BIN
docs/images/saml-okta-8.png
Normal file
|
After Width: | Height: | Size: 386 KiB |
BIN
docs/images/secret-import-add.png
Normal file
|
After Width: | Height: | Size: 275 KiB |
BIN
docs/images/secret-import-change-order.png
Normal file
|
After Width: | Height: | Size: 288 KiB |
BIN
docs/images/service-token-permissions.png
Normal file
|
After Width: | Height: | Size: 652 KiB |
BIN
docs/images/webhooks.png
Normal file
|
After Width: | Height: | Size: 129 KiB |
31
docs/integrations/cicd/bitbucket.mdx
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: "Bitbucket"
|
||||
description: "How to sync secrets from Infisical to Bitbucket"
|
||||
---
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- Set up and add envars to [Infisical Cloud](https://app.infisical.com)
|
||||
|
||||
## Navigate to your project's integrations tab
|
||||
|
||||

|
||||
|
||||
## Authorize Infisical for Bitbucket
|
||||
|
||||
Press on the Bitbucket tile and grant Infisical access to your Bitbucket account.
|
||||
|
||||

|
||||
|
||||
<Info>
|
||||
If this is your project's first cloud integration, then you'll have to grant
|
||||
Infisical access to your project's environment variables. Although this step
|
||||
breaks E2EE, it's necessary for Infisical to sync the environment variables to
|
||||
the cloud platform.
|
||||
</Info>
|
||||
|
||||
## Start integration
|
||||
|
||||
Select which Infisical environment secrets you want to sync to which Bitbucket repo and press start integration to start syncing secrets to the repo.
|
||||
|
||||

|
||||
37
docs/integrations/cicd/codefresh.mdx
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "Codefresh"
|
||||
description: "How to sync secrets from Infisical to Codefresh"
|
||||
---
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- Set up and add envars to [Infisical Cloud](https://app.infisical.com)
|
||||
|
||||
## Navigate to your project's integrations tab
|
||||
|
||||

|
||||
|
||||
## Authorize Infisical for Codefresh
|
||||
|
||||
Obtain an API key in User Settings > API Keys
|
||||
|
||||

|
||||

|
||||
|
||||
Press on the Codefresh tile and input your Codefresh API key to grant Infisical access to your Codefresh account.
|
||||
|
||||

|
||||
|
||||
<Info>
|
||||
If this is your project's first cloud integration, then you'll have to grant
|
||||
Infisical access to your project's environment variables. Although this step
|
||||
breaks E2EE, it's necessary for Infisical to sync the environment variables to
|
||||
the cloud platform.
|
||||
</Info>
|
||||
|
||||
## Start integration
|
||||
|
||||
Select which Infisical environment secrets you want to sync to which Codefresh service and press create integration to start syncing secrets to Codefresh.
|
||||
|
||||

|
||||

|
||||
55
docs/integrations/cloud/cloud-66.mdx
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "Cloud 66"
|
||||
description: "How to sync secrets from Infisical to Cloud 66"
|
||||
---
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- Set up and add envars to [Infisical Cloud](https://app.infisical.com)
|
||||
|
||||
## Navigate to your project's integrations tab
|
||||
|
||||

|
||||
|
||||
## Enter your Cloud 66 Access Token
|
||||
|
||||
In Cloud 66 Dashboard, click on the top right icon > Account Settings > Access Token
|
||||

|
||||

|
||||
|
||||
Create new Personal Access Token.
|
||||

|
||||
|
||||
Name it **infisical** and check **Public** and **Admin**. Then click "Create Token"
|
||||

|
||||
|
||||
Copy and save your token.
|
||||

|
||||
|
||||
### Go to Infisical Integration Page
|
||||
|
||||
Click on the Cloud 66 tile and enter your API token to grant Infisical access to your Cloud 66 account.
|
||||

|
||||
|
||||
<Info>
|
||||
If this is your project's first cloud integration, then you'll have to grant
|
||||
Infisical access to your project's environment variables. Although this step
|
||||
breaks E2EE, it's necessary for Infisical to sync the environment variables to
|
||||
the cloud platform.
|
||||
</Info>
|
||||
|
||||
Enter your Cloud 66 Personal Access Token here. Then click "Connect to Cloud 66".
|
||||

|
||||
|
||||
|
||||
## Start integration
|
||||
|
||||
Select which Infisical environment secrets you want to sync to which Cloud 66 stacks and press create integration to start syncing secrets to Cloud 66.
|
||||

|
||||
|
||||
<Warning>
|
||||
Any existing environment variables in Cloud 66 will be deleted when you start syncing. Make sure to add all the secrets into the Infisical dashboard first before doing any integrations.
|
||||
</Warning>
|
||||
|
||||
Done!
|
||||

|
||||
39
docs/integrations/cloud/digital-ocean-app-platform.mdx
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "Digital Ocean App Platform"
|
||||
description: "How to sync secrets from Infisical to Digital Ocean App Platform"
|
||||
---
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- Set up and add envars to [Infisical Cloud](https://app.infisical.com)
|
||||
|
||||
## Get your Digital Ocean Personal Access Tokens
|
||||
|
||||
On Digital Ocean dashboard, navigate to **API > Tokens** and click on "Generate New Token"
|
||||

|
||||
|
||||
Name it **infisical**, choose **No expiry**, and make sure to check **Write (optional)**. Then click on "Generate Token" and copy your API token.
|
||||

|
||||
|
||||
## Navigate to your project's integrations tab
|
||||
|
||||
Click on the **Digital Ocean App Platform** tile and enter your API token to grant Infisical access to your Digital Ocean account.
|
||||

|
||||
|
||||
<Info>
|
||||
If this is your project's first cloud integration, then you'll have to grant
|
||||
Infisical access to your project's environment variables. Although this step
|
||||
breaks E2EE, it's necessary for Infisical to sync the environment variables to
|
||||
the cloud platform.
|
||||
</Info>
|
||||
|
||||
Then enter your Digital Ocean Personal Access Token here. Then click "Connect to Digital Ocean App Platform".
|
||||

|
||||
|
||||
## Start integration
|
||||
|
||||
Select which Infisical environment secrets you want to sync to which Digital Ocean App and click "Create Integration".
|
||||

|
||||
|
||||
Done!
|
||||

|
||||
@@ -26,3 +26,7 @@ infisical run -- <your application start command>
|
||||
# Example
|
||||
infisical run -- npm run dev
|
||||
```
|
||||
|
||||
<Info>
|
||||
React environment variables must be prefixed with `REACT_APP_` to show up within the application
|
||||
</Info>
|
||||
|
||||
@@ -44,10 +44,17 @@ provider "infisical" {
|
||||
|
||||
### 3. Fetch Infisical Secrets
|
||||
|
||||
Use the `infisical_secrets` data source to fetch your secrets. This is defined with an empty block `{}` as the provider automatically fetches all secrets associated with your service token.
|
||||
Use the `infisical_secrets` data source to fetch your secrets. In this block, you must set the `env_slug` and `folder_path` to scope the secrets you want.
|
||||
|
||||
`env_slug` is the slug of the environment name. This slug name can be found under the project settings page on the Infisical dashboard.
|
||||
|
||||
`folder_path` is the path to the folder in a given environment. The path `/` for root of the environment where as `/folder1` is the folder at the root of the environment.
|
||||
|
||||
```hcl main.tf
|
||||
data "infisical_secrets" "my-secrets" {}
|
||||
data "infisical_secrets" "my-secrets" {
|
||||
env_slug = "dev"
|
||||
folder_path = "/some-folder/another-folder"
|
||||
}
|
||||
```
|
||||
|
||||
### 4. Define Outputs
|
||||
|
||||
@@ -29,6 +29,8 @@ Missing an integration? [Throw in a request](https://github.com/Infisical/infisi
|
||||
| [AWS Parameter Store](/integrations/cloud/aws-parameter-store) | Cloud | Available |
|
||||
| [AWS Secret Manager](/integrations/cloud/aws-secret-manager) | Cloud | Available |
|
||||
| [Azure Key Vault](/integrations/cloud/azure-key-vault) | Cloud | Available |
|
||||
| [BitBucket](/integrations/cicd/bitbucket) | CI/CD | Available |
|
||||
| [Codefresh](/integrations/cicd/codefresh) | CI/CD | Available |
|
||||
| [GitHub Actions](/integrations/cicd/githubactions) | CI/CD | Available |
|
||||
| [GitLab](/integrations/cicd/gitlab) | CI/CD | Available |
|
||||
| [CircleCI](/integrations/cicd/circleci) | CI/CD | Available |
|
||||
|
||||
@@ -11,11 +11,11 @@ Prerequisites:
|
||||
|
||||
Follow this [guide](./docker) to configure the Infisical CLI for each service that you wish to inject environment variables into; you'll have to update the Dockerfile of each service.
|
||||
|
||||
## Generate Infisical Tokens
|
||||
## Generate service token
|
||||
|
||||
Generate a unique [Infisical Token](/documentation/platform/token) for each service.
|
||||
|
||||
## Add Infisical Tokens to your Docker Compose file
|
||||
## Feed service token to your Docker Compose file
|
||||
|
||||
For each service you want to inject secrets into, set an environment variable called `INFISICAL_TOKEN` equal to a unique identifier variable.
|
||||
|
||||
|
||||
25
docs/integrations/platforms/docker-intro.mdx
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "Docker"
|
||||
description: "Learn how to feed secrets from Infisical into your docker application"
|
||||
---
|
||||
There are many methods to inject Infisical secrets to docker-based applications.
|
||||
Regardless of which method you choose, these methods will inject secrets from Infisical as environment variables into your Docker container.
|
||||
|
||||
<Card title="Docker Entrypoint" color="#ea5a0c" href="./docker">
|
||||
Install and run your app start command with Infisical CLI
|
||||
</Card>
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Docker run" color="#0285c7" href="./docker-pass-envs">
|
||||
Feed secrets via `--env-file` flag in docker run command
|
||||
</Card>
|
||||
<Card title="Docker compose" color="#16a34a" href="./docker-compose">
|
||||
Inject secrets to multiple services using Docker Compose
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
<Info>
|
||||
The main difference between the "Docker Entrypoint" and "Docker run" approach is where the Infisical CLI is installed.
|
||||
In most production settings, it's typically inconvenient to have the Infisical CLI installed and executed externally.
|
||||
As a result, we suggest using the "Docker Entrypoint" method for production purposes.
|
||||
However, if this limitation doesn't apply to you, select the method that best fits your needs.
|
||||
</Info>
|
||||
48
docs/integrations/platforms/docker-pass-envs.mdx
Normal file
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: "Docker Run"
|
||||
description: "Pass secrets to your docker container at run time"
|
||||
---
|
||||
|
||||
This method allows you to feed secrets from Infisical into your container using the `--env-file` flag of `docker run` command.
|
||||
Rather than giving the flag a file path to your env file, you'll use the Infisical CLI to create a virtual file path.
|
||||
|
||||
For this method to function as expected, you must have a bash shell (for processing substitution) and the [Infisical CLI](../../cli/overview) installed in the environment where you will be running the `docker run` command.
|
||||
|
||||
## 1. Authentication
|
||||
|
||||
If you are already logged in via the CLI you can skip this step. Otherwise, head to your project settings in Infisical Cloud to generate an [Infisical Token](/documentation/platform/token). The service token will allow you to authenticate and fetch secrets from Infisical.
|
||||
Once you have created a service token with the required permissions, you'll need to feed the token to the CLI.
|
||||
|
||||
#### Pass as flag
|
||||
You may use the --token flag to set the token
|
||||
|
||||
```bash
|
||||
infisical export --token=<>
|
||||
```
|
||||
|
||||
#### Pass via shell environment variable
|
||||
The CLI is configured to look for an environment variable named `INFISICAL_TOKEN`. If set, it'll attempt to use it for authentication.
|
||||
|
||||
```bash
|
||||
export INFISICAL_TOKEN=<>
|
||||
```
|
||||
|
||||
<Warning>
|
||||
In production scenarios, please to avoid using the `infisical login` command and instead use a [service token](/documentation/platform/token).
|
||||
</Warning>
|
||||
|
||||
## 2. Run your docker command with Infisical
|
||||
Next, use the --env-file flag of the `docker run` command with Infisical CLI to point to your secrets.
|
||||
Under the hood, this command will fetch secrets from Infisical and serve them as a file to the `--env-file` flag.
|
||||
|
||||
```bash
|
||||
# In this example, executing a docker run command will initiate an empty Alpine container and display the environment variables passed to it by Infisical.
|
||||
docker run --rm --env-file <(infisical export --format=dotenv) alpine printenv
|
||||
```
|
||||
|
||||
To view all options of the `export` command, click [here](../../cli/commands/export)
|
||||
|
||||
|
||||
<Warning>
|
||||
When using the --env-file option, Docker does not have the capability to support secrets that span multiple lines.
|
||||
</Warning>
|
||||
@@ -1,11 +1,10 @@
|
||||
---
|
||||
title: "Docker"
|
||||
title: "Docker Entrypoint"
|
||||
description: "How to use Infisical to inject environment variables into a Docker container."
|
||||
---
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- Set up and add envars to [Infisical Cloud](https://app.infisical.com)
|
||||
This approach allows you to inject secrets from Infisical directly into your application.
|
||||
This is achieved by installing the Infisical CLI into your docker image and modifying your start command to execute with Infisical.
|
||||
|
||||
## Add the Infisical CLI to your Dockerfile
|
||||
|
||||
@@ -33,6 +32,10 @@ Prerequisites:
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
####
|
||||
<Tip>
|
||||
We recommend you to set the version of the CLI to a specific version. This will help keep your CLI version consistent across reinstalls. [View versions](https://cloudsmith.io/~infisical/repos/infisical-cli/packages/)
|
||||
</Tip>
|
||||
|
||||
## Modify the start command in your Dockerfile
|
||||
|
||||
@@ -48,18 +51,17 @@ CMD ["infisical", "run", "--", "npm", "run", "start"]
|
||||
CMD ["infisical", "run", "--command", "npm run start && ..."]
|
||||
```
|
||||
|
||||
## Generate an Infisical Token
|
||||
## Generate an service token
|
||||
|
||||
Head to your project settings in Infisical Cloud to generate an [Infisical Token](/documentation/platform/token).
|
||||
Head to your project settings in the Infisical dashboard to generate an [service token](/documentation/platform/token).
|
||||
This service token will allow you to authenticate and fetch secrets from Infisical.
|
||||
Once you have created a service token with the required permissions, you’ll need to feed the token to the CLI installed in your docker container.
|
||||
|
||||
## Feed Docker your Infisical Token
|
||||
## Feed service token to docker container
|
||||
The last step is to give the Infisical CLI installed in your Docker container access to the service token. This will allow the CLI to fetch and inject the secrets into your application.
|
||||
|
||||
To feed the service token to the container, use the INFISICAL_TOKEN environment variable as shown below.
|
||||
|
||||
```bash
|
||||
docker run --env INFISICAL_TOKEN=[token] [DOCKER-IMAGE]...
|
||||
```
|
||||
|
||||
<Info>
|
||||
|
||||
The Infisical CLI uses the detected `INFISICAL_TOKEN` environment variable to authenticate, retrieve, and inject the environment variables which the token is authorized for.
|
||||
|
||||
</Info>
|
||||
|
||||
@@ -15,33 +15,49 @@ The operator continuously updates secrets and can also reload dependent deployme
|
||||
The operator can be install via [Helm](helm.sh) or [kubectl](https://github.com/kubernetes/kubectl)
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Helm">
|
||||
Install Infisical Helm repository
|
||||
<Tab title="Helm (recommended)">
|
||||
**Install the latest Infisical Helm repository**
|
||||
```bash
|
||||
helm repo add infisical-helm-charts 'https://dl.cloudsmith.io/public/infisical/helm-charts/helm/charts/'
|
||||
|
||||
helm repo update
|
||||
```
|
||||
|
||||
Install the Helm chart
|
||||
**Install the Helm chart**
|
||||
|
||||
For production deployments, it is highly recommended to set the chart version and the application version during installs and upgrades.
|
||||
This will prevent the operator from being accidentally updated to the latest version and introduce unintended breaking changes.
|
||||
|
||||
View application versions [here](https://hub.docker.com/r/infisical/kubernetes-operator/tags) and chart versions [here](https://cloudsmith.io/~infisical/repos/helm-charts/packages/detail/helm/secrets-operator/#versions)
|
||||
|
||||
```bash
|
||||
helm install --generate-name infisical-helm-charts/secrets-operator
|
||||
helm install --generate-name infisical-helm-charts/secrets-operator --version=<PLACE-CHART-VERSION-HERE> --set controllerManager.manager.image.tag=<PLACE-APP-VERSION-HERE>
|
||||
|
||||
# Example installing app version v0.2.0 and chart version 0.1.4
|
||||
helm install --generate-name infisical-helm-charts/secrets-operator --version=0.1.4 --set controllerManager.manager.image.tag=v0.2.0
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab title="Kubectl">
|
||||
The operator will be installed in `infisical-operator-system` namespace
|
||||
```
|
||||
For production deployments, it is highly recommended to set the version of the Kubernetes operator manually instead of pointing to the latest version.
|
||||
Doing so will help you avoid accidental updates to the newest release which may introduce unintended breaking changes. View all application versions [here](https://hub.docker.com/r/infisical/kubernetes-operator/tags).
|
||||
|
||||
|
||||
The command below will install the most recent version of the Kubernetes operator.
|
||||
However, to set the version manually, download the manifest and set the image tag version of `infisical/kubernetes-operator` according to your desired version.
|
||||
|
||||
Once you apply the manifest, the operator will be installed in `infisical-operator-system` namespace.
|
||||
|
||||
```
|
||||
kubectl apply -f https://raw.githubusercontent.com/Infisical/infisical/main/k8-operator/kubectl-install/install-secrets-operator.yaml
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## Sync Infisical Secrets to your cluster
|
||||
To retrieve secrets from an Infisical project and save them as native Kubernetes secrets within a specific namespace, utilize the `InfisicalSecret` custom resource definition (CRD).
|
||||
This resource can be created after installing the Infisical operator. For each new managed secret, you will need to create a new InfisicalSecret CRD.
|
||||
Once you have installed the operator to your cluster, you'll need to create a `InfisicalSecret` custom resource definition (CRD).
|
||||
|
||||
```yaml
|
||||
```yaml example-infisical-secret-crd.yaml
|
||||
apiVersion: secrets.infisical.com/v1alpha1
|
||||
kind: InfisicalSecret
|
||||
metadata:
|
||||
@@ -50,15 +66,18 @@ metadata:
|
||||
spec:
|
||||
# The host that should be used to pull secrets from. If left empty, the value specified in Global configuration will be used
|
||||
hostAPI: https://app.infisical.com/api
|
||||
resyncInterval: 60 # <-- the time in seconds between secret re-sync. Faster re-syncs will require higher rate limits
|
||||
resyncInterval: 60
|
||||
authentication:
|
||||
serviceToken:
|
||||
serviceTokenSecretReference:
|
||||
secretName: service-token
|
||||
secretNamespace: option
|
||||
secretNamespace: default
|
||||
secretsScope:
|
||||
envSlug: dev
|
||||
secretsPath: "/"
|
||||
managedSecretReference:
|
||||
secretName: managed-secret # <-- the name of kubernetes secret that will be created
|
||||
secretNamespace: default # <-- where the kubernetes secret that will be created
|
||||
secretNamespace: default # <-- where the kubernetes secret should be created
|
||||
```
|
||||
### InfisicalSecret CRD properties
|
||||
|
||||
@@ -86,45 +105,59 @@ Default re-sync interval is every 1 minute.
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="authentication">
|
||||
The `authentication` property tells the operator where it should look to find credentials needed to fetch secrets from Infisical.
|
||||
This block defines the method that will be used to authenticate with Infisical so that secrets can be fetched. Currently, only [Service Tokens](../../documentation/platform/token) can be used to authenticate with Infisical.
|
||||
</Accordion>
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Service Token">
|
||||
Authenticating with service tokens is a great option when you have a small number of services you'd like to fetch secrets for and are looking for the least amount of setup.
|
||||
|
||||
#### 1. Generate service token
|
||||
<Accordion title="authentication.serviceToken.serviceTokenSecretReference">
|
||||
The service token required to authenticate with Infisical needs to be stored in a Kubernetes secret. This block defines the reference to the name and name space of secret that stores this service token.
|
||||
Follow the instructions below to create and store the service token in a Kubernetes secrets and reference it in your CRD.
|
||||
|
||||
You can generate a [service token](../../documentation/platform/token) for an Infisical project by heading over to the Infisical dashboard then to Project Settings.
|
||||
#### 1. Generate service token
|
||||
|
||||
#### 2. Create Kubernetes secret containing service token
|
||||
You can generate a [service token](../../documentation/platform/token) for an Infisical project by heading over to the Infisical dashboard then to Project Settings.
|
||||
|
||||
Once you have generated the service token, you will need to create a Kubernetes secret containing the service token you generated.
|
||||
To quickly create a Kubernetes secret containing the generated service token, you can run the command below.
|
||||
#### 2. Create Kubernetes secret containing service token
|
||||
|
||||
``` bash
|
||||
kubectl create secret generic service-token --from-literal=infisicalToken=<your-service-token-here>
|
||||
```
|
||||
Once you have generated the service token, you will need to create a Kubernetes secret containing the service token you generated.
|
||||
To quickly create a Kubernetes secret containing the generated service token, you can run the command below. Make sure you replace `<your-service-token-here>` with your service token.
|
||||
|
||||
#### 3. Add reference for the Kubernetes secret containing service token
|
||||
``` bash
|
||||
kubectl create secret generic service-token --from-literal=infisicalToken=<your-service-token-here>
|
||||
```
|
||||
|
||||
Once the secret is created, add the name and namespace of the secret that was just created under `authentication.serviceToken.serviceTokenSecretReference` field in the InfisicalSecret resource.
|
||||
#### 3. Add reference for the Kubernetes secret containing service token
|
||||
|
||||
## Example
|
||||
```yaml
|
||||
apiVersion: secrets.infisical.com/v1alpha1
|
||||
kind: InfisicalSecret
|
||||
metadata:
|
||||
name: infisicalsecret-sample-crd
|
||||
spec:
|
||||
authentication:
|
||||
serviceToken:
|
||||
serviceTokenSecretReference:
|
||||
secretName: service-token # <-- name of the Kubernetes secret that stores our service token
|
||||
secretNamespace: option # <-- namespace of the Kubernetes secret that stores our service token
|
||||
...
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
Once the secret is created, add the name and namespace of the secret that was just created under `authentication.serviceToken.serviceTokenSecretReference` field in the InfisicalSecret resource.
|
||||
|
||||
## Example
|
||||
```yaml
|
||||
apiVersion: secrets.infisical.com/v1alpha1
|
||||
kind: InfisicalSecret
|
||||
metadata:
|
||||
name: infisicalsecret-sample-crd
|
||||
spec:
|
||||
authentication:
|
||||
serviceToken:
|
||||
serviceTokenSecretReference:
|
||||
secretName: service-token # <-- name of the Kubernetes secret that stores our service token
|
||||
secretNamespace: option # <-- namespace of the Kubernetes secret that stores our service token
|
||||
...
|
||||
```
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="authentication.serviceToken.secretsScope">
|
||||
This block defines the scope of what secrets should be fetched. This is needed as your service token can have access to multiple folders and environments.
|
||||
A scope is defined by `envSlug` and `secretsPath`.
|
||||
|
||||
#### envSlug
|
||||
|
||||
This refers to the short hand name of an environment. For example for the `development` environment the environment slug is `dev`. You can locate the slug of your environment by heading to your project settings in the Infisical dashboard.
|
||||
|
||||
#### secretsPath
|
||||
|
||||
secretsPath is the path to the secret in the given environment. For example a path of `/` would refer to the root of the environment whereas `/folder1` would refer to the secrets in folder1 from the root.
|
||||
|
||||
Both fields are required.
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="managedSecretReference">
|
||||
@@ -135,6 +168,14 @@ The managed secret be should be created in the same namespace as the deployment
|
||||
|
||||
</Accordion>
|
||||
|
||||
### Apply the Infisical CRD to your cluster
|
||||
Once you have configured the Infisical CRD with the required fields, you can apply it to your cluster.
|
||||
After applying, you should notice that the managed secret has been created in the desired namespace your specified.
|
||||
|
||||
```
|
||||
kubectl apply -f example-infisical-secret-crd.yaml
|
||||
```
|
||||
|
||||
### Verify managed secret creation
|
||||
|
||||
To verify that the operator has successfully created the managed secret, you can check the secrets in the namespace that was specified.
|
||||
|
||||
@@ -21,6 +21,10 @@
|
||||
"to": "#F8B7BD"
|
||||
}
|
||||
},
|
||||
"feedback": {
|
||||
"suggestEdit": true,
|
||||
"raiseIssue": true
|
||||
},
|
||||
"api": {
|
||||
"baseUrl": ["https://app.infisical.com", "http://localhost:8080"],
|
||||
"auth": {
|
||||
@@ -69,7 +73,7 @@
|
||||
{
|
||||
"name": "Slack",
|
||||
"icon": "slack",
|
||||
"url": "https://join.slack.com/t/infisical-users/shared_invite/zt-1wehzfnzn-1aMo5JcGENJiNAC2SD8Jlg"
|
||||
"url": "https://infisical.com/slack"
|
||||
},
|
||||
{
|
||||
"name": "GitHub",
|
||||
@@ -87,9 +91,8 @@
|
||||
"documentation/getting-started/introduction",
|
||||
"documentation/getting-started/platform",
|
||||
"documentation/getting-started/sdks",
|
||||
"documentation/getting-started/cli",
|
||||
"documentation/getting-started/docker",
|
||||
"documentation/getting-started/kubernetes",
|
||||
"integrations/platforms/kubernetes",
|
||||
"integrations/platforms/docker-intro",
|
||||
"documentation/getting-started/api"
|
||||
]
|
||||
},
|
||||
@@ -110,11 +113,15 @@
|
||||
"documentation/platform/organization",
|
||||
"documentation/platform/project",
|
||||
"documentation/platform/folder",
|
||||
"documentation/platform/secret-reference",
|
||||
"documentation/platform/webhooks",
|
||||
"documentation/platform/pit-recovery",
|
||||
"documentation/platform/secret-versioning",
|
||||
"documentation/platform/audit-logs",
|
||||
"documentation/platform/token",
|
||||
"documentation/platform/ip-allowlisting",
|
||||
"documentation/platform/mfa",
|
||||
"documentation/platform/token"
|
||||
"documentation/platform/saml"
|
||||
]
|
||||
},
|
||||
{
|
||||
@@ -172,16 +179,28 @@
|
||||
{
|
||||
"group": "Integrations",
|
||||
"pages": [
|
||||
"integrations/overview",
|
||||
"integrations/overview"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Infrastructure Integrations",
|
||||
"pages": [
|
||||
{
|
||||
"group": "Docker",
|
||||
"pages": [
|
||||
"integrations/platforms/docker-intro",
|
||||
"integrations/platforms/docker",
|
||||
"integrations/platforms/docker-pass-envs",
|
||||
"integrations/platforms/docker-compose"
|
||||
]
|
||||
},
|
||||
"integrations/platforms/kubernetes",
|
||||
"integrations/frameworks/terraform",
|
||||
"integrations/frameworks/terraform"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "3rd-party Integrations",
|
||||
"pages": [
|
||||
{
|
||||
"group": "AWS",
|
||||
"pages": [
|
||||
@@ -189,6 +208,12 @@
|
||||
"integrations/cloud/aws-secret-manager"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Digital Ocean",
|
||||
"pages": [
|
||||
"integrations/cloud/digital-ocean-app-platform"
|
||||
]
|
||||
},
|
||||
"integrations/cloud/heroku",
|
||||
"integrations/cloud/vercel",
|
||||
"integrations/cloud/netlify",
|
||||
@@ -202,10 +227,18 @@
|
||||
"integrations/cloud/checkly",
|
||||
"integrations/cloud/hashicorp-vault",
|
||||
"integrations/cloud/azure-key-vault",
|
||||
"integrations/cloud/cloud-66",
|
||||
"integrations/cicd/githubactions",
|
||||
"integrations/cicd/gitlab",
|
||||
"integrations/cicd/circleci",
|
||||
"integrations/cicd/travisci",
|
||||
"integrations/cicd/bitbucket",
|
||||
"integrations/cicd/codefresh"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Framework Integrations",
|
||||
"pages": [
|
||||
"integrations/frameworks/spring-boot-maven",
|
||||
"integrations/frameworks/react",
|
||||
"integrations/frameworks/vue",
|
||||
@@ -230,18 +263,6 @@
|
||||
"group": "Overview",
|
||||
"pages": ["sdks/overview"]
|
||||
},
|
||||
{
|
||||
"group": "SDKs",
|
||||
"pages": [
|
||||
"sdks/languages/node",
|
||||
"sdks/languages/python",
|
||||
"sdks/languages/java",
|
||||
"sdks/languages/ruby",
|
||||
"sdks/languages/go",
|
||||
"sdks/languages/rust",
|
||||
"sdks/languages/php"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Overview",
|
||||
"pages": [
|
||||
@@ -312,7 +333,8 @@
|
||||
"pages": [
|
||||
"security/overview",
|
||||
"security/data-model",
|
||||
"security/mechanics"
|
||||
"security/mechanics",
|
||||
"security/service-tokens"
|
||||
]
|
||||
},
|
||||
{
|
||||
|
||||
22
docs/security/service-tokens.mdx
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "Service Tokens"
|
||||
description: "Understanding service tokens and their best practices"
|
||||
---
|
||||
|
||||
## Background
|
||||
|
||||
Many clients use service tokens to authenticate and read/write secrets from/to Infisical.
|
||||
|
||||
Each service token consist of two parts used for authentication and decryption, separated by `.`. Consider the token `st.abc.def.ghi`. Here, `st.abc.def` can be used to authenticate with the API, by including it in the `Authorization` header under `Bearer st.abc.def`, and retrieve (encrypted) secrets as well as a project key back. Meanwhile, `ghi`, a hex-string, can be used to decrypt the project key used to decrypt the secrets.
|
||||
|
||||
Note that when using service tokens via select client methods like SDK or CLI, cryptographic operations are abstracted for you that is the token is parsed and encryption/decryption operations are handled. If using service tokens with the REST API and end-to-end encryption enabled, then you will have to handle the encryption/decryption operations yourself.
|
||||
|
||||
## Recommendations
|
||||
|
||||
1. Issuance: When creating a new service token, it’s important to consider the [principle of least privilege(PoLP)](https://en.wikipedia.org/wiki/Principle_of_least_privilege) when setting its scope and expiration date. For example, if the client using the token only requires access to a staging environment, then you should scope the token to that environment only; you can further scope tokens to path(s) within environment(s) if you happen to use [path-based secret storage](/documentation/platform/folder). Likewise, if the client does not intend to access secrets indefinitely, then you may consider setting a finite lifetime for the token such as 6 months or 1 year from now. Finally, you should consider carefully whether or not your client requires the ability to read and/or write secrets from/to Infisical.
|
||||
|
||||
2. Network access: We recommend configuring the IP whitelist settings of each project to allow either single IP addresses or CIDR-notated range of addresses to read/write secrets to Infisical. With this feature, you can specify the IP range of your client servers to restrict access to your project in Infisical.
|
||||
|
||||
3. Storage: Since service tokens grant access to your secrets, we recommend storing service tokens securely across your development cycle whether it be in a `.env` file in local development or as an environment variable of your deployment platform.
|
||||
|
||||
4. Rotation: We recommend periodically rotating the service token, even in the absence of compromise. Since service tokens are capable of decrypting project keys used to decrypt secrets, all of which use AES-256-GCM encryption, they should be rotated before approximately 2^32 encryptions have been performed; this follows the guidance set forth by NIST publication 800-38D. Note that Infisical keeps track of the number of times that service tokens are used and will alert you when you have reached 90% of the recommended capacity.
|
||||
@@ -3,14 +3,14 @@ title: "Configure email service"
|
||||
description: "How to configure your email when self-hosting Infisical."
|
||||
---
|
||||
|
||||
By default, the core functions of Infisical work without any email service configuration. Without email service, basic sign up/login and secret operations will function without any issue.
|
||||
By default, the core functions of Infisical work without any email service configuration. Without email service, basic sign up/login and secret operations will function without any issue.
|
||||
However, the following functionality will be disabled.
|
||||
|
||||
- Multi-factor authentication
|
||||
- Multi-factor authentication
|
||||
- Sending invite links via email for projects to teammates
|
||||
- Sending alerts such as suspicious login attempts
|
||||
- Sending alerts such as suspicious login attempts
|
||||
|
||||
## General configuration
|
||||
## Configuration
|
||||
|
||||
If you choose to setup email service, you need to configure the following SMTP [environment variables](https://infisical.com/docs/self-hosting/configuration/envars):
|
||||
|
||||
@@ -157,11 +157,30 @@ SMTP_FROM_NAME=Infisical
|
||||
As per the [notice](https://support.google.com/accounts/answer/6010255?hl=en) by Google, you should note that using Gmail credentials for SMTP configuration
|
||||
will only work for Google Workspace or Google Cloud Identity customers as of May 30, 2022.
|
||||
|
||||
Put differently, the SMTP configuration is only possible with business (not personal) Gmail credentials.
|
||||
Put differently, the SMTP configuration is only possible with business (not personal) Gmail credentials.
|
||||
|
||||
</Warning>
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Office365">
|
||||
|
||||
1. Create an account and configure [Office365](https://www.office.com/) to send emails.
|
||||
|
||||
2. With your login credentials, you can now set up your SMTP environment variables:
|
||||
|
||||
```
|
||||
SMTP_HOST=smtp.office365.com
|
||||
SMTP_USERNAME=username@yourdomain.com # your username
|
||||
SMTP_PASSWORD=password # your password
|
||||
SMTP_PORT=587
|
||||
SMTP_SECURE=true
|
||||
SMTP_FROM_ADDRESS=username@yourdomain.com
|
||||
SMTP_FROM_NAME=Infisical
|
||||
```
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Zoho Mail">
|
||||
|
||||
1. Create an account and configure [Zoho Mail](https://www.zoho.com/mail/) to send emails.
|
||||
|
||||
@@ -105,7 +105,15 @@ Other environment variables are listed below to increase the functionality of yo
|
||||
</ParamField>
|
||||
|
||||
<ParamField query="CLIENT_SLUG_VERCEL" type="string" default="none" optional>
|
||||
OAuth2 slug for Netlify integration
|
||||
OAuth2 slug for Vercel integration
|
||||
</ParamField>
|
||||
|
||||
<ParamField query="CLIENT_ID_BITBUCKET" type="string" default="none" optional>
|
||||
OAuth2 client ID for BitBucket integration
|
||||
</ParamField>
|
||||
|
||||
<ParamField query="CLIENT_SECRET_BITBUCKET" type="string" default="none" optional>
|
||||
OAuth2 client secret for BitBucket integration
|
||||
</ParamField>
|
||||
</Tab>
|
||||
<Tab title="Auth Integrations">
|
||||
|
||||
@@ -8,7 +8,7 @@ Self-hosted Infisical allows you to maintain your sensitive information within y
|
||||
Choose from a variety of deployment options listed below to get started.
|
||||
|
||||
<Card
|
||||
title="Kubernetes"
|
||||
title="Kubernetes (recommended)"
|
||||
color="#ea5a0c"
|
||||
href="deployment-options/kubernetes-helm"
|
||||
>
|
||||
|
||||