Storing AI API Keys with Kubernetes SecretProviderClass

Question

Pulumi · Accepted Answer

In Kubernetes, a Secret is an object that contains a small amount of sensitive data such as passwords, tokens, or keys. The purpose of using a `Secret` is to manage sensitive information separately from the Pods and to reduce the risk of exposing it.

When using Kubernetes in cloud environments, one approach to managing secrets is to integrate a Kubernetes cluster with a cloud provider's secret management system, such as AWS Secrets Manager, Azure Key Vault, or Google Secret Manager. This integration can be facilitated through the use of a `SecretProviderClass`, which is a Kubernetes custom resource provided by the Secrets Store CSI driver. The SecretProviderClass allows you to reference external secrets and make them available to your Kubernetes applications.

Here's how it works:

1. You deploy the Secrets Store CSI driver in your Kubernetes cluster.
2. You create a SecretProviderClass that references the external secrets in the cloud provider's secret manager.
3. You mount the secrets into your Pods as volumes or environment variables by referencing the SecretProviderClass.

Let's assume you are using Azure Key Vault. The configuration steps would typically include:
- Setting up an Azure Key Vault and storing secrets in it.
- Setting up permissions for the Kubernetes cluster to access the Azure Key Vault.
- Deploying the Secrets Store CSI driver in the Kubernetes cluster.
- Creating a `SecretProviderClass` resource that specifies how secrets should be fetched from Azure Key Vault.
- Creating a Pod that references the `SecretProviderClass` and mounts the secrets.

Below is a Pulumi program written in Python that demonstrates how to create a Kubernetes Secret using a `SecretProviderClass`. This program assumes that you have already set up the Azure Key Vault, installed and configured necessary permissions, and you have the Secrets Store CSI driver installed in your Kubernetes cluster.

```python
import pulumi
import pulumi_kubernetes as kubernetes

# Create a Kubernetes SecretProviderClass resource
# This example assumes that you have already set up Azure Key Vault and installed Secrets Store CSI Driver in the cluster.
secret_provider_class = kubernetes.apiextensions.CustomResource(
    "ai-api-keys-secret-provider-class",
    api_version="secrets-store.csi.x-k8s.io/v1",
    kind="SecretProviderClass",
    metadata=kubernetes.meta.v1.ObjectMetaArgs(
        name="azure-kvname",
    ),
    spec={
        "provider": "azure",
        "parameters": {
            "usePodIdentity": "false",  # Set to "true" if using Pod Identity
            "keyvaultName": "my-key-vault",  # Name of the Azure Key Vault
            "cloudName": "AzurePublicCloud",  # Name of the Azure cloud
            "objects": [{
                "objectName": "apikey",  # Name of the secret in Azure Key Vault
                "objectType": "secret",  # Type of the secret (could also be "key" or "cert")
                "objectVersion": "",  # Version of the secret (optional)
            }],
            "resourceGroup": "my-rg",  # Name of the resource group containing the Key Vault
            "subscriptionId": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",  # Subscription ID
            "tenantId": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",  # Tenant ID
        },
    },
    opts=pulumi.ResourceOptions(depends_on=[/* other resources such as CSI driver if not already present */])
)

# You can now reference this SecretProviderClass in your Pod definitions 
# to mount Azure Key Vault secrets as volumes.
```

Here's an explanation of the code:

- We import the required Pulumi modules for Kubernetes.
- We define a `SecretProviderClass` custom resource. The name, apiVersion, and kind are all specific to the Secrets Store CSI driver.
- The `spec` section contains all of the necessary parameters to connect to Azure Key Vault including the vault name, the secret object, and Azure-specific settings such as the cloud name, subscription ID, and tenant ID.
- The `usePodIdentity` flag specifies whether to use Azure AD Pod Identity to manage the identity of the pods. If set to `false`, you would typically use a service principal.
- The `objects` section contains a list of secret objects you want to fetch from Azure Key Vault.

Remember, this is a high-level configuration and would require additional specific details about your environment. You should replace placeholder values such as `my-key-vault`, `my-rg`, `subscriptionId`, and `tenantId` with your actual Azure details.

The deployment and management of the Secrets Store CSI driver and the actual secrets themselves in Azure Key Vault are beyond the scope of this Pulumi code example but are prerequisites for the `SecretProviderClass` to function properly.

After this setup with `SecretProviderClass`, you can reference it in the Pod definition to mount the imported secrets as volumes, allowing your applications to consume the secrets securely.