Feat: API Docs revamp (Service Token Deprecation)
@@ -4,7 +4,7 @@ openapi: "GET /api/v2/service-token"
|
|||||||
---
|
---
|
||||||
|
|
||||||
<Warning>
|
<Warning>
|
||||||
This endpoint will be deprecated in the near future with the removal of service tokens in Q1/Q2 2024.
|
This endpoint is deprecated and will be removed in the future.
|
||||||
|
|
||||||
We recommend switching to using [identities](/documentation/platform/identities/overview) if your client supports it.
|
We recommend switching to using [Machine Identities](/documentation/platform/identities/machine-identities).
|
||||||
</Warning>
|
</Warning>
|
||||||
|
|||||||
@@ -40,12 +40,21 @@ Export environment variables from the platform into a file format.
|
|||||||
|
|
||||||
### Environment variables
|
### Environment variables
|
||||||
<Accordion title="INFISICAL_TOKEN">
|
<Accordion title="INFISICAL_TOKEN">
|
||||||
Used to fetch secrets via a [service token](/documentation/platform/token) apposed to logged in credentials. Simply, export this variable in the terminal before running this command.
|
Used to fetch secrets via a [machine identities](/documentation/platform/identities/machine-identities) apposed to logged in credentials. Simply, export this variable in the terminal before running this command.
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
# Example
|
# Example
|
||||||
export INFISICAL_TOKEN=st.63e03c4a97cb4a747186c71e.ed5b46a34c078a8f94e8228f4ab0ff97.4f7f38034811995997d72badf44b42ec
|
export INFISICAL_TOKEN=$(infisical login --method=universal-auth --client-id=<identity-client-id> --client-secret=<identity-client-secret> --silent --plain) # --plain flag will output only the token, so it can be fed to an environment variable. --silent will disable any update messages.
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|
||||||
|
<Info>
|
||||||
|
Alternatively you may also use service tokens. **Service tokens are legacy tokens that are a precursor to machine identities, and will be removed in the future.**
|
||||||
|
```bash
|
||||||
|
# Example
|
||||||
|
export INFISICAL_TOKEN=<service-token>
|
||||||
|
```
|
||||||
|
</Info>
|
||||||
</Accordion>
|
</Accordion>
|
||||||
|
|
||||||
<Accordion title="INFISICAL_DISABLE_UPDATE_CHECK">
|
<Accordion title="INFISICAL_DISABLE_UPDATE_CHECK">
|
||||||
|
|||||||
@@ -42,12 +42,20 @@ Inject secrets from Infisical into your application process.
|
|||||||
|
|
||||||
### Environment variables
|
### Environment variables
|
||||||
<Accordion title="INFISICAL_TOKEN">
|
<Accordion title="INFISICAL_TOKEN">
|
||||||
Used to fetch secrets via a [service token](/documentation/platform/token) apposed to logged in credentials. Simply, export this variable in the terminal before running this command.
|
Used to fetch secrets via a [machine identity](/documentation/platform/identities/machine-identities) apposed to logged in credentials. Simply, export this variable in the terminal before running this command.
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
# Example
|
# Example
|
||||||
export INFISICAL_TOKEN=st.63e03c4a97cb4a747186c71e.ed5b46a34c078a8f94e8228f4ab0ff97.4f7f38034811995997d72badf44b42ec
|
export INFISICAL_TOKEN=$(infisical login --method=universal-auth --client-id=<identity-client-id> --client-secret=<identity-client-secret> --silent --plain) # --plain flag will output only the token, so it can be fed to an environment variable. --silent will disable any update messages.
|
||||||
```
|
```
|
||||||
|
|
||||||
|
<Info>
|
||||||
|
Alternatively you may also use service tokens. **Service tokens are legacy tokens that are a precursor to machine identities, and will be removed in the future.**
|
||||||
|
```bash
|
||||||
|
# Example
|
||||||
|
export INFISICAL_TOKEN=<service-token>
|
||||||
|
```
|
||||||
|
</Info>
|
||||||
</Accordion>
|
</Accordion>
|
||||||
|
|
||||||
<Accordion title="INFISICAL_DISABLE_UPDATE_CHECK">
|
<Accordion title="INFISICAL_DISABLE_UPDATE_CHECK">
|
||||||
@@ -81,12 +89,21 @@ Inject secrets from Infisical into your application process.
|
|||||||
```
|
```
|
||||||
</Accordion>
|
</Accordion>
|
||||||
|
|
||||||
<Accordion title="--token">
|
<Accordion title="--projectId">
|
||||||
If you are using a [service token](/documentation/platform/token) to authenticate, you can pass the token as a flag
|
The project ID to fetch secrets from. This is required when using a machine identity to authenticate.
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
# Example
|
# Example
|
||||||
infisical run --token="st.63e03c4a97cb4a747186c71e.ed5b46a34c078a8f94e8228f4ab0ff97.4f7f38034811995997d72badf44b42ec" -- npm run start
|
infisical run --projectId=<project-id> -- npm run dev
|
||||||
|
```
|
||||||
|
</Accordion>
|
||||||
|
|
||||||
|
<Accordion title="--token">
|
||||||
|
If you are using a [machine identity](/documentation/platform/identities/machine-identities) to authenticate, you can pass the token as a flag
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Example
|
||||||
|
infisical run --token="<universal-auth-access-token>" --projectId=<project-id> -- npm run start
|
||||||
```
|
```
|
||||||
|
|
||||||
You may also expose the token to the CLI by setting the environment variable `INFISICAL_TOKEN` before executing the run command. This will have the same effect as setting the token with `--token` flag
|
You may also expose the token to the CLI by setting the environment variable `INFISICAL_TOKEN` before executing the run command. This will have the same effect as setting the token with `--token` flag
|
||||||
|
|||||||
@@ -23,13 +23,20 @@ $ infisical secrets
|
|||||||
### Environment variables
|
### Environment variables
|
||||||
|
|
||||||
<Accordion title="INFISICAL_TOKEN">
|
<Accordion title="INFISICAL_TOKEN">
|
||||||
Used to fetch secrets via a [service token](/documentation/platform/token) apposed to logged in credentials. Simply, export this variable in the terminal before running this command.
|
Used to fetch secrets via a [machine identity](/documentation/platform/identities/machine-identities) apposed to logged in credentials. Simply, export this variable in the terminal before running this command.
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
# Example
|
# Example
|
||||||
export INFISICAL_TOKEN=st.63e03c4a97cb4a747186c71e.ed5b46a34c078a8f94e8228f4ab0ff97.4f7f38034811995997d72badf44b42ec
|
export INFISICAL_TOKEN=$(infisical login --method=universal-auth --client-id=<identity-client-id> --client-secret=<identity-client-secret> --silent --plain) # --plain flag will output only the token, so it can be fed to an environment variable. --silent will disable any update messages.
|
||||||
```
|
```
|
||||||
|
|
||||||
|
<Info>
|
||||||
|
Alternatively you may also use service tokens. **Service tokens are legacy tokens that are a precursor to machine identities, and will be removed in the future.**
|
||||||
|
```bash
|
||||||
|
# Example
|
||||||
|
export INFISICAL_TOKEN=<service-token>
|
||||||
|
```
|
||||||
|
</Info>
|
||||||
</Accordion>
|
</Accordion>
|
||||||
|
|
||||||
<Accordion title="INFISICAL_DISABLE_UPDATE_CHECK">
|
<Accordion title="INFISICAL_DISABLE_UPDATE_CHECK">
|
||||||
@@ -53,6 +60,15 @@ $ infisical secrets
|
|||||||
|
|
||||||
</Accordion>
|
</Accordion>
|
||||||
|
|
||||||
|
<Accordion title="--projectId">
|
||||||
|
The project ID to fetch secrets from. This is required when using a machine identity to authenticate.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Example
|
||||||
|
infisical secrets --projectId=<project-id>
|
||||||
|
```
|
||||||
|
</Accordion>
|
||||||
|
|
||||||
<Accordion title="--env">
|
<Accordion title="--env">
|
||||||
Used to select the environment name on which actions should be taken on
|
Used to select the environment name on which actions should be taken on
|
||||||
|
|
||||||
@@ -186,7 +202,7 @@ $ infisical secrets folders
|
|||||||
</Accordion>
|
</Accordion>
|
||||||
|
|
||||||
<Accordion title="--token">
|
<Accordion title="--token">
|
||||||
Fetch folders using the Infisical service token
|
Fetch folders using an Infisical universal auth access token
|
||||||
|
|
||||||
Default value: ``
|
Default value: ``
|
||||||
</Accordion>
|
</Accordion>
|
||||||
|
|||||||
@@ -3,6 +3,10 @@ title: "infisical service-token"
|
|||||||
description: "Manage Infisical service tokens"
|
description: "Manage Infisical service tokens"
|
||||||
---
|
---
|
||||||
|
|
||||||
|
<Warning>
|
||||||
|
This command is deprecated and will be removed in the near future. Please switch to [Machine Identities](/documentation/platform/identities/machine-identities) for authenticating with Infisical.
|
||||||
|
</Warning>
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
infisical service-token create --scope=dev:/global --scope=dev:/backend --access-level=read --access-level=write
|
infisical service-token create --scope=dev:/global --scope=dev:/backend --access-level=read --access-level=write
|
||||||
```
|
```
|
||||||
|
|||||||
@@ -1,22 +0,0 @@
|
|||||||
---
|
|
||||||
title: "Infisical Token"
|
|
||||||
description: "How to use Infisical service token within the CLI."
|
|
||||||
---
|
|
||||||
|
|
||||||
Prerequisite: [Infisical Token and How to Generate One](/documentation/platform/token).
|
|
||||||
|
|
||||||
It's possible to use the CLI to sync environment variables without manually entering login credentials by using a service token in the prerequisite link above.
|
|
||||||
|
|
||||||
## Feeding Infisical Token to the CLI
|
|
||||||
|
|
||||||
The CLI looks out for an environment variable called the `INFISICAL_TOKEN` which you can set depending on where you run the CLI. If `INFISICAL_TOKEN` is detected by the CLI, it will authenticate and retrieve the environment variables which the token is authorized for.
|
|
||||||
|
|
||||||
A common use-case is to use the Infisical Token to fetch environment variables with Docker. More specifically, a token can be passed to a container as an environment variable for the CLI to authenticate and pull its corresponding secrets. Check out the integration guides for that:
|
|
||||||
|
|
||||||
- [Docker](../../integrations/platforms/docker)
|
|
||||||
- [Docker Compose](../../integrations/platforms/docker-compose)
|
|
||||||
|
|
||||||
<Info>
|
|
||||||
Once the token is expired, the CLI using it will no longer be able to make
|
|
||||||
requests with it.
|
|
||||||
</Info>
|
|
||||||
@@ -33,26 +33,67 @@ The distinguishing factor, however, is the authentication method used.
|
|||||||
</Tab>
|
</Tab>
|
||||||
|
|
||||||
<Tab title="Staging, production & all other use case">
|
<Tab title="Staging, production & all other use case">
|
||||||
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.
|
<Tabs>
|
||||||
Once you have created a service token with the required permissions, you'll need to feed the token to the CLI.
|
<Tab title="Machine Identities (Recommended)">
|
||||||
|
|
||||||
#### Pass as flag
|
## Machine Identities
|
||||||
You may use the --token flag to set the token
|
|
||||||
|
|
||||||
```
|
To use Infisical for non local development scenarios, please create a [machine identity](../documentation/platform/identities/machine-identities). The machine identity will allow you to authenticate and interact with Infisical.
|
||||||
infisical export --token=<>
|
Once you have created a machine identity with the required permissions, you'll need to feed the token to the CLI.
|
||||||
infisical secrets --token=<>
|
|
||||||
infisical run --token=<> -- npm run dev
|
|
||||||
```
|
|
||||||
|
|
||||||
#### Pass via shell environment variable
|
#### Use `infisical login` to obtain a universal auth access token
|
||||||
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=<>
|
export INFISICAL_TOKEN=$(infisical login --method=universal-auth --client-id=<identity-client-id> --client-secret=<identity-client-secret> --silent --plain) # --plain flag will output only the token, so it can be fed to an environment variable. --silent will disable any update messages.
|
||||||
```
|
```
|
||||||
|
|
||||||
|
The CLI is configured to look for the `INFISICAL_TOKEN` environment variable. You can also pass the universal auth token as a `--token` flag to commands.
|
||||||
|
|
||||||
|
<Info>
|
||||||
|
Keep in mind that the universal auth token has a limited lifetime. It is recommended to use it only for the duration of the task at hand.
|
||||||
|
You can [refresh the token](./commands/token) if needed.
|
||||||
|
</Info>
|
||||||
|
|
||||||
|
#### Run commands with the universal auth token
|
||||||
|
|
||||||
|
When using universal auth it's required to pass the `--projectId` flag.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Use the token for your commands.
|
||||||
|
infisical export --projectId=<project-id>
|
||||||
|
infisical secrets --projectId=<project-id>
|
||||||
|
infisical run --projectId=<project-id> -- npm run dev
|
||||||
|
```
|
||||||
|
</Tab>
|
||||||
|
<Tab title="Service Tokens (Deprecated)">
|
||||||
|
|
||||||
|
## Service Tokens
|
||||||
|
|
||||||
|
<Warning>
|
||||||
|
Service tokens are deprecated and will be removed in the near future. Please switch to [Machine Identities](../documentation/platform/identities/machine-identities) for authenticating with Infisical.
|
||||||
|
</Warning>
|
||||||
|
|
||||||
|
To use Infisical for non local development scenarios, please create a service 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.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
infisical export --token=<service-token>
|
||||||
|
infisical secrets --token=<service-token>
|
||||||
|
infisical run --token=<service-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.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
export INFISICAL_TOKEN=<service-token>
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
</Tab>
|
||||||
|
</Tabs>
|
||||||
</Tab>
|
</Tab>
|
||||||
</Tabs>
|
</Tabs>
|
||||||
|
|
||||||
@@ -61,7 +102,7 @@ The distinguishing factor, however, is the authentication method used.
|
|||||||
<Tabs>
|
<Tabs>
|
||||||
<Tab title="Feed secrets to your application">
|
<Tab title="Feed secrets to your application">
|
||||||
```bash
|
```bash
|
||||||
infisical run --env=dev --path=/apps/firefly -- [your application start command]
|
infisical run --env=dev --path=/apps/firefly -- [your application start command] # e.g. npm run dev
|
||||||
|
|
||||||
# example with node (nodemon)
|
# example with node (nodemon)
|
||||||
infisical run --env=staging --path=/apps/spotify -- nodemon index.js
|
infisical run --env=staging --path=/apps/spotify -- nodemon index.js
|
||||||
|
|||||||
@@ -42,12 +42,26 @@ Follow the instructions for either [Helm](https://helm.sh/) or [kubectl](https:/
|
|||||||
|
|
||||||
## Usage
|
## Usage
|
||||||
|
|
||||||
**Step 1: Create Kubernetes secret containing service token**
|
<Tabs>
|
||||||
|
<Tab title="Machine Identities (Recommended)">
|
||||||
|
### Machine Identities
|
||||||
|
</Tab>
|
||||||
|
<Tab title="Service Tokens (Deprecated)">
|
||||||
|
### Service Tokens
|
||||||
|
<Warning>
|
||||||
|
Service tokens are deprecated and will be removed in the near future. Please switch to [Machine Identities](/documentation/platform/identities/machine-identities) for authenticating with Infisical.
|
||||||
|
</Warning>
|
||||||
|
|
||||||
Once you have generated the service token, create a Kubernetes secret containing the service token you generated by running the command below.
|
|
||||||
|
</Tab>
|
||||||
|
</Tabs>
|
||||||
|
|
||||||
|
**Step 1: Create Kubernetes secret containing machine identity**
|
||||||
|
|
||||||
|
Once you have created your machine identity, create a Kubernetes secret containing the machine identity you generated by running the command below.
|
||||||
|
|
||||||
``` bash
|
``` bash
|
||||||
kubectl create secret generic service-token --from-literal=infisicalToken=<your-service-token-here>
|
kubectl create secret generic universal-auth-credentials --from-literal=clientId=<your-client-id> --from-literal=clientSecret=<your-client-secret>
|
||||||
```
|
```
|
||||||
|
|
||||||
**Step 2: Fill out the InfisicalSecrets CRD and apply it to your cluster**
|
**Step 2: Fill out the InfisicalSecrets CRD and apply it to your cluster**
|
||||||
@@ -63,13 +77,16 @@ spec:
|
|||||||
hostAPI: https://app.infisical.com/api
|
hostAPI: https://app.infisical.com/api
|
||||||
resyncInterval:
|
resyncInterval:
|
||||||
authentication:
|
authentication:
|
||||||
serviceToken:
|
universalAuth:
|
||||||
serviceTokenSecretReference:
|
secretsScope:
|
||||||
secretName: service-token
|
projectSlug: <project-slug>
|
||||||
secretNamespace: option
|
envSlug: <env-slug> # "dev", "staging", "prod", etc..
|
||||||
secretsScope:
|
secretsPath: "<secrets-path>" # Root is "/"
|
||||||
envSlug: dev
|
|
||||||
secretsPath: "/"
|
credentialsRef:
|
||||||
|
secretName: universal-auth-credentials
|
||||||
|
secretNamespace: default
|
||||||
|
|
||||||
managedSecretReference:
|
managedSecretReference:
|
||||||
secretName: managed-secret # <-- the name of kubernetes secret that will be created
|
secretName: managed-secret # <-- the name of kubernetes secret that will be created
|
||||||
secretNamespace: default # <-- where the kubernetes secret should be created
|
secretNamespace: default # <-- where the kubernetes secret should be created
|
||||||
|
|||||||
@@ -23,7 +23,7 @@ This approach offers several advantages in terms of security and management:
|
|||||||
|
|
||||||
- **Scalability**: Dynamic secret management systems can scale more effectively to handle a large number of services and applications, as they automate much of the overhead associated with manual secret management.
|
- **Scalability**: Dynamic secret management systems can scale more effectively to handle a large number of services and applications, as they automate much of the overhead associated with manual secret management.
|
||||||
|
|
||||||
Dynamic secrets are particularly useful in environments with stringent security requirements, such as cloud environments, distributed systems, and microservices architectures, where they help to manage database credentials, API keys, service tokens, and other types of secrets.
|
Dynamic secrets are particularly useful in environments with stringent security requirements, such as cloud environments, distributed systems, and microservices architectures, where they help to manage database credentials, API keys, tokens, and other types of secrets.
|
||||||
|
|
||||||
## Infisical Dynamic Secret Templates
|
## Infisical Dynamic Secret Templates
|
||||||
|
|
||||||
|
|||||||
@@ -43,7 +43,23 @@ To interact with various resources in Infisical, Machine Identities are able to
|
|||||||
## FAQ
|
## FAQ
|
||||||
|
|
||||||
<AccordionGroup>
|
<AccordionGroup>
|
||||||
|
<Accordion title="How do I use Machine Identities with the CLI?">
|
||||||
|
To use Machine Identities with the CLI, you need to authenticate with the Infisical API using the identity's access token. Here's how you can do it.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
export INFISICAL_TOKEN=$(infisical login --method=universal-auth --client-id=<your-identity-client-id> --client-secret=<your-identity-client-secret> --silent --plain)
|
||||||
|
infisical secrets --env dev --projectId=<your-project-id>
|
||||||
|
```
|
||||||
|
|
||||||
|
The CLI is built to look for the `INFISICAL_TOKEN` environment variable. You can also pass the universal auth token as a `--token` flag to most commands.
|
||||||
|
</Accordion>
|
||||||
|
|
||||||
|
|
||||||
<Accordion title="What is the difference between an identity and service token?">
|
<Accordion title="What is the difference between an identity and service token?">
|
||||||
|
<Warning>
|
||||||
|
Service tokens are deprecated and will be removed in the near future. Please switch to Machine Identities for authenticating with Infisical.
|
||||||
|
</Warning>
|
||||||
|
|
||||||
A service token is a project-level authentication method that is being phased out in favor of identities.
|
A service token is a project-level authentication method that is being phased out in favor of identities.
|
||||||
|
|
||||||
Amongst many differences, identities provide broader access over the Infisical API, utilizes the same
|
Amongst many differences, identities provide broader access over the Infisical API, utilizes the same
|
||||||
|
|||||||
@@ -17,7 +17,6 @@ Upon being added to an organization and projects, users assume a certain set of
|
|||||||
|
|
||||||
To interact with various resources in Infisical, users are able to utilize a number of authentication methods:
|
To interact with various resources in Infisical, users are able to utilize a number of authentication methods:
|
||||||
- **Email & Password**: the most common authentication method that is used for authentication into Web Dashboard and Infisical CLI. It is recommended to utilize [Multi-factor Authentication](/documentation/platform/mfa) in addition to it.
|
- **Email & Password**: the most common authentication method that is used for authentication into Web Dashboard and Infisical CLI. It is recommended to utilize [Multi-factor Authentication](/documentation/platform/mfa) in addition to it.
|
||||||
- **Service Tokens**: Service tokens allow users authenticate into CLI and other clients under their own identity. For the majority of use cases, it is not a recommended approach. Instead, it is often a good idea to utilize [Machine Identities](./machine-identities) with [Universal Authentication](/documentation/platform/identities/universal-auth).
|
|
||||||
- **SSO**: Infisical natively integrates with a number of SSO identity providers like [Google](/documentation/platform/sso/google), [GitHub](/documentation/platform/sso/github), and [GitLab](/documentation/platform/sso/gitlab).
|
- **SSO**: Infisical natively integrates with a number of SSO identity providers like [Google](/documentation/platform/sso/google), [GitHub](/documentation/platform/sso/github), and [GitLab](/documentation/platform/sso/gitlab).
|
||||||
- **SAML SSO**: It is also possible to set up SAML SSO integration with identity providers like [Okta](/documentation/platform/sso/okta), [Microsoft Entra ID](/documentation/platform/sso/azure) (formerly known as Azure AD), [JumpCloud](/documentation/platform/sso/jumpcloud), [Google](/documentation/platform/sso/google-saml), and more.
|
- **SAML SSO**: It is also possible to set up SAML SSO integration with identity providers like [Okta](/documentation/platform/sso/okta), [Microsoft Entra ID](/documentation/platform/sso/azure) (formerly known as Azure AD), [JumpCloud](/documentation/platform/sso/jumpcloud), [Google](/documentation/platform/sso/google-saml), and more.
|
||||||
- **LDAP**: For organizations with more advanced needs, Infisical also provides user authentication with [LDAP](/documentation/platform/ldap/overview) that includes a number of LDAP providers.
|
- **LDAP**: For organizations with more advanced needs, Infisical also provides user authentication with [LDAP](/documentation/platform/ldap/overview) that includes a number of LDAP providers.
|
||||||
|
|||||||
@@ -1,38 +0,0 @@
|
|||||||
---
|
|
||||||
title: "IP Allowlisting"
|
|
||||||
description: "Restrict access to your secrets in Infisical using trusted IPs"
|
|
||||||
---
|
|
||||||
|
|
||||||
<Warning>
|
|
||||||
IP allowlisting at the project-level is being replaced with IP allowlisting at the token-level now available with the Service Token V3 authentication method.
|
|
||||||
|
|
||||||
Instead of providing trusted IPs (specific IPs and CIDR ranges) to be applied across all service tokens,
|
|
||||||
you can now specify trusted IPs at the token-level.
|
|
||||||
|
|
||||||
</Warning>
|
|
||||||
<Info>
|
|
||||||
Note that IP Allowlisting is a paid feature.
|
|
||||||
|
|
||||||
If you're using Infisical Cloud, then it is available under the **Pro Tier**. If you're self-hosting Infisical,
|
|
||||||
then you should contact sales@infisical.com to purchase an enterprise license to use it.
|
|
||||||
</Info>
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||

