Using the InfisicalPushSecret CRD

Overview

The InfisicalPushSecret CRD allows you to create secrets in your Kubernetes cluster and push them to Infisical.

This CRD offers the following features:

Push Secrets from a Kubernetes secret into Infisical.
Manage secret lifecycle of pushed secrets in Infisical. When the Kubernetes secret is updated, the operator will automatically update the secrets in Infisical. Optionally, when the Kubernetes secret is deleted, the operator will delete the secrets in Infisical automatically.

Prerequisites

A project within Infisical.
A machine identity 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.

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

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

  kubectl apply -f source-secret.yaml

After applying the soruce-secret.yaml file, you are ready to apply the InfisicalPushSecret CRD.

  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

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.

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:

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.

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.

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:

infisical-push-secret.yaml
  push:
    secret:
      secretName: push-secret-demo
      secretNamespace: default

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

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.

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.

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:

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

The Kubernetes machine identity authentication method is used to authenticate with Infisical. The identity ID is stored in a field in the InfisicalPushSecret resource. This authentication method can only be used within a Kubernetes environment. Read more about 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.
autoCreateServiceAccountToken: If set to true, the operator will automatically create a short-lived service account token on-demand for the service account. Defaults to false.
serviceAccountTokenAudiences: Optionally specify audience for the service account token. This field is only relevant if you have set autoCreateServiceAccountToken to true. No audience is specified by default.

Example:

  spec:
    kubernetesAuth:
      identityId: <machine-identity-id>
      autoCreateServiceAccountToken: true # Automatically creates short-lived service account tokens for the service account.
      serviceAccountTokenAudiences:
        - <audience> # Optionally specify audience for the service account token. No audience is specified by default.
      serviceAccountRef:
        name: <secret-name>
        namespace: <secret-namespace>

The AWS IAM machine identity authentication method is used to authenticate with Infisical. Read more about AWS IAM Auth.

Valid fields:

identityId: The identity ID of the machine identity you created.

Example:

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

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.

Valid fields:

identityId: The identity ID of the machine identity you created.

Example:

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

The GCP IAM machine identity authentication method is used to authenticate with Infisical. The identity ID is stored in a field in the InfisicalPushSecret resource. This authentication method can only be used both within and outside GCP environments. Read more about Azure Auth.

Valid fields:

identityId: The identity ID of the machine identity you created.
serviceAccountKeyFilePath: The path to the GCP service account key file.

Example:

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

The GCP ID Token machine identity authentication method is used to authenticate with Infisical. The identity ID is stored in a field in the InfisicalPushSecret resource. This authentication method can only be used within GCP environments. Read more about Azure Auth.

Valid fields:

identityId: The identity ID of the machine identity you created.

Example:

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

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

Fields:

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:

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

Using templating to push secrets

Pushing secrets to Infisical from the operator may not always be enough. Templating is a useful utility of the Infisical secrets operator that allows you to use Go Templating to template the secrets you want to push to Infisical. Using Go templates, you can format, combine, and create new key-value pairs of secrets that you want to push to Infisical.

Define secret keys and their corresponding templates. Each data value uses a Golang template with access to all secrets defined in the push.secret.secretName Kubernetes secret.

Secrets are structured as follows:

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

Example template configuration:

# This example assumes that the `push-secret-demo` Kubernetes secret contains the following secrets:
# SITE_URL = "https://example.com"
# REGION = "us-east-1"
# OTHER_SECRET = "other-secret"

push:
  secret:
    secretName: push-secret-demo
    secretNamespace: default
    template:
      includeAllSecrets: true # Includes all secrets from the `push-secret-demo` Kubernetes secret
      data:
        SITE_URL: "{{ .SITE_URL.Value }}"
        API_URL: "https://api.{{.SITE_URL.Value}}.{{.REGION.Value}}.com" # Will create a new secret in Infisical with the key `API_URL` with the value of the `SITE_URL` and `REGION` secrets

To help transform your config map data further, the operator provides a set of built-in functions that you can use in your templates.

Available templating functions

Please refer to the templating functions documentation for more information.

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.

  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

Was this page helpful?

Suggest edits Raise issue

InfisicalSecret CRD InfisicalDynamicSecret CRD

On this page

Overview
Prerequisites
Example usage
InfisicalPushSecret CRD properties
Using templating to push secrets
Applying the InfisicalPushSecret CRD to your cluster

Infrastructure Integrations

App Connections

Secret Syncs

Native Integrations

CI/CD Integrations

Framework Integrations

Build Tool Integrations

Others

Using the InfisicalPushSecret CRD

Overview

Prerequisites

Example usage

InfisicalPushSecret CRD properties

Using templating to push secrets

Example template configuration:

Available templating functions

Applying the InfisicalPushSecret CRD to your cluster

Infrastructure Integrations

App Connections

Secret Syncs

Native Integrations

CI/CD Integrations

Framework Integrations

Build Tool Integrations

Others

​Overview

​Prerequisites

​Example usage

​InfisicalPushSecret CRD properties

​Using templating to push secrets

​Applying the InfisicalPushSecret CRD to your cluster

Overview

Prerequisites

Example usage

InfisicalPushSecret CRD properties

Using templating to push secrets

Applying the InfisicalPushSecret CRD to your cluster