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.

If you are already using the External Secrets operator, you can view the integration documentation for it here.

Install Operator

The operator can be install via Helm or kubectl

Install the latest Infisical Helm repository

helm repo add infisical-helm-charts 'https://dl.cloudsmith.io/public/infisical/helm-charts/helm/charts/' 
  
helm repo update

Install the Helm chart

To select a specific version, view the application versions here and chart versions here

helm install --generate-name infisical-helm-charts/secrets-operator 
# 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

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).

example-infisical-secret-crd.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:
    hostAPI: https://app.infisical.com/api
    resyncInterval: 10
    authentication:
        # Make sure to only have 1 authentication method defined, serviceToken/universalAuth.
        # If you have multiple authentication methods defined, it may cause issues.

        # (Deprecated) Service Token Auth
        serviceToken:
            serviceTokenSecretReference:
                secretName: service-token
                secretNamespace: default
            secretsScope:
                envSlug: <env-slug>
                secretsPath: <secrets-path>
                recursive: true

        # Universal Auth
        universalAuth:
            secretsScope:
                projectSlug: new-ob-em
                envSlug: dev # "dev", "staging", "prod", etc..
                secretsPath: "/" # Root is "/"
                recursive: true # Wether or not to use recursive mode (Fetches all secrets in an environment from a given secret path, and all folders inside the path) / defaults to false
            credentialsRef:
                secretName: universal-auth-credentials
                secretNamespace: default

        # Native Kubernetes Auth
        kubernetesAuth:
            identityId: <machine-identity-id>
            serviceAccountRef:
              name: <service-account-name>
              namespace: <service-account-namespace>

            # secretsScope is identical to the secrets scope in the universalAuth field in this sample.
            secretsScope:
                projectSlug: your-project-slug
                envSlug: prod
                secretsPath: "/path"
                recursive: true

        # AWS IAM Auth
        awsIamAuth:
            identityId: <your-machine-identity-id>

            # secretsScope is identical to the secrets scope in the universalAuth field in this sample.
            secretsScope:
                projectSlug: your-project-slug
                envSlug: prod
                secretsPath: "/path"
                recursive: true

        # Azure Auth
        azureAuth:
            identityId: <your-machine-identity-id>
            resource: https://management.azure.com/&client_id=CLIENT_ID # (Optional) This is the Azure resource that you want to access. For example, "https://management.azure.com/". If no value is provided, it will default to "https://management.azure.com/"

            # secretsScope is identical to the secrets scope in the universalAuth field in this sample.
            secretsScope:
                projectSlug: your-project-slug
                envSlug: prod
                secretsPath: "/path"
                recursive: true

        # GCP ID Token Auth
        gcpIdTokenAuth:
            identityId: <your-machine-identity-id>

            # secretsScope is identical to the secrets scope in the universalAuth field in this sample.
            secretsScope:
                projectSlug: your-project-slug
                envSlug: prod
                secretsPath: "/path"
                recursive: true

        # GCP IAM Auth
        gcpIamAuth:
            identityId: <your-machine-identity-id>

            # secretsScope is identical to the secrets scope in the universalAuth field in this sample.
            secretsScope:
                projectSlug: your-project-slug
                envSlug: prod
                secretsPath: "/path"
                recursive: true

    managedSecretReference:
        secretName: managed-secret
        secretNamespace: default
        creationPolicy: "Orphan" ## Owner | Orphan
        # secretType: kubernetes.io/dockerconfigjson


InfisicalSecret CRD properties

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:

Apply the Infisical CRD to your cluster

Once you have configured the Infisical CRD with the required fields, you can apply it to your cluster. After applying, you should notice that the managed secret has been created in the desired namespace your specified.

kubectl apply -f example-infisical-secret-crd.yaml

Verify managed secret creation

To verify that the operator has successfully created the managed secret, you can check the secrets in the namespace that was specified.

# Verify managed secret is created
kubectl get secrets -n <namespace of managed secret>

The Infisical secrets will be synced and stored into the managed secret every 1 minutes.

Using managed secret in your deployment

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

Auto redeployment

Deployments using managed secrets don’t reload automatically on updates, so they may use outdated secrets unless manually redeployed. To address this, we added functionality to automatically redeploy your deployment when its managed secret updates.

Enabling auto redeploy

To enable auto redeployment you simply have to add the following annotation to the deployment that consumes a managed secret

secrets.infisical.com/auto-reload: "true"

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. Then, for each deployment that has this annotation present, a rolling update will be triggered.

Global configuration

To configure global settings that will apply to all instances of InfisicalSecret, you can define these configurations in a Kubernetes ConfigMap. For example, you can configure all InfisicalSecret instances to fetch secrets from a single backend API without specifying the hostAPI parameter for each instance.

Available global properties

PropertyDescriptionDefault value
hostAPIIf hostAPI in InfisicalSecret instance is left empty, this value will be usedhttps://app.infisical.com/api

Applying global configurations

All global configurations must reside in a Kubernetes ConfigMap named infisical-config in the namespace infisical-operator-system. To apply global configuration to the operator, copy the following yaml into infisical-config.yaml file.

infisical-config.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: infisical-operator-system
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: infisical-config
  namespace: infisical-operator-system
data:
  hostAPI: https://example.com/api # <-- global hostAPI

Then apply this change via kubectl by running the following

kubectl apply -f infisical-config.yaml

Troubleshoot operator

If the operator is unable to fetch secrets from the API, it will not affect the managed Kubernetes secret. It will continue attempting to reconnect to the API indefinitely. The InfisicalSecret resource uses the status.conditions field to report its current state and any errors encountered.

$ kubectl get infisicalSecrets
NAME                     AGE
infisicalsecret-sample   12s

$ kubectl describe infisicalSecret infisicalsecret-sample
...
Spec:
...
Status:
  Conditions:
    Last Transition Time:  2022-12-18T04:29:09Z
    Message:               Infisical controller has located the Infisical token in provided Kubernetes secret
    Reason:                OK
    Status:                True
    Type:                  secrets.infisical.com/LoadedInfisicalToken
    Last Transition Time:  2022-12-18T04:29:10Z
    Message:               Failed to update secret because: 400 Bad Request
    Reason:                Error
    Status:                False
    Type:                  secrets.infisical.com/ReadyToSyncSecrets
Events:                    <none>

Uninstall Operator

The managed secret created by the operator will not be deleted when the operator is uninstalled.

Install Infisical Helm repository

helm uninstall <release name>

Useful Articles

Was this page helpful?