Kubernetes Operator

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.

http://<backend-svc-name>.<namespace>.svc.cluster.local:4000/api

This property defines the time in seconds between each secret re-sync from Infisical. Shorter time between re-syncs will require higher rate limits only available on paid plans. Default re-sync interval is every 1 minute.

This block defines the TLS settings to use for connecting to the Infisical instance.

This block defines the reference to the CA certificate to use for connecting to the Infisical instance with SSL/TLS.

The name of the Kubernetes secret containing the CA certificate to use for connecting to the Infisical instance with SSL/TLS.

The namespace of the Kubernetes secret containing the CA certificate to use for connecting to the Infisical instance with SSL/TLS.

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.

This block defines the method that will be used to authenticate with Infisical so that secrets can be fetched

The universal machine identity authentication method is used to authenticate with Infisical. The client ID and client secret needs to be stored in a Kubernetes secret. This block defines the reference to the name and namespace of secret that stores these credentials.

  kubectl create secret generic universal-auth-credentials --from-literal=clientId="<your-identity-client-id>" --from-literal=clientSecret="<your-identity-client-secret>"

Example

apiVersion: secrets.infisical.com/v1alpha1
kind: InfisicalSecret
metadata:
  name: infisicalsecret-sample-crd
spec:
  authentication:
      universalAuth:
          secretsScope:
              projectSlug: <project-slug> # <-- project slug
              envSlug: <env-slug> # "dev", "staging", "prod", etc..
              secretsPath: "<secrets-path>" # Root is "/"
          credentialsRef:
              secretName: universal-auth-credentials # <-- name of the Kubernetes secret that stores our machine identity credentials
              secretNamespace: default # <-- namespace of the Kubernetes secret that stores our machine identity credentials
  ...

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.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: infisical-auth
  namespace: default

kubectl apply -f infisical-service-account.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: role-tokenreview-binding
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:auth-delegator
subjects:
  - kind: ServiceAccount
    name: infisical-auth
    namespace: default

kubectl apply -f cluster-role-binding.yaml

apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
  name: infisical-auth-token
  annotations:
    kubernetes.io/service-account.name: "infisical-auth"

kubectl apply -f service-account-token.yaml

kubectl patch serviceaccount infisical-auth -p '{"secrets": [{"name": "infisical-auth-token"}]}' -n default

kubectl get secret infisical-auth-token -n default -o=jsonpath='{.data.token}' | base64 --decode

Example

apiVersion: secrets.infisical.com/v1alpha1
kind: InfisicalSecret
metadata:
  name: infisicalsecret-sample-crd
spec:
  authentication:
      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
  ...

The AWS 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 within an AWS environment like an EC2 or a Lambda function.

Example

apiVersion: secrets.infisical.com/v1alpha1
kind: InfisicalSecret
metadata:
  name: infisicalsecret-sample-crd
spec:
  authentication:
      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
  ...

The Azure 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 an Azure environment.

Example

apiVersion: secrets.infisical.com/v1alpha1
kind: InfisicalSecret
metadata:
  name: infisicalsecret-sample-crd
spec:
  authentication:
      azureAuth:
          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
  ...

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.

Example

apiVersion: secrets.infisical.com/v1alpha1
kind: InfisicalSecret
metadata:
  name: infisicalsecret-sample-crd
spec:
  authentication:
      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
  ...

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.

Example

apiVersion: secrets.infisical.com/v1alpha1
kind: InfisicalSecret
metadata:
  name: infisicalsecret-sample-crd
spec:
  authentication:
      gcpIamAuth:
          identityId: <your-machine-identity-id>
          serviceAccountKeyFilePath: "/path/to-service-account-key-file-path.json"

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

The service token required to authenticate with Infisical needs to be stored in a Kubernetes secret. This block defines the reference to the name and namespace of secret that stores this service token. Follow the instructions below to create and store the service token in a Kubernetes secrets and reference it in your CRD.

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. Make sure you replace <your-service-token-here> with your service token.

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

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
      secretsScope:
        envSlug: <env-slug> # "dev", "staging", "prod", etc..
        secretsPath: <secrets-path> # Root is "/"
  ...

The managedSecretReference field is used to define the target location for storing secrets retrieved from an Infisical project. This field requires specifying both the name and namespace of the Kubernetes secret that will hold these secrets. The Infisical operator will automatically create the Kubernetes secret with the specified name/namespace and keep it continuously updated.

Note: The managed secret be should be created in the same namespace as the deployment that will use it.

The name of the managed Kubernetes secret to be created

The namespace of the managed Kubernetes secret to be created.

Override the default Opaque type for managed secrets with this field. Useful for creating kubernetes.io/dockerconfigjson secrets.

