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

fix kubernetes docs

Browse Source
This commit is contained in:
Maidul Islam
2025-01-09 12:11:48 -05:00
parent e29f7f656c
commit b5b91c929f
3 changed files with 124 additions and 121 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
docs/integrations/platforms/kubernetes/infisical-dynamic-secret-crd.mdx
View File

@@ -1,14 +1,26 @@
--- ---
sidebarTitle: "InfisicalDynamicSecret CRD" sidebarTitle: "InfisicalDynamicSecret CRD"
title: "Using the InfisicalDynamicSecret CRD" title: "InfisicalDynamicSecret CRD"
description: "Learn how to use the InfisicalDynamicSecret CRD to create dynamic secret leases in Infisical and sync them to your Kubernetes cluster." description: "Learn how to generate dynamic secret leases in Infisical and sync them to your Kubernetes cluster."
--- ---
## Overview
## Sync Dynamic Secrets to your cluster The **InfisicalDynamicSecret** CRD allows you to easily create and manage dynamic secret leases in Infisical and automatically syncing them to your Kubernetes cluster as native **Kubernetes Secret** resources.
This means any Pod, Deployment, or other Kubernetes resource can make use of dynamic secrets from Infisical just like any other K8s secret.
### Example usage This CRD offers the following features:
- **Generate a dynamic secret lease** in Infisical and track its lifecycle.
- **write** the dynamic secret from Infisical to your cluster as native Kubernetes secret.
- **Automatically rotate** the dyanmic secret value before it expires to make sure your cluster always has valid credentials.
- **Optionally trigger redeployments** of any workloads that consume the secret if you enable auto-reload.
The example below demonstrates a sample InfisicalDynamicSecret CRD that creates a dynamic secret lease in Infisical, and syncs the lease to your Kubernetes cluster. ### Prerequisites
- The operator is installed on to your Kubernetes cluster
- You have already configured a dynamic secret in Infisical
## Configure Dynamic Secret CRD
The example below shows a sample **InfisicalDynamicSecret** CRD that creates a dynamic secret lease in Infisical, and syncs the lease to your Kubernetes cluster.
```yaml dynamic-secret-crd.yaml ```yaml dynamic-secret-crd.yaml
apiVersion: secrets.infisical.com/v1alpha1 apiVersion: secrets.infisical.com/v1alpha1

94
docs/integrations/platforms/kubernetes/infisical-secret-crd.mdx
View File

