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
Files
956fb2efb4b3dd06500d0c43f52692999c9b8667
infisical/docs/integrations/platforms/kubernetes/infisical-push-secret-crd.mdx
Daniel Hougaard 956fb2efb4 docs: better k8s pre-req
2025-01-10 20:16:30 +01:00

413 lines
14 KiB
Plaintext
Raw Blame History

---
sidebarTitle: "InfisicalPushSecret CRD"
title: "Using the InfisicalPushSecret CRD"
description: "Learn how to use the InfisicalPushSecret CRD to push and manage secrets in Infisical."
---
## Overview
The **InfisicalPushSecret** CRD allows you to create and manage secrets in Infisical and sync them to your Kubernetes cluster as native **Kubernetes secret** resources.
If you need automatic redeployments of your application when secrets change, you can use the [InfisicalSecret](/docs/integrations/platforms/kubernetes/infisical-secret-crd) CRD to fetch secrets from Infisical and inject them into your application's environment.
This CRD offers the following features:
- **Create Secrets** in Infisical and manage its lifecycle.
- **Automatic secret deletion** when the InfisicalPushSecret CRD is deleted.
### Prerequisites
- A project within Infisical.
- A [machine identity](/docs/documentation/platform/identities/overview) ready for use in Infisical that has permissions to create secrets in your project.
- The operator is installed on to your Kubernetes cluster.
## Example usage
Below is a sample InfisicalPushSecret CRD that pushes secrets defined in a Kubernetes secret to Infisical.
After filling out the fields in the InfisicalPushSecret CRD, you can apply it directly to your cluster.
Before applying the InfisicalPushSecret CRD, you need to create a Kubernetes secret containing the secrets you want to push to Infisical. An example can be seen below the InfisicalPushSecret CRD.
```yaml infisical-push-secret.yaml
apiVersion: secrets.infisical.com/v1alpha1
kind: InfisicalPushSecret
metadata:
name: infisical-push-secret-demo
spec:
resyncInterval: 1m
hostAPI: https://app.infisical.com/api
# Optional, defaults to no replacement.
updatePolicy: Replace # If set to replace, existing secrets inside Infisical will be replaced by the value of the PushSecret on sync.
# Optional, defaults to no deletion.
deletionPolicy: Delete # If set to delete, the secret(s) inside Infisical managed by the operator, will be deleted if the InfisicalPushSecret CRD is deleted.
destination:
projectId: <project-id>
environmentSlug: <env-slug>
secretsPath: <secret-path>
push:
secret:
secretName: push-secret-demo # Secret CRD
secretNamespace: default
# Only have one authentication method defined or you are likely to run into authentication issues.
# Remove all except one authentication method.
authentication:
awsIamAuth:
identityId: <machine-identity-id>
azureAuth:
identityId: <machine-identity-id>
gcpIamAuth:
identityId: <machine-identity-id>
serviceAccountKeyFilePath: </path-to-service-account-key-file.json>
gcpIdTokenAuth:
identityId: <machine-identity-id>
kubernetesAuth:
identityId: <machine-identity-id>
serviceAccountRef:
name: <secret-name>
namespace: <secret-namespace>
universalAuth:
credentialsRef:
secretName: <secret-name> # universal-auth-credentials
secretNamespace: <secret-namespace> # default
```
```yaml source-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: push-secret-demo
namespace: default
stringData: # can also be "data", but needs to be base64 encoded
API_KEY: some-api-key
DATABASE_URL: postgres://127.0.0.1:5432
ENCRYPTION_KEY: fabcc12-a22-facbaa4-11aa568aab
```
```bash
kubectl apply -f source-secret.yaml
```
After applying the soruce-secret.yaml file, you are ready to apply the InfisicalPushSecret CRD.
```bash
kubectl apply -f infisical-push-secret.yaml
```
After applying the InfisicalPushSecret CRD, you should notice that the secrets you have defined in your source-secret.yaml file have been pushed to your specified destination in Infisical.
## InfisicalPushSecret CRD properties
<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`
When `hostAPI` is not defined the operator fetches secrets from Infisical Cloud.
<Accordion title="Advanced use case">
If you have installed your Infisical instance within the same cluster as the Infisical operator, you can optionally access the Infisical backend's service directly without having to route through the public internet.
To achieve this, use the following address for the hostAPI field:
``` bash
http://<backend-svc-name>.<namespace>.svc.cluster.local:4000/api
```
Make sure to replace `<backend-svc-name>` and `<namespace>` with the appropriate values for your backend service and namespace.
</Accordion>
</Accordion>
<Accordion title="resyncInterval">
The `resyncInterval` is a string-formatted duration that defines the time between each resync.
The format of the field is `[duration][unit]` where `duration` is a number and `unit` is a string representing the unit of time.
The following units are supported:
- `s` for seconds (must be at least 5 seconds)
- `m` for minutes
- `h` for hours
- `d` for days
- `w` for weeks
The default value is `1m` (1 minute).
Valid intervals examples:
```yaml
resyncInterval: 5s # 10 seconds
resyncInterval: 10s # 10 seconds
resyncInterval: 5m # 5 minutes
resyncInterval: 1h # 1 hour
resyncInterval: 1d # 1 day
```
</Accordion>
<Accordion title="updatePolicy">
The field is optional and will default to `None` if not defined.
The update policy defines how the operator should handle conflicting secrets when pushing secrets to Infisical.
Valid values are `None` and `Replace`.
Behavior of each policy:
- `None`: The operator will not override existing secrets in Infisical. If a secret with the same key already exists, the operator will skip pushing that secret, and the secret will not be managed by the operator.
- `Replace`: The operator will replace existing secrets in Infisical with the new secrets. If a secret with the same key already exists, the operator will update the secret with the new value.
```yaml
spec:
updatePolicy: Replace
```
</Accordion>
<Accordion title="deletionPolicy">
This field is optional and will default to `None` if not defined.
The deletion policy defines what the operator should do in case the InfisicalPushSecret CRD is deleted.
Valid values are `None` and `Delete`.
Behavior of each policy:
- `None`: The operator will not delete the secrets in Infisical when the InfisicalPushSecret CRD is deleted.
- `Delete`: The operator will delete the secrets in Infisical that are managed by the operator when the InfisicalPushSecret CRD is deleted.
```yaml
spec:
deletionPolicy: Delete
```
</Accordion>
<Accordion title="destination">
The `destination` field is used to specify where you want to create the secrets in Infisical. The required fields are `projectId`, `environmentSlug`, and `secretsPath`.
```yaml
spec:
destination:
projectId: <project-id>
environmentSlug: <env-slug>
secretsPath: <secrets-path>
```
<Accordion title="destination.projectId">
The project ID where you want to create the secrets in Infisical.
</Accordion>
<Accordion title="destination.environmentSlug">
The environment slug where you want to create the secrets in Infisical.
</Accordion>
<Accordion title="destination.secretsPath">
The path where you want to create the secrets in Infisical. The root path is `/`.
</Accordion>
</Accordion>
<Accordion title="push">
The `push` field is used to define what you want to push to Infisical. Currently the operator only supports pushing Kubernetes secrets to Infisical. An example of the `push` field is shown below.
<Accordion title="secret">
The `secret` field is used to define the Kubernetes secret you want to push to Infisical. The required fields are `secretName` and `secretNamespace`.
Example usage of the `push.secret` field:
```yaml infisical-push-secret.yaml
push:
secret:
secretName: push-secret-demo
secretNamespace: default
```
```yaml push-secret-demo.yaml
apiVersion: v1
kind: Secret
metadata:
name: push-secret-demo
namespace: default
# Pass in the secrets you wish to push to Infisical
stringData:
API_KEY: some-api-key
DATABASE_URL: postgres://127.0.0.1:5432
ENCRYPTION_KEY: fabcc12-a22-facbaa4-11aa568aab
```
</Accordion>
</Accordion>
<Accordion title="authentication">
The `authentication` field dictates which authentication method to use when pushing secrets to Infisical.
The available authentication methods are `universalAuth`, `kubernetesAuth`, `awsIamAuth`, `azureAuth`, `gcpIdTokenAuth`, and `gcpIamAuth`.
<Accordion title="universalAuth">
The universal authentication method is one of the easiest ways to get started with Infisical. Universal Auth works anywhere and is not tied to any specific cloud provider.
[Read more about Universal Auth](/documentation/platform/identities/universal-auth).
Valid fields:
- `identityId`: The identity ID of the machine identity you created.
- `credentialsRef`: The name and namespace of the Kubernetes secret that stores the service token.
- `credentialsRef.secretName`: The name of the Kubernetes secret.
- `credentialsRef.secretNamespace`: The namespace of the Kubernetes secret.
Example:
```yaml
# infisical-push-secret.yaml
spec:
universalAuth:
credentialsRef:
secretName: <secret-name>
secretNamespace: <secret-namespace>
```
```yaml
# machine-identity-credentials.yaml
apiVersion: v1
kind: Secret
metadata:
name: universal-auth-credentials
type: Opaque
stringData:
clientId: <machine-identity-client-id>
clientSecret: <machine-identity-client-secret>
```
</Accordion>
<Accordion title="kubernetesAuth">
The Kubernetes machine identity authentication method is used to authenticate with Infisical. The identity ID is stored in a field in the InfisicalSecret resource. This authentication method can only be used within a Kubernetes environment.
[Read more about Kubernetes Auth](/documentation/platform/identities/kubernetes-auth).
Valid fields:
- `identityId`: The identity ID of the machine identity you created.
- `serviceAccountRef`: The name and namespace of the service account that will be used to authenticate with Infisical.
- `serviceAccountRef.name`: The name of the service account.
- `serviceAccountRef.namespace`: The namespace of the service account.
Example:
```yaml
spec:
kubernetesAuth:
identityId: <machine-identity-id>
serviceAccountRef:
name: <secret-name>
namespace: <secret-namespace>
```
</Accordion>
<Accordion title="awsIamAuth">
The AWS IAM machine identity authentication method is used to authenticate with Infisical.
[Read more about AWS IAM Auth](/documentation/platform/identities/aws-auth).
Valid fields:
- `identityId`: The identity ID of the machine identity you created.
Example:
```yaml
spec:
authentication:
awsIamAuth:
identityId: <machine-identity-id>
```
</Accordion>
<Accordion title="azureAuth">
The AWS IAM machine identity authentication method is used to authenticate with Infisical. Azure Auth can only be used from within an Azure environment.
[Read more about Azure Auth](/documentation/platform/identities/azure-auth).
Valid fields:
- `identityId`: The identity ID of the machine identity you created.
Example:
```yaml
spec:
authentication:
azureAuth:
identityId: <machine-identity-id>
```
</Accordion>
<Accordion title="gcpIamAuth">
The GCP IAM machine identity authentication method is used to authenticate with Infisical. The identity ID is stored in a field in the InfisicalSecret resource. This authentication method can only be used both within and outside GCP environments.
[Read more about Azure Auth](/documentation/platform/identities/gcp-auth).
Valid fields:
- `identityId`: The identity ID of the machine identity you created.
- `serviceAccountKeyFilePath`: The path to the GCP service account key file.
Example:
```yaml
spec:
gcpIamAuth:
identityId: <machine-identity-id>
serviceAccountKeyFilePath: </path-to-service-account-key-file.json>
```
</Accordion>
<Accordion title="gcpIdTokenAuth">
The GCP ID Token machine identity authentication method is used to authenticate with Infisical. The identity ID is stored in a field in the InfisicalSecret resource. This authentication method can only be used within GCP environments.
[Read more about Azure Auth](/documentation/platform/identities/gcp-auth).
Valid fields:
- `identityId`: The identity ID of the machine identity you created.
Example:
```yaml
spec:
gcpIdTokenAuth:
identityId: <machine-identity-id>
```
</Accordion>
</Accordion>
<Accordion title="tls">
This block defines the TLS settings to use for connecting to the Infisical
instance.
Fields:
<Accordion title="caRef">
This block defines the reference to the CA certificate to use for connecting to the Infisical instance with SSL/TLS.
Valid fields:
- `secretName`: The name of the Kubernetes secret containing the CA certificate to use for connecting to the Infisical instance with SSL/TLS.
- `secretNamespace`: The namespace of the Kubernetes secret containing the CA certificate to use for connecting to the Infisical instance with SSL/TLS.
- `key`: The name of the key in the Kubernetes secret which contains the value of the CA certificate to use for connecting to the Infisical instance with SSL/TLS.
Example:
```yaml
tls:
caRef:
secretName: custom-ca-certificate
secretNamespace: default
key: ca.crt
```
</Accordion>
</Accordion>
## Applying the InfisicalPushSecret CRD to your cluster
Once you have configured the `InfisicalPushSecret` CRD with the required fields, you can apply it to your cluster.
After applying, you should notice that the secrets have been pushed to Infisical.
```bash
kubectl apply -f source-push-secret.yaml # The secret that you're referencing in the InfisicalPushSecret CRD push.secret field
kubectl apply -f example-infisical-push-secret-crd.yaml # The InfisicalPushSecret CRD itself
```
Reference in New Issue View Git Blame Copy Permalink