crossplane-contrib/provider-jet-vault

Generated crossplane provider for vault

provider-jet-vault's Issues

Enable consuming an entire secret instead of a single key in Secret.generic.vault.jet.crossplane.io

What problem are you facing?

The Secret.generic.vault.jet.crossplane.io resource is automatically configured by Terrajet to use the SecretKeySelector type from crossplane-runtime. This type requires selecting a specific key from a secret.

This creates a heavy burden on platform-operators and/or development teams to explicitly create a Secret.generic.vault.jet.crossplane.io for every key in a connection detail they might need in their secret store.

How could Vault Provider help solve your problem?

Allow consuming all fields from a secret instead of individual keys, as in this example:

apiVersion: v1
kind: Secret
metadata:
  name: example-secret
  namespace: default
stringData:
  keyOne: valueOne
  keyTwo: valueTwo
type: Opaque

---
apiVersion: generic.vault.jet.crossplane.io/v1alpha1
kind: Secret
metadata:
  name: example-vault-secret
spec:
  forProvider:
    path: "secret/foo"
    dataSecretRef:
      name: example-secret
      namespace: default

The resulting secret in vault would look like this:

$ vault kv get secret/foo

===== Data =====
Key        Value
---        -----
keyone     valueone
keytwo     valuetwo

Enable submitting non-json data to Secret.generic.vault.jet.crossplane.io

What problem are you facing?

The vault_generic_secret resource expects data to be formatted as JSON. It uses the Keys of this json to name secret fields when submitting them to vault.

An example Kubernetes Secret:

apiVersion: v1
kind: Secret
metadata:
  name: example-secret
  namespace: default
stringData:
  exampleKey: '{"keyone": "valueone", "keytwo":"valuetwo"}'
type: Opaque

An example Vault Secret:

---
apiVersion: generic.vault.jet.crossplane.io/v1alpha1
kind: Secret
metadata:
  name: example-vault-secret
spec:
  forProvider:
    path: "secret/foo"
    dataJsonSecretRef:
      key: exampleKey
      name: example-secret
      namespace: default

The resulting secret in vault would look like this:

$ vault kv get secret/foo

===== Data =====
Key        Value
---        -----
keyone     valueone
keytwo     valuetwo

If the secret is not json-formatted, it will fail apply and not be created.

This creates several issues:

1. json-formatted secrets are often intended to be consumed as json, not parsed out.
2. ConnectionDetails which are not already json formatted cannot be submitted to vault.

How could Vault Provider help solve your problem?

Support submitting raw data to the resource via a dataSecretRef field. This field will signal the provider to json-encode the data and set this json-encoded string when submitting the resource for creation.

An example Kubernetes Secret:

apiVersion: v1
kind: Secret
metadata:
  name: example-secret
  namespace: default
stringData:
  exampleKey: 'I am a connection secret'
type: Opaque

An example Vault Secret:

---
apiVersion: generic.vault.jet.crossplane.io/v1alpha1
kind: Secret
metadata:
  name: example-vault-secret
spec:
  forProvider:
    path: "secret/foo"
    dataSecretRef:
      key: exampleKey
      name: example-secret
      namespace: default

The resulting secret in vault would look like this:

$ vault kv get secret/foo

===== Data =====
Key           Value
---           -----
exampleKey    'I am a connection secret'

Implementation

Adding the field can be achieved by adding a tfconfig.ResourceOption to the spec. This option is then included by updating the WithDefaultResourceFn.

What is less clear is how to perform the pre-parsing. @muvaf has suggested this would involve writing a new ExternalClient for the provider. There is an open issue to fully document this approach here.

Secret data is deleted, but not the secret path

What happened?

Created a generic secret and saw it placed in Vault at the desired path.
Deleted the secret.
The secret values were deleted, but the path entry was not.

If the secret is deleted in the cluster, it should be removed (path and all) from Vault.

How can we reproduce it?

See above steps.

What environment did it happen in?

Crossplane version: uxp-1.6.4-up.1
Provider version: v0.1.0

Project Status

Hello, I'm looking to manage as much of our infrastructure as possible from Crossplane.

To do so I would like to manage Vault policies and roles as well.

As far as I can tell this project is basically unused and unmaintained. Is that the case?

Further, the APIs do not seem to reflect even a fraction of the Terraform Vault provider's capabilities.

https://registry.terraform.io/providers/hashicorp/vault/latest/docs

I am currently just exploring using the Terraform Crossplane Provider directly for my use case, but if there's support I'd be interested in contributing to a full Vault provider.

Thank you!