|
|
||||||
@@ -19,7 +19,7 @@ This means that updating the value of a base secret propagates directly to other
|
|||||||
|
|
||||||

|

|
||||||
|
|
||||||
Since secret referencing works by reconstructing values back on the client side, the client, be it a user or service token, fetching back secrets
|
Since secret referencing works by reconstructing values back on the client side, the client, be it a user, service token, or a machine identity, fetching back secrets
|
||||||
must be permissioned access to all base and dependent 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`.
|
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`.
|
||||||
|
|||||||
@@ -3,6 +3,10 @@ title: "Service Token"
|
|||||||
description: "Infisical service tokens allow users to programmatically interact with Infisical."
|
description: "Infisical service tokens allow users to programmatically interact with Infisical."
|
||||||
---
|
---
|
||||||
|
|
||||||
|
<Warning>
|
||||||
|
Service tokens are deprecated and will be removed in the near future. Please switch to [Machine Identities](/documentation/platform/identities/machine-identities) for authenticating with Infisical.
|
||||||
|
</Warning>
|
||||||
|
|
||||||
Service tokens are authentication credentials that services can use to access designated endpoints in the Infisical API to manage project resources like secrets.
|
Service tokens are authentication credentials that services can use to access designated endpoints in the Infisical API to manage project resources like secrets.
|
||||||
Each service token can be provisioned scoped access to select environment(s) and path(s) within them.
|
Each service token can be provisioned scoped access to select environment(s) and path(s) within them.
|
||||||
|
|
||||||
|
|||||||
|
After Width: | Height: | Size: 58 KiB |
BIN
docs/images/integrations/jenkins/jenkins_10_identity.png
Normal file
|
After Width: | Height: | Size: 268 KiB |
BIN
docs/images/integrations/jenkins/jenkins_11_identity.png
Normal file
|
After Width: | Height: | Size: 87 KiB |
BIN
docs/images/integrations/jenkins/jenkins_4_identity_id.png
Normal file
|
After Width: | Height: | Size: 184 KiB |
BIN
docs/images/integrations/jenkins/jenkins_4_identity_secret.png
Normal file
|
After Width: | Height: | Size: 186 KiB |
BIN
docs/images/integrations/jenkins/jenkins_5_identity.png
Normal file
|
After Width: | Height: | Size: 210 KiB |
BIN
docs/images/integrations/jenkins/jenkins_9_identity.png
Normal file
|
After Width: | Height: | Size: 229 KiB |
@@ -6,133 +6,274 @@ description: "How to effectively and securely manage secrets in Jenkins using In
|
|||||||
**Objective**: Fetch secrets from Infisical to Jenkins pipelines
|
**Objective**: Fetch secrets from Infisical to Jenkins pipelines
|
||||||
|
|
||||||
In this guide, we'll outline the steps to deliver secrets from Infisical to Jenkins via the Infisical CLI.
|
In this guide, we'll outline the steps to deliver secrets from Infisical to Jenkins via the Infisical CLI.
|
||||||
At a high level, the Infisical CLI will be executed within your build environment and use a service token to authenticate with Infisical.
|
At a high level, the Infisical CLI will be executed within your build environment and use a machine identity to authenticate with Infisical.
|
||||||
This token must be added as a Jenkins Credential and then passed to the Infisical CLI as an environment variable, enabling it to access and retrieve secrets within your workflows.
|
This token must be added as a Jenkins Credential and then passed to the Infisical CLI as an environment variable, enabling it to access and retrieve secrets within your workflows.
|
||||||
|
|
||||||
Prerequisites:
|
Prerequisites:
|
||||||
|
|
||||||
- Set up and add secrets to [Infisical](https://app.infisical.com).
|
- Set up and add secrets to [Infisical](https://app.infisical.com).
|
||||||
|
- Create a [machine identity](/documentation/platform/identities/machine-identities) (Recommended), or a service token in Infisical.
|
||||||
- You have a working Jenkins installation with the [credentials plugin](https://plugins.jenkins.io/credentials/) installed.
|
- You have a working Jenkins installation with the [credentials plugin](https://plugins.jenkins.io/credentials/) installed.
|
||||||
- You have the [Infisical CLI](/cli/overview) installed on your Jenkins executor nodes or container images.
|
- You have the [Infisical CLI](/cli/overview) installed on your Jenkins executor nodes or container images.
|
||||||
|
|
||||||
|
|
||||||
## Add Infisical Service Token to Jenkins
|
|
||||||
|
|
||||||
After setting up your project in Infisical and installing the Infisical CLI to the environment where your Jenkins builds will run, you will need to add the Infisical Service Token to Jenkins.
|
<Tabs>
|
||||||
|
|
||||||
To generate a Infisical service token, follow the guide [here](/documentation/platform/token).
|
<Tab title="Machine Identity (Recommended)">
|
||||||
Once you have generated the token, navigate to **Manage Jenkins > Manage Credentials** in your Jenkins instance.
|
## Add Infisical Machine Identity to Jenkins
|
||||||
|
|
||||||

|
After setting up your project in Infisical and installing the Infisical CLI to the environment where your Jenkins builds will run, you will need to add the Infisical Machine Identity to Jenkins.
|
||||||
|
|
||||||
Click on the credential store you want to store the Infisical Service Token in. In this case, we're using the default Jenkins global store.
|
To generate a Infisical machine identity, follow the guide [here](/documentation/platform/identities/machine-identities).
|
||||||
|
Once you have generated the token, navigate to **Manage Jenkins > Manage Credentials** in your Jenkins instance.
|
||||||
|
|
||||||
<Info>
|

|
||||||
Each of your projects will have a different `INFISICAL_TOKEN`.
|
|
||||||
As a result, it may make sense to spread these out into separate credential domains depending on your use case.
|
|
||||||
</Info>
|
|
||||||
|
|
||||||

|
Click on the credential store you want to store the Infisical Machine Identity in. In this case, we're using the default Jenkins global store.
|
||||||
|
|
||||||
Now, click Add Credentials.
|
<Info>
|
||||||
|
Each of your projects will have a different `INFISICAL_TOKEN`.
|
||||||
|
As a result, it may make sense to spread these out into separate credential domains depending on your use case.
|
||||||
|
</Info>
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
Choose **Secret text** for the **Kind** option from the dropdown list and enter the Infisical Service Token in the **Secret** field.
|
Now, click Add Credentials.
|
||||||
Although the **ID** can be any value, we'll set it to `infisical-service-token` for the sake of this guide.
|
|
||||||
The description is optional and can be any text you prefer.
|

|
||||||
|
|
||||||
|
Choose **Secret text** for the **Kind** option from the dropdown list and enter the Infisical Service Token in the **Secret** field.
|
||||||
|
Although the **ID** can be any value, we'll set it to `infisical-machine-identity-client-id` and `infisical-machine-identity-client-secret` for the sake of this guide.
|
||||||
|
The description is optional and can be any text you prefer.
|
||||||
|
|
||||||
|
|
||||||

|

|
||||||
|

|
||||||
|
|
||||||
When you're done, you should see a credential similar to the one below:
|
When you're done, you should see two credentials similar to the one below:
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
|
|
||||||
## Use Infisical in a Freestyle Project
|
## Use Infisical in a Freestyle Project
|
||||||
|
|
||||||
To fetch secrets with Infisical in a Freestyle Project job, you'll need to expose the credential you created above as an environment variable to the Infisical CLI.
|
To fetch secrets with Infisical in a Freestyle Project job, you'll need to expose the credential you created above as an environment variable to the Infisical CLI.
|
||||||
To do so, first click **New Item** from the dashboard navigation sidebar:
|
To do so, first click **New Item** from the dashboard navigation sidebar:
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
Enter the name of the job, choose the **Freestyle Project** option, and click **OK**.
|
Enter the name of the job, choose the **Freestyle Project** option, and click **OK**.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
Scroll down to the **Build Environment** section and enable the **Use secret text(s) or file(s)** option. Then click **Add** under the **Bindings** section and choose **Secret text** from the dropdown menu.
|
Scroll down to the **Build Environment** section and enable the **Use secret text(s) or file(s)** option. Then click **Add** under the **Bindings** section and choose **Secret text** from the dropdown menu.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
Enter `INFISICAL_TOKEN` in the **Variable** field then click the **Specific credentials** option from the Credentials section and select the credential you created earlier.
|
Enter `INFISICAL_MACHINE_IDENTITY_CLIENT_ID` in the **Variable** field for the client ID, and `INFISICAL_MACHINE_IDENTITY_CLIENT_SECRET` for the client secret. Then click the **Specific credentials** option from the Credentials section and select the credentials you created earlier.
|
||||||
In this case, we saved it as `Infisical service token` so we'll choose that from the dropdown menu.
|
In this case, we saved it as `Infisical Machine Identity Client ID` and `Infisical Machine Identity Client Secret` so we'll choose those from the dropdown menu.
|
||||||
|
|
||||||

|
Make sure to add bindings for both the client ID and the client secret.
|
||||||
|
|
||||||
Scroll down to the **Build** section and choose **Execute shell** from the **Add build step** menu.
|

|
||||||
|
|
||||||

|
Scroll down to the **Build** section and choose **Execute shell** from the **Add build step** menu.
|
||||||
|
|
||||||
In the command field, you can now use the Infisical CLI to fetch secrets.
|

|
||||||
The example command below will print the secrets using the service token passed as a credential. When done, click **Save**.
|
|
||||||
|
|
||||||
```
|
In the command field, you can now use the Infisical CLI to fetch secrets.
|
||||||
infisical secrets --env=dev --path=/
|
The example command below will print the secrets using the service token passed as a credential. When done, click **Save**.
|
||||||
```
|
|
||||||
|
|
||||||

|
```bash
|
||||||
|
export INFISICAL_TOKEN=$(infisical login --method=universal-auth --client-id=$INFISICAL_MACHINE_IDENTITY_CLIENT_ID --client-secret=$INFISICAL_MACHINE_IDENTITY_CLIENT_SECRET --silent --plain)
|
||||||
|
infisical secrets --env dev --projectId=<your-project-id>
|
||||||
|
```
|
||||||
|
|
||||||
Finally, click **Build Now** from the navigation sidebar to run your new job.
|

|
||||||
|
|
||||||
<Info>
|
Finally, click **Build Now** from the navigation sidebar to run your new job.
|
||||||
Running into issues? Join Infisical's [community Slack](https://infisical.com/slack) for quick support.
|
|
||||||
</Info>
|
<Info>
|
||||||
|
Running into issues? Join Infisical's [community Slack](https://infisical.com/slack) for quick support.
|
||||||
|
</Info>
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## Use Infisical in a Jenkins Pipeline
|
## Use Infisical in a Jenkins Pipeline
|
||||||
|
|
||||||
To fetch secrets using Infisical in a Pipeline job, you'll need to expose the Jenkins credential you created above as an environment variable.
|
To fetch secrets using Infisical in a Pipeline job, you'll need to expose the Jenkins credential you created above as an environment variable.
|
||||||
To do so, click **New Item** from the dashboard navigation sidebar:
|
To do so, click **New Item** from the dashboard navigation sidebar:
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
Enter the name of the job, choose the **Pipeline** option, and click OK.
|
Enter the name of the job, choose the **Pipeline** option, and click OK.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
Scroll down to the **Pipeline** section, paste the following into the **Script** field, and click **Save**.
|
Scroll down to the **Pipeline** section, paste the following into the **Script** field, and click **Save**.
|
||||||
|
|
||||||
```
|
```
|
||||||
pipeline {
|
pipeline {
|
||||||
agent any
|
agent any
|
||||||
|
|
||||||
environment {
|
environment {
|
||||||
INFISICAL_TOKEN = credentials('infisical-service-token')
|
MACHINE_IDENTITY_CLIENT_ID = credentials('infisical-machine-identity-client-id')
|
||||||
}
|
MACHINE_IDENTITY_CLIENT_SECRET = credentials('infisical-machine-identity-client-secret')
|
||||||
|
|
||||||
stages {
|
}
|
||||||
stage('Run Infisical') {
|
|
||||||
steps {
|
|
||||||
sh("infisical secrets --env=dev --path=/")
|
|
||||||
|
|
||||||
// doesn't work
|
stages {
|
||||||
// sh("docker run --rm test-container infisical secrets")
|
stage('Run Infisical') {
|
||||||
|
steps {
|
||||||
|
sh("export INFISICAL_TOKEN=$(infisical login --method=universal-auth --client-id=${MACHINE_IDENTITY_CLIENT_ID} --client-secret=${MACHINE_IDENTITY_CLIENT_SECRET} --silent --plain)")
|
||||||
|
sh("infisical secrets --env=dev --path=/ --projectId=<your-project-id>")
|
||||||
|
|
||||||
// works
|
// doesn't work
|
||||||
// sh("docker run -e INFISICAL_TOKEN=${INFISICAL_TOKEN} --rm test-container infisical secrets --env=dev --path=/")
|
// sh("docker run --rm test-container infisical secrets --projectId=<your-project-id>")
|
||||||
|
|
||||||
// doesn't work
|
// works
|
||||||
// sh("docker-compose up -d")
|
// sh("docker run -e INFISICAL_TOKEN=${INFISICAL_TOKEN} --rm test-container infisical secrets --env=dev --path=/ --projectId=<your-project-id>")
|
||||||
|
|
||||||
// works
|
// doesn't work
|
||||||
// sh("INFISICAL_TOKEN=${INFISICAL_TOKEN} docker-compose up -d")
|
// sh("docker-compose up -d")
|
||||||
|
|
||||||
|
// works
|
||||||
|
// sh("INFISICAL_TOKEN=${INFISICAL_TOKEN} docker-compose up -d")
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
</Tab>
|
||||||
|
|
||||||
|
<Tab title="Service Token (Deprecated)">
|
||||||
|
## Add Infisical Service Token to Jenkins
|
||||||
|
|
||||||
|
<Warning>
|
||||||
|
Service tokens are deprecated and will be removed in the future.
|
||||||
|
Please use machine identity authentication instead.
|
||||||
|
</Warning>
|
||||||
|
|
||||||
|
After setting up your project in Infisical and installing the Infisical CLI to the environment where your Jenkins builds will run, you will need to add the Infisical Service Token to Jenkins.
|
||||||
|
|
||||||
|
To generate a Infisical service token, follow the guide [here](/documentation/platform/token).
|
||||||
|
Once you have generated the token, navigate to **Manage Jenkins > Manage Credentials** in your Jenkins instance.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Click on the credential store you want to store the Infisical Service Token in. In this case, we're using the default Jenkins global store.
|
||||||
|
|
||||||
|
<Info>
|
||||||
|
Each of your projects will have a different `INFISICAL_TOKEN`.
|
||||||
|
As a result, it may make sense to spread these out into separate credential domains depending on your use case.
|
||||||
|
</Info>
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Now, click Add Credentials.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Choose **Secret text** for the **Kind** option from the dropdown list and enter the Infisical Service Token in the **Secret** field.
|
||||||
|
Although the **ID** can be any value, we'll set it to `infisical-service-token` for the sake of this guide.
|
||||||
|
The description is optional and can be any text you prefer.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
When you're done, you should see a credential similar to the one below:
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
|
||||||
|
## Use Infisical in a Freestyle Project
|
||||||
|
|
||||||
|
To fetch secrets with Infisical in a Freestyle Project job, you'll need to expose the credential you created above as an environment variable to the Infisical CLI.
|
||||||
|
To do so, first click **New Item** from the dashboard navigation sidebar:
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Enter the name of the job, choose the **Freestyle Project** option, and click **OK**.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Scroll down to the **Build Environment** section and enable the **Use secret text(s) or file(s)** option. Then click **Add** under the **Bindings** section and choose **Secret text** from the dropdown menu.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Enter `INFISICAL_TOKEN` in the **Variable** field then click the **Specific credentials** option from the Credentials section and select the credential you created earlier.
|
||||||
|
In this case, we saved it as `Infisical service token` so we'll choose that from the dropdown menu.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Scroll down to the **Build** section and choose **Execute shell** from the **Add build step** menu.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
In the command field, you can now use the Infisical CLI to fetch secrets.
|
||||||
|
The example command below will print the secrets using the service token passed as a credential. When done, click **Save**.
|
||||||
|
|
||||||
|
```
|
||||||
|
infisical secrets --env=dev --path=/
|
||||||
|
```
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Finally, click **Build Now** from the navigation sidebar to run your new job.
|
||||||
|
|
||||||
|
<Info>
|
||||||
|
Running into issues? Join Infisical's [community Slack](https://infisical.com/slack) for quick support.
|
||||||
|
</Info>
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## Use Infisical in a Jenkins Pipeline
|
||||||
|
|
||||||
|
To fetch secrets using Infisical in a Pipeline job, you'll need to expose the Jenkins credential you created above as an environment variable.
|
||||||
|
To do so, click **New Item** from the dashboard navigation sidebar:
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Enter the name of the job, choose the **Pipeline** option, and click OK.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Scroll down to the **Pipeline** section, paste the following into the **Script** field, and click **Save**.
|
||||||
|
|
||||||
|
```
|
||||||
|
pipeline {
|
||||||
|
agent any
|
||||||
|
|
||||||
|
environment {
|
||||||
|
INFISICAL_TOKEN = credentials('infisical-service-token')
|
||||||
|
}
|
||||||
|
|
||||||
|
stages {
|
||||||
|
stage('Run Infisical') {
|
||||||
|
steps {
|
||||||
|
sh("infisical secrets --env=dev --path=/")
|
||||||
|
|
||||||
|
// doesn't work
|
||||||
|
// sh("docker run --rm test-container infisical secrets")
|
||||||
|
|
||||||
|
// works
|
||||||
|
// sh("docker run -e INFISICAL_TOKEN=${INFISICAL_TOKEN} --rm test-container infisical secrets --env=dev --path=/")
|
||||||
|
|
||||||
|
// doesn't work
|
||||||
|
// sh("docker-compose up -d")
|
||||||
|
|
||||||
|
// works
|
||||||
|
// sh("INFISICAL_TOKEN=${INFISICAL_TOKEN} docker-compose up -d")
|
||||||
|
}
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
}
|
```
|
||||||
```
|
</Tab>
|
||||||
|
|
||||||
|
</Tabs>
|
||||||
|
|
||||||
|
|
||||||
The example provided above serves as an initial guide. It shows how Jenkins adds the `INFISICAL_TOKEN` environment variable, which is configured in the pipeline, into the shell for executing commands.
|
The example provided above serves as an initial guide. It shows how Jenkins adds the `INFISICAL_TOKEN` environment variable, which is configured in the pipeline, into the shell for executing commands.
|
||||||
There may be instances where this doesn't work as expected in the context of running Docker commands.
|
There may be instances where this doesn't work as expected in the context of running Docker commands.
|
||||||
|
|||||||
@@ -13,63 +13,120 @@ There are many approaches to sync secrets stored within Infisical to AWS Amplify
|
|||||||
|
|
||||||
This approach enables you to fetch secrets from Infisical during Amplify build time.
|
This approach enables you to fetch secrets from Infisical during Amplify build time.
|
||||||
|
|
||||||
<Steps>
|
<Tabs>
|
||||||
<Step title="Generate a service token">
|
|
||||||
Go to your project settings in the Infisical dashboard to generate a [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 provide the token to the CLI installed in your Docker container.
|
|
||||||
</Step>
|
|
||||||
<Step title="Set the service token as an Amplify environment variable">
|
|
||||||

|
|
||||||
1. In the Amplify console, choose App Settings, and then select Environment variables.
|
|
||||||
2. In the Environment variables section, select Manage variables.
|
|
||||||
3. Under Variable, enter the key **INFISICAL_TOKEN**. For the value, enter the generated service token from the previous step.
|
|
||||||
4. Click save.
|
|
||||||
</Step>
|
|
||||||
<Step title="Install Infisical CLI to the Amplify build step">
|
|
||||||
In the prebuild phase, add the command in AWS Amplify to install the Infisical CLI.
|
|
||||||
|
|
||||||
```yaml
|
<Tab title="Machine Identity (Recommended)">
|
||||||
build:
|
<Steps>
|
||||||
phases:
|
<Step title="Create a machine identity">
|
||||||
preBuild:
|
Create a machine identtiy and connect it to your Infisical project. You can read more about how to use machine identities [here](/documentation/platform/identities/machine-identities). The machine identity will allow you to authenticate and fetch secrets from Infisical.
|
||||||
commands:
|
</Step>
|
||||||
- sudo curl -1sLf 'https://dl.cloudsmith.io/public/infisical/infisical-cli/setup.rpm.sh' | sudo -E bash
|
|
||||||
- sudo yum -y install infisical
|
|
||||||
```
|
|
||||||
</Step>
|
|
||||||
<Step title="Modify the build command">
|
|
||||||
You can now pull secrets from Infisical using the CLI and save them as a `.env` file. To do this, modify the build commands.
|
|
||||||
|
|
||||||
```yaml
|
<Step title="Set the machine identity client ID and client secret as Amplify environment variables">
|
||||||
build:
|

|
||||||
phases:
|
1. In the Amplify console, choose App Settings, and then select Environment variables.
|
||||||
|
2. In the Environment variables section, select Manage variables.
|
||||||
|
3. Under the first Variable enter `INFISICAL_MACHINE_IDENTITY_CLIENT_ID`, and for the value, enter the client ID of the machine identity you created in the previous step.
|
||||||
|
4. Under the second Variable enter `INFISICAL_MACHINE_IDENTITY_CLIENT_SECRET`, and for the value, enter the client secret of the machine identity you created in the previous step.
|
||||||
|
5. Click save.
|
||||||
|
</Step>
|
||||||
|
|
||||||
|
<Step title="Install Infisical CLI to the Amplify build step">
|
||||||
|
In the prebuild phase, add the command in AWS Amplify to install the Infisical CLI.
|
||||||
|
|
||||||
|
```yaml
|
||||||
build:
|
build:
|
||||||
commands:
|
phases:
|
||||||
- INFISICAL_TOKEN=${INFISICAL_TOKEN}
|
preBuild:
|
||||||
- infisical export --format=dotenv > .env
|
commands:
|
||||||
- <rest of the commands>
|
- sudo curl -1sLf 'https://dl.cloudsmith.io/public/infisical/infisical-cli/setup.rpm.sh' | sudo -E bash
|
||||||
```
|
- sudo yum -y install infisical
|
||||||
</Step>
|
```
|
||||||
</Steps>
|
</Step>
|
||||||
|
|
||||||
## Sync Secrets Using AWS SSM Parameter Store
|
<Step title="Modify the build command">
|
||||||
|
You can now pull secrets from Infisical using the CLI and save them as a `.env` file. To do this, modify the build commands.
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
build:
|
||||||
|
phases:
|
||||||
|
build:
|
||||||
|
commands:
|
||||||
|
- INFISICAL_TOKEN=$(infisical login --method=universal-auth --client-id=${INFISICAL_MACHINE_IDENTITY_CLIENT_ID} --client-secret=${INFISICAL_MACHINE_IDENTITY_CLIENT_SECRET} --silent --plain)
|
||||||
|
- infisical export --format=dotenv > .env
|
||||||
|
- <rest of the commands>
|
||||||
|
```
|
||||||
|
</Step>
|
||||||
|
</Steps>
|
||||||
|
|
||||||
|
</Tab>
|
||||||
|
|
||||||
|
<Tab title="Service Token (Deprecated)">
|
||||||
|
|
||||||
|
<Warning>
|
||||||
|
The service token approach is deprecated and will be removed in the future. Please use the machine identity approach instead.
|
||||||
|
</Warning>
|
||||||
|
|
||||||
|
<Steps>
|
||||||
|
<Step title="Generate a service token">
|
||||||
|
Go to your project settings in the Infisical dashboard to generate a [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 provide the token to the CLI installed in your Docker container.
|
||||||
|
</Step>
|
||||||
|
<Step title="Set the service token as an Amplify environment variable">
|
||||||
|

|
||||||
|
1. In the Amplify console, choose App Settings, and then select Environment variables.
|
||||||
|
2. In the Environment variables section, select Manage variables.
|
||||||
|
3. Under Variable, enter the key **INFISICAL_TOKEN**. For the value, enter the generated service token from the previous step.
|
||||||
|
4. Click save.
|
||||||
|
</Step>
|
||||||
|
<Step title="Install Infisical CLI to the Amplify build step">
|
||||||
|
In the prebuild phase, add the command in AWS Amplify to install the Infisical CLI.
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
build:
|
||||||
|
phases:
|
||||||
|
preBuild:
|
||||||
|
commands:
|
||||||
|
- sudo curl -1sLf 'https://dl.cloudsmith.io/public/infisical/infisical-cli/setup.rpm.sh' | sudo -E bash
|
||||||
|
- sudo yum -y install infisical
|
||||||
|
```
|
||||||
|
</Step>
|
||||||
|
<Step title="Modify the build command">
|
||||||
|
You can now pull secrets from Infisical using the CLI and save them as a `.env` file. To do this, modify the build commands.
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
build:
|
||||||
|
phases:
|
||||||
|
build:
|
||||||
|
commands:
|
||||||
|
- INFISICAL_TOKEN=${INFISICAL_TOKEN}
|
||||||
|
- infisical export --format=dotenv > .env
|
||||||
|
- <rest of the commands>
|
||||||
|
```
|
||||||
|
</Step>
|
||||||
|
</Steps>
|
||||||
|
|
||||||
|
## Sync Secrets Using AWS SSM Parameter Store
|
||||||
|
|
||||||
|
Another approach to use secrets from Infisical in AWS Amplify is to utilize AWS Parameter Store.
|
||||||
|
At high level, you begin by using Infisical's AWS SSM Parameter Store integration to sync secrets from Infisical to AWS SSM Parameter Store. You then instruct AWS Amplify to consume those secrets from AWS SSM Parameter Store as [environment secrets](https://docs.aws.amazon.com/amplify/latest/userguide/environment-variables.html#environment-secrets).
|
||||||
|
|
||||||
|
<Steps>
|
||||||
|
<Step title="Follow the AWS SSM Parameter Store Integration guide">
|
||||||
|
Follow the [Infisical AWS SSM Parameter Store Integration Guide](./aws-parameter-store) to set up the integration. Pause once you reach the step where it asks you to select the path you would like to sync.
|
||||||
|
</Step>
|
||||||
|
<Step title="Find your Amplify App ID">
|
||||||
|

|
||||||
|
1. Open your AWS Amplify App console.
|
||||||
|
2. Go to **Actions >> View App Settings**
|
||||||
|
3. The App ID will be the last part of the App ARN field after the slash.
|
||||||
|
</Step>
|
||||||
|
<Step title="Set AWS SSM Parameter Store path">
|
||||||
|
You need to set the path in the format `/amplify/[amplify_app_id]/[your-amplify-environment-name]` as the path option in AWS SSM Parameter Infisical Integration.
|
||||||
|
</Step>
|
||||||
|
</Steps>
|
||||||
|
</Tab>
|
||||||
|
</Tabs>
|
||||||
|
|
||||||
Another approach to use secrets from Infisical in AWS Amplify is to utilize AWS Parameter Store.
|
|
||||||
At high level, you begin by using Infisical's AWS SSM Parameter Store integration to sync secrets from Infisical to AWS SSM Parameter Store. You then instruct AWS Amplify to consume those secrets from AWS SSM Parameter Store as [environment secrets](https://docs.aws.amazon.com/amplify/latest/userguide/environment-variables.html#environment-secrets).
|
|
||||||
|
|
||||||
<Steps>
|
|
||||||
<Step title="Follow the AWS SSM Parameter Store Integration guide">
|
|
||||||
Follow the [Infisical AWS SSM Parameter Store Integration Guide](./aws-parameter-store) to set up the integration. Pause once you reach the step where it asks you to select the path you would like to sync.
|
|
||||||
</Step>
|
|
||||||
<Step title="Find your Amplify App ID">
|
|
||||||

|
|
||||||
1. Open your AWS Amplify App console.
|
|
||||||
2. Go to **Actions >> View App Settings**
|
|
||||||
3. The App ID will be the last part of the App ARN field after the slash.
|
|
||||||
</Step>
|
|
||||||
<Step title="Set AWS SSM Parameter Store path">
|
|
||||||
You need to set the path in the format `/amplify/[amplify_app_id]/[your-amplify-environment-name]` as the path option in AWS SSM Parameter Infisical Integration.
|
|
||||||
</Step>
|
|
||||||
</Steps>
|
|
||||||
|
|
||||||
<Info>
|
<Info>
|
||||||
Accessing an environment secret during a build is similar to accessing environment variables, except that environment secrets are stored in `process.env.secrets` as a JSON string.
|
Accessing an environment secret during a build is similar to accessing environment variables, except that environment secrets are stored in `process.env.secrets` as a JSON string.
|
||||||
|
|||||||
@@ -34,7 +34,9 @@ Set up the Infisical provider by specifying the `host` and `service_token`. Repl
|
|||||||
```hcl main.tf
|
```hcl main.tf
|
||||||
provider "infisical" {
|
provider "infisical" {
|
||||||
host = "https://app.infisical.com" # Only required if using self hosted instance of Infisical, default is https://app.infisical.com
|
host = "https://app.infisical.com" # Only required if using self hosted instance of Infisical, default is https://app.infisical.com
|
||||||
service_token = "<>" # Get token https://infisical.com/docs/documentation/platform/token
|
client_id = "<>"
|
||||||
|
client_secret = "<>"
|
||||||
|
service_token = "<>" # DEPRECATED, USE MACHINE IDENTITY AUTH INSTEAD
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
@@ -54,6 +56,7 @@ Use the `infisical_secrets` data source to fetch your secrets. In this block, yo
|
|||||||
data "infisical_secrets" "my-secrets" {
|
data "infisical_secrets" "my-secrets" {
|
||||||
env_slug = "dev"
|
env_slug = "dev"
|
||||||
folder_path = "/some-folder/another-folder"
|
folder_path = "/some-folder/another-folder"
|
||||||
|
workspace_id = "your-project-id"
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|||||||
@@ -8,49 +8,106 @@ Prerequisites:
|
|||||||
- Set up and add envars to [Infisical Cloud](https://app.infisical.com)
|
- Set up and add envars to [Infisical Cloud](https://app.infisical.com)
|
||||||
|
|
||||||
## Configure the Infisical CLI for each service
|
## Configure the Infisical CLI for each service
|
||||||
|
|
||||||
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.
|
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 service token
|
<Tabs>
|
||||||
|
<Tab title="Machine Identity (Recommended)">
|
||||||
|
### Generate and configure machine identity
|
||||||
|
Generate a machine identity for each service you want to inject secrets into. You can do this by following the steps in the [Machine Identity](/documentation/platform/identities/machine-identities) guide.
|
||||||
|
|
||||||
Generate a unique [Infisical Token](/documentation/platform/token) for each service.
|
### Set the machine identity client ID and client secret as environment variables
|
||||||
|
For each service you want to inject secrets into, set two environment variable called `INFISICAL_MACHINE_IDENTITY_CLIENT_ID`, and `INFISICAL_MACHINE_IDENTITY_CLIENT_SECRET` equal to the client ID and client secret of the machine identity(s) you created in the previous step.
|
||||||
|
|
||||||
## Feed service token to your Docker Compose file
|
In the example below, we set two sets of client ID and client secret for the services.
|
||||||
|
|
||||||
For each service you want to inject secrets into, set an environment variable called `INFISICAL_TOKEN` equal to a unique identifier variable.
|
For the web service we set `INFISICAL_MACHINE_IDENTITY_CLIENT_ID_FOR_WEB` and `INFISICAL_MACHINE_IDENTITY_CLIENT_SECRET_FOR_WEB` as the client ID and client secret respectively.
|
||||||
|
|
||||||
In the example below, we set `INFISICAL_TOKEN_FOR_WEB` and `INFISICAL_TOKEN_FOR_API` as the `INFISICAL_TOKEN` for the services.
|
For the API service we set `INFISICAL_MACHINE_IDENTITY_CLIENT_ID_FOR_API` and `INFISICAL_MACHINE_IDENTITY_CLIENT_SECRET_FOR_API` as the client ID and client secret respectively.
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
# Example Docker Compose file
|
# Example Docker Compose file
|
||||||
services:
|
services:
|
||||||
web:
|
web:
|
||||||
build: .
|
build: .
|
||||||
image: example-service-1
|
image: example-service-1
|
||||||
environment:
|
environment:
|
||||||
- INFISICAL_TOKEN=${INFISICAL_TOKEN_FOR_WEB}
|
- INFISICAL_MACHINE_IDENTITY_CLIENT_ID=${INFISICAL_MACHINE_IDENTITY_CLIENT_ID_FOR_WEB}
|
||||||
|
- INFISICAL_MACHINE_IDENTITY_CLIENT_SECRET=${INFISICAL_MACHINE_IDENTITY_CLIENT_SECRET_FOR_WEB}
|
||||||
|
|
||||||
api:
|
api:
|
||||||
build: .
|
build: .
|
||||||
image: example-service-2
|
image: example-service-2
|
||||||
environment:
|
environment:
|
||||||
- INFISICAL_TOKEN=${INFISICAL_TOKEN_FOR_API}
|
- INFISICAL_MACHINE_IDENTITY_CLIENT_ID=${INFISICAL_MACHINE_IDENTITY_CLIENT_ID_FOR_API}
|
||||||
```
|
- INFISICAL_MACHINE_IDENTITY_CLIENT_SECRET=${INFISICAL_MACHINE_IDENTITY_CLIENT_SECRET_FOR_API}
|
||||||
|
|
||||||
## Export shell variables
|
```
|
||||||
|
|
||||||
Next, set the shell variables you defined in your compose file. This can be done manually or via your CI/CD environment. Once done, it will be used to populate the corresponding `INFISICAL_TOKEN`
|
### Export shell variables
|
||||||
in your Docker Compose file.
|
Next, set the shell variables you defined in your compose file. This can be done manually or via your CI/CD environment. Once done, it will be used to populate the corresponding `INFISICAL_MACHINE_IDENTITY_CLIENT_ID` and `INFISICAL_MACHINE_IDENTITY_CLIENT_SECRET` in your Docker Compose file.
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
#Example
|
#Example
|
||||||
|
|
||||||
# Token refers to the token we generated in step 2 for this service
|
# Token refers to the token we generated in step 2 for this service
|
||||||
export INFISICAL_TOKEN_FOR_WEB=<token>
|
export INFISICAL_MACHINE_IDENTITY_CLIENT_ID_FOR_WEB=<client_id>
|
||||||
|
export INFISICAL_MACHINE_IDENTITY_CLIENT_SECRET_FOR_WEB=<client_secret>
|
||||||
|
|
||||||
# Token refers to the token we generated in step 2 for this service
|
# Token refers to the token we generated in step 2 for this service
|
||||||
export INFISICAL_TOKEN_FOR_API=<token>
|
export INFISICAL_MACHINE_IDENTITY_CLIENT_ID_FOR_API=<client_id>
|
||||||
|
export INFISICAL_MACHINE_IDENTITY_CLIENT_SECRET_FOR_API=<client_secret>
|
||||||
|
|
||||||
# Then run your compose file in the same terminal.
|
# Then run your compose file in the same terminal.
|
||||||
docker-compose ...
|
docker-compose ...
|
||||||
```
|
```
|
||||||
|
</Tab>
|
||||||
|
<Tab title="Service Token (Deprecated)">
|
||||||
|
|
||||||
|
<Warning>
|
||||||
|
The service token approach is deprecated and will be removed in the future. Please use the machine identity approach instead.
|
||||||
|
</Warning>
|
||||||
|
|
||||||
|
## Generate service token
|
||||||
|
Generate a unique [Service Token](/documentation/platform/token) for each service.
|
||||||
|
|
||||||
|
## 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.
|
||||||
|
|
||||||
|
In the example below, we set `INFISICAL_TOKEN_FOR_WEB` and `INFISICAL_TOKEN_FOR_API` as the `INFISICAL_TOKEN` for the services.
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
# Example Docker Compose file
|
||||||
|
services:
|
||||||
|
web:
|
||||||
|
build: .
|
||||||
|
image: example-service-1
|
||||||
|
environment:
|
||||||
|
- INFISICAL_TOKEN=${INFISICAL_TOKEN_FOR_WEB}
|
||||||
|
|
||||||
|
api:
|
||||||
|
build: .
|
||||||
|
image: example-service-2
|
||||||
|
environment:
|
||||||
|
- INFISICAL_TOKEN=${INFISICAL_TOKEN_FOR_API}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Export shell variables
|
||||||
|
|
||||||
|
Next, set the shell variables you defined in your compose file. This can be done manually or via your CI/CD environment. Once done, it will be used to populate the corresponding `INFISICAL_TOKEN`
|
||||||
|
in your Docker Compose file.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
#Example
|
||||||
|
|
||||||
|
# Token refers to the token we generated in step 2 for this service
|
||||||
|
export INFISICAL_TOKEN_FOR_WEB=<token>
|
||||||
|
|
||||||
|
# Token refers to the token we generated in step 2 for this service
|
||||||
|
export INFISICAL_TOKEN_FOR_API=<token>
|
||||||
|
|
||||||
|
# Then run your compose file in the same terminal.
|
||||||
|
docker-compose ...
|
||||||
|
```
|
||||||
|
</Tab>
|
||||||
|
</Tabs>
|
||||||
|
|||||||
@@ -10,8 +10,11 @@ For this method to function as expected, you must have a bash shell (for process
|
|||||||
|
|
||||||
## 1. Authentication
|
## 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.
|
If you are already logged in via the CLI you can skip this step. Otherwise, head to your organization settings in Infisical Cloud to create a [Machine Identity](../../documentation/platform/identities/machine-identities). The machine identity 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.
|
Once you have created a machine identity with the required permissions, you'll need to feed the token to the CLI.
|
||||||
|
<Info>
|
||||||
|
Please note that we highly recommend using `infisical login` for local development.
|
||||||
|
</Info>
|
||||||
|
|
||||||
#### Pass as flag
|
#### Pass as flag
|
||||||
You may use the --token flag to set the token
|
You may use the --token flag to set the token
|
||||||
@@ -27,8 +30,14 @@ The CLI is configured to look for an environment variable named `INFISICAL_TOKEN
|
|||||||
export INFISICAL_TOKEN=<>
|
export INFISICAL_TOKEN=<>
|
||||||
```
|
```
|
||||||
|
|
||||||
|
You can use the `infisical login --method=universal-auth` command to directly obtain a universal auth access token and set it as an environment variable.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
export INFISICAL_TOKEN=$(infisical login --method=universal-auth --client-id=<your-client-id> --client-secret=<your-client-secret> --silent --plain)
|
||||||
|
```
|
||||||
|
|
||||||
<Warning>
|
<Warning>
|
||||||
In production scenarios, please to avoid using the `infisical login` command and instead use a [service token](/documentation/platform/token).
|
In production scenarios, please to avoid using the `infisical login` command and instead use a [machine identity](../../documentation/platform/identities/machine-identities).
|
||||||
</Warning>
|
</Warning>
|
||||||
|
|
||||||
## 2. Run your docker command with Infisical
|
## 2. Run your docker command with Infisical
|
||||||
|
|||||||
@@ -37,31 +37,78 @@ This is achieved by installing the Infisical CLI into your docker image and modi
|
|||||||
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/)
|
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>
|
</Tip>
|
||||||
|
|
||||||
|
|
||||||
## Modify the start command in your Dockerfile
|
## Modify the start command in your Dockerfile
|
||||||
|
|
||||||
Starting your service with the Infisical CLI pulls your secrets from Infisical and injects them into your service.
|
Starting your service with the Infisical CLI pulls your secrets from Infisical and injects them into your service.
|
||||||
|
<Tabs>
|
||||||
|
<Tab title="Machine Identity (Recommended)">
|
||||||
|
```dockerfile
|
||||||
|
CMD ["infisical", "run", "--projectId", "<your-project-id>", "--", "[your service start command]"]
|
||||||
|
|
||||||
```dockerfile
|
# example with single single command
|
||||||
CMD ["infisical", "run", "--", "[your service start command]"]
|
CMD ["infisical", "run", "--projectId", "<your-project-id>", "--", "npm", "run", "start"]
|
||||||
|
|
||||||
# example with single single command
|
# example with multiple commands
|
||||||
CMD ["infisical", "run", "--", "npm", "run", "start"]
|
CMD ["infisical", "run", "--projectId", "<your-project-id>", "--command", "npm run start && ..."]
|
||||||
|
```
|
||||||
|
|
||||||
# example with multiple commands
|
<Steps>
|
||||||
CMD ["infisical", "run", "--command", "npm run start && ..."]
|
<Step title="Generate a machine identity">
|
||||||
```
|
Generate a machine identity for your project by following the steps in the [Machine Identity](/documentation/platform/identities/machine-identities) guide. The machine identity will allow you to authenticate and fetch secrets from Infisical.
|
||||||
|
</Step>
|
||||||
|
<Step title="Obtain an access token for the machine identity">
|
||||||
|
Obtain an access token for the machine identity by running the following command:
|
||||||
|
```bash
|
||||||
|
export INFISICAL_TOKEN=$(infisical login --method=universal-auth --client-id=<your-client-id> --client-secret=<your-client-secret> --plain --silent)
|
||||||
|
```
|
||||||
|
|
||||||
## Generate a service token
|
<Info>
|
||||||
|
Please note that the access token has a limited lifespan. The `infisical token renew` command can be used to renew the token if needed.
|
||||||
|
</Info>
|
||||||
|
</Step>
|
||||||
|
<Step title="Feed the access token to the docker container">
|
||||||
|
The last step is to give the Infisical CLI installed in your Docker container access to the access token. This will allow the CLI to fetch and inject the secrets into your application.
|
||||||
|
|
||||||
Head to your project settings in the Infisical dashboard to generate an [service token](/documentation/platform/token).
|
To feed the access token to the container, use the INFISICAL_TOKEN environment variable as shown below.
|
||||||
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 service token to docker container
|
```bash
|
||||||
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.
|
docker run --env INFISICAL_TOKEN=$INFISICAL_TOKEN [DOCKER-IMAGE]...
|
||||||
|
```
|
||||||
|
</Step>
|
||||||
|
</Steps>
|
||||||
|
|
||||||
|
</Tab>
|
||||||
|
<Tab title="Service Token (Deprecated)">
|
||||||
|
<Warning>
|
||||||
|
The service token approach is deprecated and will be removed in the future. Please use the machine identity approach instead.
|
||||||
|
</Warning>
|
||||||
|
```dockerfile
|
||||||
|
CMD ["infisical", "run", "--", "[your service start command]"]
|
||||||
|
|
||||||
|
# example with single single command
|
||||||
|
CMD ["infisical", "run", "--", "npm", "run", "start"]
|
||||||
|
|
||||||
|
# example with multiple commands
|
||||||
|
CMD ["infisical", "run", "--command", "npm run start && ..."]
|
||||||
|
```
|
||||||
|
|
||||||
|
<Steps>
|
||||||
|
<Step title="Generate a service 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.
|
||||||
|
</Step>
|
||||||
|
<Step title="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]...
|
||||||
|
```
|
||||||
|
</Step>
|
||||||
|
</Steps>
|
||||||
|
</Tab>
|
||||||
|
</Tabs>
|
||||||
|
|
||||||
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]...
|
|
||||||
```
|
|
||||||
|
|||||||
@@ -81,6 +81,9 @@ spec:
|
|||||||
secretName: universal-auth-credentials
|
secretName: universal-auth-credentials
|
||||||
secretNamespace: default
|
secretNamespace: default
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
# Service tokens are deprecated and will be removed in the near future. Please use Machine Identities for authenticating with Infisical.
|
||||||
serviceToken:
|
serviceToken:
|
||||||
serviceTokenSecretReference:
|
serviceTokenSecretReference:
|
||||||
secretName: service-token
|
secretName: service-token
|
||||||
@@ -174,6 +177,10 @@ Default re-sync interval is every 1 minute.
|
|||||||
</Accordion>
|
</Accordion>
|
||||||
|
|
||||||
<Accordion title="authentication.serviceToken">
|
<Accordion title="authentication.serviceToken">
|
||||||
|
<Warning>
|
||||||
|
Service tokens are deprecated and will be removed in the near future. Please use Machine Identities (Universal Auth) for authenticating with Infisical.
|
||||||
|
</Warning>
|
||||||
|
|
||||||
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 namespace of secret that stores this service token.
|
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 namespace 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.
|
Follow the instructions below to create and store the service token in a Kubernetes secrets and reference it in your CRD.
|
||||||
|
|
||||||
|
|||||||
@@ -32,6 +32,6 @@ This section covers the internals of Infisical including its technical underpinn
|
|||||||
icon="ticket"
|
icon="ticket"
|
||||||
color="#000000"
|
color="#000000"
|
||||||
>
|
>
|
||||||
Learn best practices for utilizing Infisical service tokens.
|
Learn best practices for utilizing Infisical service tokens. Please note that service tokens are now deprecated and will be removed entirely in the future.
|
||||||
</Card>
|
</Card>
|
||||||
</CardGroup>
|
</CardGroup>
|
||||||
|
|||||||
@@ -2,6 +2,10 @@
|
|||||||
title: "Service tokens"
|
title: "Service tokens"
|
||||||
description: "Understanding service tokens and their best practices."
|
description: "Understanding service tokens and their best practices."
|
||||||
---
|
---
|
||||||
|
|
||||||
|
<Warning>
|
||||||
|
Service tokens are deprecated and will be removed in the future. Please use the [machine identity](/documentation/platform/identities/machine-identities) approach instead.
|
||||||
|
</Warning>
|
||||||
|
|
||||||
Many clients use service tokens to authenticate and read/write secrets from/to Infisical; they can be created in your project settings.
|
Many clients use service tokens to authenticate and read/write secrets from/to Infisical; they can be created in your project settings.
|
||||||
|
|
||||||
|
|||||||