mirror of
https://github.com/awatertrevi/infisical.git
synced 2026-10-06 08:27:22 +00:00
Feat: API Docs revamp (Service Token Deprecation)
This commit is contained in:
Daniel Hougaard
@@ -42,12 +42,26 @@ Follow the instructions for either [Helm](https://helm.sh/) or [kubectl](https:/
|
||||
|
||||
## 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
|
||||
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**
|
||||
@@ -63,13 +77,16 @@ spec:
|
||||
hostAPI: https://app.infisical.com/api
|
||||
resyncInterval:
|
||||
authentication:
|
||||
serviceToken:
|
||||
serviceTokenSecretReference:
|
||||
secretName: service-token
|
||||
secretNamespace: option
|
||||
secretsScope:
|
||||
envSlug: dev
|
||||
secretsPath: "/"
|
||||
universalAuth:
|
||||
secretsScope:
|
||||
projectSlug: <project-slug>
|
||||
envSlug: <env-slug> # "dev", "staging", "prod", etc..
|
||||
secretsPath: "<secrets-path>" # Root is "/"
|
||||
|
||||
credentialsRef:
|
||||
secretName: universal-auth-credentials
|
||||
secretNamespace: default
|
||||
|
||||
managedSecretReference:
|
||||
secretName: managed-secret # <-- the name of kubernetes secret that will 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.
|
||||
|
||||
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
|
||||
|
||||
|
||||
@@ -43,7 +43,23 @@ To interact with various resources in Infisical, Machine Identities are able to
|
||||
## FAQ
|
||||
|
||||
<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?">
|
||||
<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.
|
||||
|
||||
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:
|
||||
- **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).
|
||||
- **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.
|
||||
|
||||
@@ -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 [email protected] 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.
|
||||
|
||||
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."
|
||||
---
|
||||
|
||||
<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.
|
||||
Each service token can be provisioned scoped access to select environment(s) and path(s) within them.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user