Templates enable you to transform data from Infisical before storing it as a Kubernetes Secret.

When set to true, this option injects all secrets retrieved from Infisical into your configuration. Secrets defined in the template will override the automatically injected secrets.

Define secret keys and their corresponding templates. Each data value uses a Golang template with access to all secrets retrieved from the specified scope.

Secrets are structured as follows:

type TemplateSecret struct {
    Value      string `json:"value"`
    SecretPath string `json:"secretPath"`
}

Example template configuration:

  managedSecretReference:
    secretName: managed-secret
    secretNamespace: default
    template:
      includeAllSecrets: true
      data:
        NEW_KEY: "{{ .KEY1.SecretPath }} {{ .KEY1.Value }}"

When you run the following command:

kubectl get secret managed-secret -o jsonpath='{.data}'

You’ll receive Kubernetes secrets output that includes the NEW_KEY:

{... "KEY":"d29ybGQ=","NEW_KEY":"LyBoZWxsbw=="}

When you set includeAllSecrets as false the Kubernetes secrets outputs will be:

{"NEW_KEY":"LyBoZWxsbw=="}

Creation polices allow you to control whether or not owner references should be added to the managed Kubernetes secret that is generated by the Infisical operator. This is useful for tools such as ArgoCD, where every resource requires an owner reference; otherwise, it will be pruned automatically.

Available options

• Orphan (default)
• Owner

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:

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

This will take all the secrets from your managed secret and expose them to your container

  envFrom:
    - secretRef:
        name: managed-secret # managed secret name
  ```

  Example usage in a deployment
  ```yaml
  apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        envFrom:
        - secretRef:
            name: managed-secret # <- name of managed secret
        ports:
        - containerPort: 80

This will allow you to select individual secrets by key name from your managed secret and expose them to your container

env:
  - name: SECRET_NAME # The environment variable's name which is made available in the container
    valueFrom:
      secretKeyRef:
        name: managed-secret # managed secret name
        key: SOME_SECRET_KEY # The name of the key which  exists in the managed secret

Example usage in a deployment

apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers: - name: nginx
image: nginx:1.14.2
env: - name: STRIPE_API_SECRET
valueFrom:
secretKeyRef:
name: managed-secret # <- name of managed secret
key: STRIPE_API_SECRET
ports: - containerPort: 80

This will allow you to create a volume on your container which comprises of files holding the secrets in your managed kubernetes secret

volumes:
  - name: secrets-volume-name # The name of the volume under which secrets will be stored
    secret:
      secretName: managed-secret # managed secret name

You can then mount this volume to the container’s filesystem so that your deployment can access the files containing the managed secrets

volumeMounts:
  - name: secrets-volume-name
    mountPath: /etc/secrets
    readOnly: true

Example usage in a deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.14.2
          volumeMounts:
            - name: secrets-volume-name
              mountPath: /etc/secrets
              readOnly: true
          ports:
            - containerPort: 80
      volumes:
        - name: secrets-volume-name
          secret:
            secretName: managed-secret # <- managed secrets

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.

http://<backend-svc-name>.<namespace>.svc.cluster.local:4000/api

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:

resyncInterval: 5s # 10 seconds
resyncInterval: 10s # 10 seconds
resyncInterval: 5m # 5 minutes
resyncInterval: 1h # 1 hour
resyncInterval: 1d # 1 day

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.

spec:
  updatePolicy: Replace

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.

spec:
  deletionPolicy: Delete

The destination field is used to specify where you want to create the secrets in Infisical. The required fields are projectId, environmentSlug, and secretsPath.

spec:
  destination:
    projectId: <project-id>
    environmentSlug: <env-slug>
    secretsPath: <secrets-path>

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.

  push:
    secret:
      secretName: push-secret-demo
      secretNamespace: default

  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

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.

  # infisical-push-secret.yaml
  spec:
    universalAuth:
      credentialsRef:
        secretName: <secret-name> 
        secretNamespace: <secret-namespace>

  # 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>

  spec:
    kubernetesAuth:
      identityId: <machine-identity-id>
      serviceAccountRef:
        name: <secret-name>
        namespace: <secret-namespace>

  spec:
    authentication:
      awsIamAuth:
        identityId: <machine-identity-id>

  spec:
    authentication:
      azureAuth:
        identityId: <machine-identity-id>

  spec:
    gcpIamAuth:
      identityId: <machine-identity-id>
      serviceAccountKeyFilePath: </path-to-service-account-key-file.json>

  spec:
    gcpIdTokenAuth:
      identityId: <machine-identity-id>

This block defines the TLS settings to use for connecting to the Infisical instance.

Fields:

  tls:
    caRef:
      secretName: custom-ca-certificate
      secretNamespace: default
      key: ca.crt