plugin config injection to inflexible due to type check for config path

[Nexus2k]

Describe the bug:
We're trying to bring up our vault with the https://github.com/1Password/vault-plugin-secrets-onepassword plugin fully configured and working. The plugin however does need configuration set at path op/config. The code at https://github.com/banzaicloud/bank-vaults/blob/50de449474cd3dd86a6d585c953608cbe3769944/internal/vault/secrets_engines.go#L229 and subsequently at https://github.com/banzaicloud/bank-vaults/blob/50de449474cd3dd86a6d585c953608cbe3769944/internal/vault/secrets_engines.go#L166 however only allows to use the /config name for a fixed list of engine types but not for the type plugin. This should be clearly configurable and not be a fixed list imho.

Expected behaviour:
In the vault crd, accept the following:

  externalConfig:
    plugins:
      - plugin_name: op-connect
        command: op-connect
        sha256: 7ce3e44c1a5f17e5f9b8dafd7a4c604b86ea862a69e5d2f12684cb0f136f5ba2
        type: secret
    secrets:
      - path: op
        type: plugin
        plugin_name: op-connect
        configuration:
          config:
          - op_connect_host: "http://{{ .Values.op_connector_service }}.svc.cluster.local:8080"
          - op_connect_token: {{ .Values.op_connect_token }}

Steps to reproduce the bug:
If you use the config as stated above the vault-configurer complains that it's missing a "name" parameter below the config which would automatically lead it to use that name as path for the config. The onepassword-connect plugin however does need it's config to be written to op/config and no subpath/name is needed.

I've managed to come up with this workaround as a hack:

  externalConfig:
    plugins:
      - plugin_name: op-connect
        command: op-connect
        sha256: 7ce3e44c1a5f17e5f9b8dafd7a4c604b86ea862a69e5d2f12684cb0f136f5ba2
        type: secret
    secrets:
      - path: op
        type: plugin
        plugin_name: op-connect
      - path: op
        type: kv # We need to fool the code in accepting no config path
        configuration:
          config:
          - op_connect_host: "http://{{ .Values.op_connector_service }}.svc.cluster.local:8080"
          - op_connect_token: {{ .Values.op_connect_token }}

This tricks the vault-configurer into setting up the plugin path as type plugin and later thanks to type: kv being in the allow list for /config paths it accepts the config to be written there.
I personally would recommend to have a flag below configuration: or at the same level indicating no need for a subpath.

Additional context:
I also had issues with the plugin not being executable which I was able to backtrace to the disable_mlock: true config option which the default vault chart always sets but the bank-vault crd needs that explicitly set. Using the same helm chart defaults as the original vault setup would be helpful I think.

Environment details:

• Kubernetes version (e.g. v1.10.2): v1.22.8
• Cloud-provider/provisioner (e.g. AKS, GKE, EKS, PKE etc): GKE
• bank-vaults version (e.g. 0.4.17): v1.15.5
• Install method (e.g. helm or static manifests): helm
• Logs from the misbehaving component (and any other relevant logs): {"level":"error","msg":"error configuring vault: error configuring secret engines for vault: error adding secrets engines: error finding sub config data name for secret engine: op/config","time":"2022-04-29T09:30:12Z"}
• Resource definition (possibly in YAML format) that caused the issue, without sensitive data: see above

/kind bug

[github-actions]

Thank you for your contribution! This issue has been automatically marked as stale because it has no recent activity in the last 60 days. It will be closed in 20 days, if no further activity occurs. If this issue is still relevant, please leave a comment to let us know, and the stale label will be automatically removed.