Connect to Infisical

This article describes how to connect Infisical secret management platform  as a secret store to your Humanitec Operator setup.

Before you begin #

Before you begin, make sure you have the following resources and permissions:

• An Infisical organization and project set up to use as your secret store.
• If you are using different secret environments or projects in Infisical, you have to register each of them as a separate secret store.
• You have determined the required access level (read/write/no access) to the secret store for the Platform Orchestrator and the Humanitec Operator, respectively. See Architecture for guidance.
• You have installed and configured the Humanitec Operator on a Kubernetes cluster.
• You have created a dedicated machine identity with universal auth  and a client secret for that identity.
• You have access to the cluster via kubectl.

Prepare your environment #

1. Define the Client ID from machine Identity universal auth:

export INFISICAL_CLIENT_ID=<client-id>

2. Define the Client Secret from machine Identity universal auth:

export INFISICAL_CLIENT_SECRET=<client-secret>

3. Define the URL to access the Infisical instance. If you are using Infisical Cloud, the URL will be:

export INFISICAL_URL=https://app.infisical.com

4. Define the ID of the Infisical project you want to use. The project ID can be found in the URL when accessing the project via the Infisical UI or using the Infisical API :

export INFISICAL_PROJECT_ID=<project-id>

5. Define the environment slug where the secrets are located:

export INFISICAL_ENVIRONMENT=<environment-slug>

6. Define an ID for your secret store. This ID will later match the secret store registrations in the Operator and in the Platform Orchestrator:

export SECRET_STORE_ID=my-infisical

Store universal auth credentials as Kubernetes secrets #

Create a Kubernetes secret for the Operator to access the Infisical store:

kubectl create secret generic infisical-secret-store-creds \
  -n humanitec-operator-system \
  --from-literal=client_id=${INFISICAL_CLIENT_ID} \
  --from-literal=client_secret=${INFISICAL_CLIENT_SECRET}

Register the secret store with the Operator #

You have the option to make the secret store accessible cluster-wide, i.e. for all deployments onto the same Kubernetes cluster, or Environment-local, i.e. for the namespace of a particular Application Environment only.

A cluster-wide secret store is defined in the Operator namespace and can be referenced from all Deployments onto the cluster. An Environment-local store is defined in an Environment namespace and can only be referenced from Deployments into that namespace. The environment-local store therefore offers greater isolation of your secret store access.

This example shows how to automatically create an Environment-local secret store definition for your Deployments.

When resolving a secret reference, the Operator will first try to use an Environment-local secret store of the store ID defined in the reference, and fall back to using a cluster-wide secret store of the same ID if not found.

The default secret store must be a cluster-wide store. Any Environment-local store labelled default will not be used as such.

1. Create the secret store registration using the following command. Modify it according to your setup:

• If this is not your default secret store, omit the label app.humanitec.io/default-store
• If this is an Environment-local secret store, modify the metadata.namespace attribute to match the Environment namespace

kubectl apply -f - << EOF
apiVersion: humanitec.io/v1alpha1
kind: SecretStore
metadata:
  name: ${SECRET_STORE_ID}
  namespace: humanitec-operator-system
  labels:
    app.humanitec.io/default-store: "true"
spec:
  infisical:
    url: ${INFISICAL_URL}
    projectId: ${INFISICAL_PROJECT_ID}
    environment: ${INFISICAL_ENVIRONMENT}
    auth:
      universalAuth:
        clientIDSecretRef:
          name: infisical-secret-store-creds
          key: client_id
        clientSecretSecretRef:
          name: infisical-secret-store-creds
          key: client_secret
EOF

2. Confirm the secret store registration.

To confirm the secret store registration, and anytime you wish to check for registered secret stores, use the following command:

# Cluster-wide secret store
kubectl get secretstores -n humanitec-operator-system

# Environment-local secret store
kubectl get secretstores -n my-environment-namespace

Deregister the secret store #

Deregistering a secret store removes access to the store. It does not delete any secrets contained therein.

1. Deregister the secret store from the Operator

Use this command to deregister a secret store from the Operator. Note that only future deployments trying to reference the store are affected. Running deployments with existing secret mappings continue to work using the present secret values because the Operator has mapped them into Kubernetes secrets in the deployment’s target namespace.

# Cluster-wide secret store
kubectl delete secretstore ${SECRET_STORE_ID} -n humanitec-operator-system

# Environment-local secret store
kubectl delete secretstore ${SECRET_STORE_ID} -n my-environment-namespace

Make sure that exactly one cluster-wide secret store is the default secret store at all times on your cluster.

Removing access to the default secret store may cause disruptions for future deployments if Resource cookies have been stored there previously. Validate the existence of cookies, and when switching to a another default store, consider migrating them over to the new default store.

Resource Cookies #

Resource cookies are stored in the Infisical according to this pattern:

/cookies/<resource-gures-id>.<driver-org>.<driver>

Limitations #

• The current integration of Infisical does not allow writing secrets via the Humanitec Platform Orchestrator.

Next steps #

• Test the Humanitec Operator and secret store setup using these test cases.
• Perform the Update Resource Definitions for related Applications tutorial to verify your setup.
  • Ensure the sample Applications are being deployed to your Orchestrator-enabled cluster by adjusting the matching criteria for the cluster Resource.
  • Observe how custom resources of type workload and resource are being created on the cluster, and check their status sections.
  • Observe how the Operator writes operational state (“resource cookies”) into your default secret store.