Using kubernetes secrets.hashicorp.com with upgrade.cattle.io

Question

Pulumi · Accepted Answer

Creating and managing Kubernetes secrets is a common operation that ensures sensitive information like passwords, OAuth tokens, SSH keys, etc., are stored securely and used safely within a Kubernetes cluster.

HashiCorp Vault is a service for securely storing and accessing secrets. Vault can be integrated with Kubernetes, allowing for secrets to be read from Vault and written to Kubernetes as native Secret resources.

Rancher, which provides `upgrade.cattle.io`, is an open-source multi-cluster management platform for Kubernetes that simplifies the deployment and operation of Kubernetes clusters.

To use Kubernetes secrets with HashiCorp Vault and integrate them into Rancher-managed clusters for upgrades, we will perform the following steps:

1. Set up a Vault server and enable the Kubernetes authentication method.
2. Configure a Vault Kubernetes Secret backend role that defines which Kubernetes service accounts can access secrets.
3. Apply a Secret definition in Kubernetes that references the Vault secrets through an annotation.
4. Use Rancher to manage the deployment and upgrade strategies for the application using these secrets.

Below is a TypeScript Pulumi program that demonstrates how to create a Vault-backed Kubernetes secret and integrate it into a Rancher-managed resource for upgrades.

```typescript
import * as k8s from "@pulumi/kubernetes";
import * as vault from "@pulumi/vault";
import * as rancher2 from "@pulumi/rancher2";

// Create a provider for the desired Kubernetes cluster where the secrets will be used
const provider = new k8s.Provider("provider", { /* cluster-specific configuration */ });

// Configure the HashiCorp Vault provider
const vaultProvider = new vault.Provider("vault", { /* Vault-specific configuration */ });

// Create a Kubernetes Secret Backend Role in Vault
const secretBackendRole = new vault.kubernetes.SecretBackendRole("my-role", {
    backend: "kubernetes", // Make sure the Kubernetes backend is enabled and configured in Vault
    name: "my-role",
    boundServiceAccountNames: ["my-service-account"],
    boundServiceAccountNamespaces: ["default"],
    policies: ["my-policy"], // Reference to the Vault policies to assign
    ttl: "1h", // Set the default Time-To-Live for tokens generated for this role
}, { provider: vaultProvider });

// Example usage of the Rancher2 provider to perform upgrades through `upgrade.cattle.io`
const rancherProvider = new rancher2.Provider("rancher", { /* Rancher-specific configuration */ });
const clusterUpgrade = new rancher2.Cluster("cluster-upgrade", {
    name: "my-cluster",
    rancherKubernetesEngineConfig: {
        /* Configuration specific to rancher's kubernetes engine */
    },
    upgradeStrategy: {
        // Define the upgrade strategy for this cluster
        drain: true,
        maxUnavailableControlplane: "1",
        maxUnavailableWorker: "10%",
    },
}, { provider: rancherProvider });

// Create a Kubernetes Secret which references the Vault secret using annotations
const k8sSecret = new k8s.core.v1.Secret("vault-secret", {
    metadata: {
        annotations: {
            // Annotation to tell Kubernetes that the actual secret value should be retrieved from HashiCorp Vault
            "vault.hashicorp.com/agent-inject": "true",
            "vault.hashicorp.com/role": "my-role", // Reference to the Vault role created earlier
            "vault.hashicorp.com/agent-inject-secret-data": "path/to/secret", // The path where the Vault secret is stored
        },
        // ... other metadata properties ...
    },
    // The keys here are the keys that will be created in the Kubernetes secret.
    // The actual secret data will be populated by Vault based on the annotations.
    stringData: {
        // An empty placeholder since the data will come from Vault
    },
}, { provider });

// Output the resulting Secret name
export const secretName = k8sSecret.metadata.name;
```

In the above program:

1. We define providers for Kubernetes, Vault, and Rancher. These configurations are cluster-specific and must be filled out according to your setup.
2. We create a `SecretBackendRole` using the `vault.kubernetes.SecretBackendRole` resource which binds a service account to a Vault policy and specifies how Secret tokens should be created.
3. We create a Kubernetes Secret using the `k8s.core.v1.Secret` resource with annotations specifying how to inject secrets from Vault.
4. We specify an upgrade strategy in a Rancher `Cluster` resource using the `rancher2.Cluster` resource. This upgrades the cluster according to defined strategies.

Make sure to replace placeholders like `path/to/secret`, backend configuration, and other cluster-specific configuration fields with your actual setup details.

You'd typically manage Vault policies separately and ensure that your Vault server is correctly configured to communicate with Kubernetes. Also, ensure that the service account mentioned (`my-service-account`) exists and has the necessary permissions.
  
Lastly, the `upgrade.cattle.io` part is somewhat abstract in this context as the upgrade strategies and integration points would depend on how Rancher is interacting with these secrets for upgrades, which may involve further annotations or specific configurations within Rancher that refer to secret management policies.