mbp-935: Configure Vault to support JWT authentication

[mlorenzofr]

This is the first draft to automate the JWT/SPIFFE configuration of Vault.

To configure Vault JWT authentication parameters, we can change the settings in the clusterGroup.applications.vault.jwt attribute, in the values-hub.yaml file:

  applications:
    vault:
      name: vault
      namespace: vault
      project: hub
      chart: hashicorp-vault
      chartVersion: 0.1.*
      jwt:
        enabled: true
        oidcDiscoveryUrl: https://oidc-discovery.apps.{{ $.Values.global.clusterDomain }}
        oidcDiscoveryCa: /run/secrets/kubernetes.io/serviceaccount/service-ca.crt
        defaultRole: qtodo
        roles:
          - name: qtodo
            audience: qtodo
            subject: spiffe://apps.{{ $.Values.global.clusterDomain }}/ns/qtodo/sa/qtodo
            policies:
              - global-secret

If enabled, it will cause the Ansible tasks included in the vault_jwt.yaml file (rhvp.cluster_utils) to run to configure JWT authentication in Vault.

Although I've added the oidcDiscoveryCa and policies fields to the roles, this part isn't fully implemented in Ansible, as there are some issues with the current version of ZTWIM. I'll leave this for future versions.

wdyt?

[mlorenzofr]

@posip-redhat @sabre1041

[sabre1041]

@mlorenzofr Ran into a failure attempting to execute the PR

TASK [rhvp.cluster_utils.vault_utils : Write JWT configuration] *************************************************************************************************************************************************************************************
fatal: [localhost]: FAILED! => {"changed": true, "rc": 2, "return_code": 2, "stderr": "Error writing data to auth/jwt/config: Error making API request.\n\nURL: PUT https://vault.vault.svc.cluster.local:8200/v1/auth/jwt/config\nCode: 400. Errors:\n\n* error checking oidc discovery URL\n", "stderr_lines": ["Error writing data to auth/jwt/config: Error making API request.", "", "URL: PUT https://vault.vault.svc.cluster.local:8200/v1/auth/jwt/config", "Code: 400. Errors:", "", "* error checking oidc discovery URL"], "stdout": "", "stdout_lines": []}

The challenge is that logic in the rhvp.cluster_utils collection for enabling JWT auth assumes the default router certificate is being used. However, on clusters where custom certificates (either at the router, route or pod level) are used, this will fail..

Given the various options for how a certificate could be sourced, an alternate solution could be to retrieve the remote certificate and use the retrieved certificate in the auth configuration

[mlorenzofr]

The challenge is that logic in the rhvp.cluster_utils collection for enabling JWT auth assumes the default router certificate is being used. However, on clusters where custom certificates (either at the router, route or pod level) are used, this will fail..

Given the various options for how a certificate could be sourced, an alternate solution could be to retrieve the remote certificate and use the retrieved certificate in the auth configuration

Okay. I'll implement it as you suggested, using the same certificate served by the endpoint as the CA for validation.

[mlorenzofr]

@sabre1041

I have created a new PR in the rhvp.cluster_utils to implement the changes. Since tomorrow is a US holiday, it may take some time for review and approval.

I have built a version of the utility container with these changes for my testing, and it can also be used to validate these changes in our project.

To use the utility container build with the suggested changes:

export PATTERN_UTILITY_CONTAINER=quay.io/mlorenzofr/utility-container

I used the svc name spire-spiffe-oidc-discovery-provider in my tests and it worked fine:

 oidcDiscoveryUrl: https://spire-spiffe-oidc-discovery-provider.zero-trust-workload-identity-manager.svc.cluster.local

[sabre1041]

This looks really good. Also great collaboration with the VP team on working to integrate changes upstream.

Tested using a container that @mlorenzofr built containing updated content to be integrated upstream.

Set the following prior to running the pattern

export PATTERN_UTILITY_CONTAINER=quay.io/mlorenzofr/utility-container

Also utilized some of the steps as described here to work around ZTWIM TP1 challenges:

1. Execute pattern install
2. Stop execution when attempting to verify Vault is active
3. Wait until Argo CD has deployed ZTWIM
4. Apply TP1 adjustments (starting with Kyverno steps)
5. Rerun pattern install

[sabre1041]

This is great for ZTWIM TP1. We will need to revisit the necessary changes for TP2

[sabre1041]

LGTM