@@ -1,11 +1,9 @@
--- ---
sidebarTitle: "InfisicalSecret CRD" sidebarTitle: "InfisicalSecret CRD"
title: "Using the InfisicalSecret CRD" title: "InfisicalSecret CRD"
description: "Learn how to use the InfisicalSecret CRD to fetch secrets from Infisical and store them in a Kubernetes secret" description: "Learn how to use the InfisicalSecret CRD to fetch secrets from Infisical and store them as native Kubernetes secret resource"
--- ---
## Sync Infisical Secrets to your cluster
Once you have installed the operator to your cluster, you'll need to create a `InfisicalSecret` custom resource definition (CRD). Once you have installed the operator to your cluster, you'll need to create a `InfisicalSecret` custom resource definition (CRD).
```yaml example-infisical-secret-crd.yaml ```yaml example-infisical-secret-crd.yaml
@@ -691,48 +689,6 @@ This is useful for tools such as ArgoCD, where every resource requires an owner
</Accordion> </Accordion>
### Propagating labels & annotations
The operator will transfer all labels & annotations present on the `InfisicalSecret` CRD to the managed Kubernetes secret to be created.
Thus, if a specific label is required on the resulting secret, it can be applied as demonstrated in the following example:
<Accordion title="Example propagation">
```yaml
apiVersion: secrets.infisical.com/v1alpha1
kind: InfisicalSecret
metadata:
name: infisicalsecret-sample
labels:
label-to-be-passed-to-managed-secret: sample-value
annotations:
example.com/annotation-to-be-passed-to-managed-secret: "sample-value"
spec:
..
authentication:
...
managedSecretReference:
...
```
This would result in the following managed secret to be created:
```yaml
apiVersion: v1
data: ...
kind: Secret
metadata:
annotations:
example.com/annotation-to-be-passed-to-managed-secret: sample-value
secrets.infisical.com/version: W/"3f1-ZyOSsrCLGSkAhhCkY2USPu2ivRw"
labels:
label-to-be-passed-to-managed-secret: sample-value
name: managed-token
namespace: default
type: Opaque
```
</Accordion>
### Apply the InfisicalSecret CRD to your cluster ### Apply the InfisicalSecret CRD to your cluster
Once you have configured the InfisicalSecret CRD with the required fields, you can apply it to your cluster. Once you have configured the InfisicalSecret CRD with the required fields, you can apply it to your cluster.
@@ -756,7 +712,7 @@ kubectl get secrets -n <namespace of managed secret>
1 minutes. 1 minutes.
</Info> </Info>
### Using managed secret in your deployment ## Using managed secret in your deployment
Incorporating the managed secret created by the operator into your deployment can be achieved through several methods. Incorporating the managed secret created by the operator into your deployment can be achieved through several methods.
Here, we will highlight three of the most common ways to utilize it. Learn more about Kubernetes secrets [here](https://kubernetes.io/docs/concepts/configuration/secret/) Here, we will highlight three of the most common ways to utilize it. Learn more about Kubernetes secrets [here](https://kubernetes.io/docs/concepts/configuration/secret/)
@@ -962,4 +918,46 @@ spec:
#### How it works #### How it works
When a secret change occurs, the operator will check to see which deployments are using the operator-managed Kubernetes secret that received the update. When a secret change occurs, the operator will check to see which deployments are using the operator-managed Kubernetes secret that received the update.
Then, for each deployment that has this annotation present, a rolling update will be triggered. Then, for each deployment that has this annotation present, a rolling update will be triggered.
</Info> </Info>
## Propagating labels & annotations
The operator will transfer all labels & annotations present on the `InfisicalSecret` CRD to the managed Kubernetes secret to be created.
Thus, if a specific label is required on the resulting secret, it can be applied as demonstrated in the following example:
<Accordion title="Example propagation">
```yaml
apiVersion: secrets.infisical.com/v1alpha1
kind: InfisicalSecret
metadata:
name: infisicalsecret-sample
labels:
label-to-be-passed-to-managed-secret: sample-value
annotations:
example.com/annotation-to-be-passed-to-managed-secret: "sample-value"
spec:
..
authentication:
...
managedSecretReference:
...
```
This would result in the following managed secret to be created:
```yaml
apiVersion: v1
data: ...
kind: Secret
metadata:
annotations:
example.com/annotation-to-be-passed-to-managed-secret: sample-value
secrets.infisical.com/version: W/"3f1-ZyOSsrCLGSkAhhCkY2USPu2ivRw"
labels:
label-to-be-passed-to-managed-secret: sample-value
name: managed-token
namespace: default
type: Opaque
```
</Accordion>

129
docs/integrations/platforms/kubernetes/overview.mdx
View File

@@ -1,14 +1,18 @@
--- ---
title: "Kubernetes Operator" title: "Kubernetes Operator"
sidebarTitle: "Overview" sidebarTitle: "Overview"
description: "How to use Infisical to inject secrets into Kubernetes clusters." description: "How to use Infisical to inject, push, and manage secrets within Kubernetes clusters"
--- ---
![title](../../../images/k8-diagram.png) The Infisical Operator is a collection of Kubernetes controllers that streamline how secrets are managed between Infisical and your Kubernetes cluster.
It provides multiple Custom Resource Definitions (CRDs) which enable you to:
The Infisical Secrets Operator is a Kubernetes controller that retrieves secrets from Infisical and stores them in a designated cluster. - **Sync** secrets from Infisical into Kubernetes (`InfisicalSecret`).
It uses an `InfisicalSecret` resource to specify authentication and storage methods. - **Push** new secrets from Kubernetes to Infisical (`InfisicalPushSecret`).
The operator continuously updates secrets and can also reload dependent deployments automatically. - **Manage** dynamic secrets and automatically create time-bound leases (`InfisicalDynamicSecret`).
When these CRDs are configured, the Infisical Operator will continuously monitors for changes and performs necessary updates to keep your Kubernetes secrets up to date.
It can also automatically reload dependent Deployments resources whenever relevant secrets are updated.
<Note> <Note>
If you are already using the External Secrets operator, you can view the If you are already using the External Secrets operator, you can view the
@@ -16,77 +20,75 @@ The operator continuously updates secrets and can also reload dependent deployme
[here](https://external-secrets.io/latest/provider/infisical/). [here](https://external-secrets.io/latest/provider/infisical/).
</Note> </Note>
## Install Operator ## Install
The operator can be install via [Helm](https://helm.sh). Helm is a package manager for Kubernetes that allows you to define, install, and upgrade Kubernetes applications. The operator can be install via [Helm](https://helm.sh). Helm is a package manager for Kubernetes that allows you to define, install, and upgrade Kubernetes applications.
**Install the latest Helm repository**
**Install the latest Infisical Helm repository**
```bash ```bash
helm repo add infisical-helm-charts 'https://dl.cloudsmith.io/public/infisical/helm-charts/helm/charts/' helm repo add infisical-helm-charts 'https://dl.cloudsmith.io/public/infisical/helm-charts/helm/charts/'
```
```bash
helm repo update helm repo update
``` ```
**Install the Helm chart** The operator can be installed either cluster-wide or restricted to a specific namespace.
If you require stronger isolation and stricter access controls, a namespace-scoped installation may make more sense.
To select a specific version, view the application versions [here](https://hub.docker.com/r/infisical/kubernetes-operator/tags) and chart versions [here](https://cloudsmith.io/~infisical/repos/helm-charts/packages/detail/helm/secrets-operator/#versions) <Tabs>
<Tab title="Cluster Wide Installation">
```bash
helm install --generate-name infisical-helm-charts/secrets-operator
```
</Tab>
<Tab title="Namespace Scoped Installation">
The operator can be configured to watch and manage secrets in a specific namespace instead of having cluster-wide access. This is useful for:
```bash - **Enhanced Security**: Limit the operator's permissions to only specific namespaces instead of cluster-wide access
helm install --generate-name infisical-helm-charts/secrets-operator - **Multi-tenant Clusters**: Run separate operator instances for different teams or applications
``` - **Resource Isolation**: Ensure operators in different namespaces don't interfere with each other
- **Development & Testing**: Run development and production operators side by side in isolated namespaces
```bash **Note**: For multiple namespace-scoped installations, only the first installation should install CRDs. Subsequent installations should set `installCRDs: false` to avoid conflicts.
# Example installing app version v0.2.0 and chart version 0.1.4
helm install --generate-name infisical-helm-charts/secrets-operator --version=0.1.4 --set controllerManager.manager.image.tag=v0.2.0
```
**Namespace-scoped Installation** ```bash
# First namespace installation (with CRDs)
helm install operator-namespace1 infisical-helm-charts/secrets-operator \
--namespace first-namespace \
--set scopedNamespace=first-namespace \
--set scopedRBAC=true
The operator can be configured to watch and manage secrets in a specific namespace instead of having cluster-wide access. This is useful for: # Subsequent namespace installations
helm install operator-namespace2 infisical-helm-charts/secrets-operator \
--namespace another-namespace \
--set scopedNamespace=another-namespace \
--set scopedRBAC=true \
--set installCRDs=false
```
- **Enhanced Security**: Limit the operator's permissions to only specific namespaces instead of cluster-wide access When scoped to a namespace, the operator will:
- **Multi-tenant Clusters**: Run separate operator instances for different teams or applications
- **Resource Isolation**: Ensure operators in different namespaces don't interfere with each other
- **Development & Testing**: Run development and production operators side by side in isolated namespaces
**Note**: For multiple namespace-scoped installations, only the first installation should install CRDs. Subsequent installations should set `installCRDs: false` to avoid conflicts. - Only watch InfisicalSecrets in the specified namespace
- Only create/update Kubernetes secrets in that namespace
- Only access deployments in that namespace
```bash The default configuration gives cluster-wide access:
# First namespace installation (with CRDs)
helm install operator-namespace1 infisical-helm-charts/secrets-operator \
--namespace first-namespace \
--set scopedNamespace=first-namespace \
--set scopedRBAC=true
# Subsequent namespace installations ```yaml
helm install operator-namespace2 infisical-helm-charts/secrets-operator \ installCRDs: true # Install CRDs (set to false for additional namespace installations)
--namespace another-namespace \ scopedNamespace: "" # Empty for cluster-wide access
--set scopedNamespace=another-namespace \ scopedRBAC: false # Cluster-wide permissions
--set scopedRBAC=true \ ```
--set installCRDs=false
```
When scoped to a namespace, the operator will: If you want to install operators in multiple namespaces simultaneously:
- Make sure to set `installCRDs: false` for all but one of the installations to avoid conflicts, as CRDs are cluster-wide resources.
- Use unique release names for each installation (e.g., operator-namespace1, operator-namespace2).
- Only watch InfisicalSecrets in the specified namespace </Tab>
- Only create/update Kubernetes secrets in that namespace </Tabs>
- Only access deployments in that namespace
The default configuration gives cluster-wide access: ## Custom Resource Definitions
```yaml
installCRDs: true # Install CRDs (set to false for additional namespace installations)
scopedNamespace: "" # Empty for cluster-wide access
scopedRBAC: false # Cluster-wide permissions
```
If you want to install operators in multiple namespaces simultaneously:
- Make sure to set `installCRDs: false` for all but one of the installations to avoid conflicts, as CRDs are cluster-wide resources.
- Use unique release names for each installation (e.g., operator-namespace1, operator-namespace2).
## Custom Resource Definitions (CRD's)
Currently the operator supports the following CRD's. We are constantly expanding the functionality of the operator, and this list will be updated as new CRD's are added. Currently the operator supports the following CRD's. We are constantly expanding the functionality of the operator, and this list will be updated as new CRD's are added.
@@ -94,8 +96,8 @@ Currently the operator supports the following CRD's. We are constantly expanding
2. [InfisicalPushSecret](/integrations/platforms/kubernetes/infisical-push-secret-crd): Push secrets from a Kubernetes secret to Infisical. 2. [InfisicalPushSecret](/integrations/platforms/kubernetes/infisical-push-secret-crd): Push secrets from a Kubernetes secret to Infisical.
3. [InfisicalDynamicSecret](/integrations/platforms/kubernetes/infisical-dynamic-secret-crd): Sync dynamic secrets and create leases automatically in Kubernetes. 3. [InfisicalDynamicSecret](/integrations/platforms/kubernetes/infisical-dynamic-secret-crd): Sync dynamic secrets and create leases automatically in Kubernetes.
## Connecting to instances with private/self-signed certificate ## General Configuration
### Private/self-signed certificate
To connect to Infisical instances behind a private/self-signed certificate, you can configure the TLS settings in the CRD To connect to Infisical instances behind a private/self-signed certificate, you can configure the TLS settings in the CRD
to point to a CA certificate stored in a Kubernetes secret resource. to point to a CA certificate stored in a Kubernetes secret resource.
@@ -190,13 +192,4 @@ The managed secret created by the operator will not be deleted when the operator
helm uninstall <release name> helm uninstall <release name>
``` ```
</Tab> </Tab>
<Tab title="Kubectl"> </Tabs>
```
kubectl delete -f https://raw.githubusercontent.com/Infisical/infisical/main/k8-operator/kubectl-install/install-secrets-operator.yaml
```
</Tab>
</Tabs>
## Useful Articles
- [Managing secrets in OpenShift with Infisical](https://xphyr.net/post/infisical_ocp/)