awatertrevi/infisical
1
0
Fork 0
mirror of https://github.com/awatertrevi/infisical.git synced 2026-09-22 13:39:35 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update package-lock.json

Browse Source
This commit is contained in:
Tuan Dang
2023-04-19 18:18:38 +03:00
parent 9f944135b9 afdf971014
commit 7fc01df93e
25 changed files with 1761 additions and 1133 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/api-reference/overview/authentication.mdx
View File

@@ -5,11 +5,11 @@ description: "How to authenticate with the Infisical Public API"
## Essentials
The Public API accepts multiple modes of authentication being via API Key, Service Account credentials, or [Infisical Token](../../../getting-started/dashboard/token).
The Public API accepts multiple modes of authentication being via API Key, Service Account credentials, or [Infisical Token](../../getting-started/dashboard/token).
- API Key: Provides full access to all endpoints representing the user.
- [Service Account](): Provides scoped access to an organization and select projects representing a machine such as a VM or application client.
- [Infisical Token](../../../getting-started/dashboard/token): Provides short-lived, scoped CRUD access to the secrets of a specific project and environment.
- [Infisical Token](../../getting-started/dashboard/token): Provides short-lived, scoped CRUD access to the secrets of a specific project and environment.
<AccordionGroup>
<Accordion title="API Key">
@@ -48,4 +48,4 @@ Depending on your use case, it may make sense to use one or another authenticati
- API Key (not recommended): Use if you need full access to the Public API without needing to access any secrets endpoints (because API keys can't encrypt/decrypt secrets).
- Service Account (recommeded): Use if you need access to multiple projects and environments in an organization; service accounts can generate short-lived access tokens, making them useful for some complex setups.
- Service Token (recommeded): Use if you need short-lived, scoped CRUD access to the secrets of a specific project and environment.
- Service Token (recommeded): Use if you need short-lived, scoped CRUD access to the secrets of a specific project and environment.

137
docs/integrations/platforms/kubernetes.mdx
View File

@@ -38,12 +38,10 @@ The operator can be install via [Helm](helm.sh) or [kubectl](https://github.com/
</Tabs>
## Sync Infisical Secrets to your cluster
To retrieve secrets from an Infisical project and store them in your Kubernetes cluster, you can use the InfisicalSecret custom resource.
This resource is available after installing the Infisical operator. In order to specify the Infisical Token location and the location where the retrieved secrets should be stored, you can use the `tokenSecretReference` and `managedSecretReference` fields within the InfisicalSecret resource.
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.
```yaml
apiVersion: secrets.infisical.com/v1alpha1
kind: InfisicalSecret
metadata:
@@ -52,46 +50,123 @@ 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
# The Kubernetes secret the stores the Infisical token
tokenSecretReference:
# Kubernetes secret name
secretName: service-token
# The secret namespace
secretNamespace: default
# The Kubernetes secret that Infisical Operator will create and populate with secrets from the above project
authentication:
serviceToken: # <-- option 1
serviceTokenSecretReference:
secretName: service-token
secretNamespace: option
serviceAccount: # <-- method 2
serviceAccountSecretReference:
secretName: service-account
secretNamespace: default
projectId: "6439ec224cfbf7ea2a95b651"
environmentName: "dev"
managedSecretReference:
# The name of managed Kubernetes secret that should be created
secretName: managed-secret
# The namespace the managed secret should be installed in
secretNamespace: default
secretName: managed-secret # <-- the name of kubernetes secret that will be created
secretNamespace: default # <-- where the kubernetes secret that will be created
```
### InfisicalSecret CRD properties
<Accordion title="tokenSecretReference">
The `tokenSecretReference` field in the InfisicalSecret resource is used to specify the location of the Infisical Token, which is required for authenticating and retrieving secrets from an Infisical project.
To create a Kubernetes secret containing an [Infisical Token](../../getting-started/dashboard/token), you can run the command below.
``` bash
kubectl create secret generic service-token --from-literal=infisicalToken=<infisical-token-here>
```
<Accordion title="hostAPI">
If you are fetching secrets from a self hosted instance of Infisical set the value of `hostAPI` to
` https://your-self-hosted-instace.com/api`
Once the secret is created, add the name and namespace of the secret under `tokenSecretReference` field in the InfisicalSecret custom resource.
When `hostAPI` is not defined the operator fetches secrets from Infisical Cloud.
</Accordion>
{' '}
<Accordion title="authentication">
The `authentication` property tells the operator where it should look to find credentials needed to fetch secrets from Infisical. You can authenticate via two methods as described below.
<Info>
No matter what the name of the secret is or its namespace, it must contain a
key named `infisicalToken` with a valid Infisical Token as the value
</Info>
<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
You can generate a service token for an Infisical project by heading over to the Infisical dashboard then to Project Settings.
#### 2. Create Kubernetes secret containing service token
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.
``` bash
kubectl create secret generic service-token --from-literal=infisicalToken=<your-service-token-here>
```
#### 3. Add reference for the Kubernetes secret containing service token
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
...
```
</Tab>
<Tab title="Service Account">
We recommend authenticating with service account credentials when you have a large number of services. With this method, instead of creating a service token for each Infisical project you'd like to
fetch secrets from, you can fetch secrets from a number of Infisical projects with just one set of credentials.
#### 1. Generate service account
You can generate a service account by heading over to the organization settings. Once you create the service account, keep the credentials at hand for the next steps.
#### 2. Grant service account access to Infisical projects
Click on the pencil icon on the service account you just created and add the projects you'd like to be accessible via that service account.
#### 3. Store service account credentials in K8 secret
Next, we'll need to store the service account credentials in a kubernetes secret so that we can reference it in our InfisicalSecret CRD.
We recommend you create this kubernetes secret in a new namespace since you may need to reference it many times for each InfisicalSecret CRD you create.
To quickly create a Kubernetes secret containing the service account details, you can execute the command below after replacing it with your own service account credentials.
```
kubectl create secret generic service-token --from-literal=serviceAccountAccessKey=[REPLACE] --from-literal=serviceAccountPrivateKey=[REPLACE] --from-literal=serviceAccountPublicKey=[REPLACE]
```
Regardless of how you create the kubernetes secret containing the service account credentials, you will need to define values for the following keys in the secret: `serviceAccountAccessKey`, `serviceAccountPrivateKey`, and `serviceAccountPublicKey`
Once the secret is created, add the name and namespace of the secret that was just created under `authentication.serviceAccount.serviceAccountSecretReference` field in the InfisicalSecret CRD.
#### 4. Add projectId and environment from which to fetch secrets from
Add the Infisical project id and environment from which to fetch secrets for by providing values under `authentication.serviceAccount.projectId` and `authentication.serviceAccount.environmentName`.
## Example
```yaml
apiVersion: secrets.infisical.com/v1alpha1
kind: InfisicalSecret
metadata:
name: infisicalsecret-sample-crd
spec:
serviceAccount:
serviceAccountSecretReference:
secretName: service-account
secretNamespace: default
projectId: "6439ec224cfbf7ea2a95b651"
environmentName: "dev"
```
</Tab>
</Tabs>
</Accordion>
<Accordion title="managedSecretReference">
The `managedSecretReference` field in the InfisicalSecret resource is used to specify the location where secrets retrieved from an Infisical project should be stored.
You should specify the name and namespace of the Kubernetes secret that will hold these secrets. The operator will create the secret for you, you just need to provide its name and namespace.
It is recommended that the managed secret be created in the same namespace as the deployment that will use it.
The managed secret be should be created in the same namespace as the deployment that will use it.
</Accordion>