https://garden.io logo
#🌱|help-and-getting-started
Deploying kubernetes resources controlled by operators
# 🌱|help-and-getting-started
l

lively-actor-89932

06/20/2023, 9:10 AM
While garden is happy to apply the kubernetes manifest, it normally insists on there being at least some kind of pod (
serviceResource
in the old
kubernetes
module, and
defaultTarget
in the new actions). It becomes cumbersome if the deployed thing is not a pod, but just a CRD-defined manifest, with a separately-deployed controller taking care of the actual pod. Would be nice if such workflows were nicely supported 🙂
q

quaint-dress-831

06/21/2023, 9:09 AM
Hey @lively-actor-89932, we already support applying arbitrary manifests e.g. this Dapr component CRD is perfectly valid
Copy code
yaml
kind: Deploy
type: kubernetes
name: azure-key-vault-secret-store
description: Dapr secret store to read Azure Key Vault secret
spec:
  manifests:
    - apiVersion: dapr.io/v1alpha1
      kind: Component
      metadata:
        name: azure-key-vault-secret-store
      spec:
        type: secretstores.azure.keyvault
        version: v1
        metadata:
        - name: vaultName
          value: ${actions.deploy.my-pulumi-azure-key-vault.outputs.keyVaultName}
        - name: azureTenantId
          value: ${actions.deploy.my-pulumi-azure-key-vault.outputs.tenantId}
        - name: azureClientId
          value: ${actions.deploy.my-pulumi-azure-key-vault.outputs.clientId}
        - name: azureClientSecret
          secretKeyRef:
            name: ${actions.deploy.my-pulumi-azure-key-vault.outputs.secretName}
            # The stringData field is never output when reading from the API.
            key: client-secret