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

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

@@ -1,14 +1,18 @@
---
title: "Kubernetes Operator"
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.
It uses an `InfisicalSecret` resource to specify authentication and storage methods.
The operator continuously updates secrets and can also reload dependent deployments automatically.
- **Sync** secrets from Infisical into Kubernetes (`InfisicalSecret`).
- **Push** new secrets from Kubernetes to Infisical (`InfisicalPushSecret`).
- **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>
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/).
</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.
**Install the latest Infisical Helm repository**
**Install the latest Helm repository**
```bash
helm repo add infisical-helm-charts 'https://dl.cloudsmith.io/public/infisical/helm-charts/helm/charts/'
```
```bash
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
helm install --generate-name infisical-helm-charts/secrets-operator
```
- **Enhanced Security**: Limit the operator's permissions to only specific namespaces instead of cluster-wide access
- **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
# 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
```
**Note**: For multiple namespace-scoped installations, only the first installation should install CRDs. Subsequent installations should set `installCRDs: false` to avoid conflicts.
**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
- **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
When scoped to a namespace, the operator will:
**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
# 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 default configuration gives cluster-wide access:
# 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
```
```yaml
installCRDs: true # Install CRDs (set to false for additional namespace installations)
scopedNamespace: "" # Empty for cluster-wide access
scopedRBAC: false # Cluster-wide permissions
```
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
- Only create/update Kubernetes secrets in that namespace
- Only access deployments in that namespace
</Tab>
</Tabs>
The default configuration gives cluster-wide access:
```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)
## Custom Resource Definitions
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.
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 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>
```
</Tab>
<Tab title="Kubectl">
```
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/)
</Tabs>