Ben Ash

The current implementation of the VaultPKISecret CRD is constrained to issuing PKI certificates. Ideally it could be used to reach out to other Vault PKI endpoints, in a more general...

@koolhandluke - that's a great suggestion. We have had some internal discussion around its implementation, but currently have no concrete commitment to add it.

Hi @mprochowski, The current behavior is expected. The Vault Secrets Operator (VSO) will always access any credential provider e.g `ServiceAccount`, `Secret`, etc. in the K8s namespace of the referring VSO...

One other thing, worth noting is that the `default` `HCPAuth` in VSO's namespace is special, in that it acts as a fallback in the case where no `hcpAuthRef` is specified...

@duong-se please let is know if this still an issue for you. Just an FYI, VSO does not currently support Vault tokens that have a max_ttl set when syncing dynamic...

> BTW, this can now be done using a template: > > ```yaml > apiVersion: secrets.hashicorp.com/v1beta1 > kind: VaultPKISecret > metadata: > name: example > spec: > ... > destination:...

> Hi @benashz, does this [PR](https://github.com/hashicorp/vault-secrets-operator/pull/641) solved the max_ttl problem? @duong-se I don't believe it does. Adding general support for max_ttl'd tokens is something that we are planning to do.

> @benashz I can use it without max_ttl for database role and kubernetes max_ttl role. So I'll let this issue for supporting max_ttl. Hi @duong-se, as of v0.6.0, VSO supports...

Hi @jtv8, thank you for the detailed report. We will definitely look into getting an ideal fix out to address the issue. If you could confirm that you have set...

Hi @mixolapmati - if you set `spec.destination.create=false` the K8s Secret's lifecycle will no longer be tied to the VSO Secret* resource. That might be what you are after here?