crossplane-contrib/provider-jet-vault

Generated crossplane provider for vault

Terrajet Vault Provider

provider-jet-vault is a Crossplane provider that is built using Terrajet code generation tools and exposes XRM-conformant managed resources for the Vault API.

Getting Started

Install the provider by using the following command after changing the image tag to the latest release:

kubectl crossplane install provider crossplane/provider-jet-vault:v0.1.0

You can see the API reference here.

Developing

Run code-generation pipeline:

go run cmd/generator/main.go

Run against a Kubernetes cluster:

make run

Build, push, and install:

make all

Build image:

make image

Push image:

make push

Build binary:

make build

Report a Bug

For filing bugs, suggesting improvements, or requesting new features, please open an issue.

Contact

Please use the following to reach members of the community:

• Slack: Join our slack channel
• Forums: crossplane-dev
• Twitter: @crossplane_io
• Email: [email protected]

Governance and Owners

provider-jet-vault is run according to the same Governance and Ownership structure as the core Crossplane project.

Code of Conduct

provider-jet-vault adheres to the same Code of Conduct as the core Crossplane project.

Licensing

provider-jet-vault is under the Apache 2.0 license.

provider-jet-vault's Issues

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!

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

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