x-rh-swatch-psk is intended to used by other services connecting to swatch's apis. Instead, internal api calls should emulate either:

• x-rh-identity for an Associate
• x-rh-identity for an X509 (service account) principal

This functionality is nicely contained in internal_apis/{}init{}.py.  The first bullet point is essentially already covered in the code.  The X509 authentication is going to be the larger piece of work.  The code in the `_get_headers` method will need to be modified to construct an x-rh-identity header that holds X509 certificate information.  The structure of the header is defined here.  It will look something like this

{
  "identity": {
    "auth_type": "X509",
    "type": "X509",
    "x509": {
      "issuer_dn": "/O=Red Hat/OU=prod/CN=Certificate Authority",
      "subject_dn": "/DC=com/DC=redhat/OU=messaging/OU=serviceusers/UID=msg-swatch-turnpike/L=stage/CN=msg-swatch-turnpike"
    }
  }
}

I'm unclear whether or not there will need to be a "service_account" attribute in the header or not.  The identity header specification supports that but I'm not sure if it is required.

It's also unclear to me whether we should be doing a true test over an actual TLS connection with mutual authentication or if we should just be emulating the post-TLS termination phase where authentication information is just encoded into the header.

Steps for true X509 testing

1. Write IQE code to pull an X509 certificate and secret key from a file specified in the YAML configuration file
2. Write Python code to parse the certificate and extract the issuer DN and subject DN from the certificate.  Place this and a means to generate an X509 header in auth_utils.py
3. Either update _get_headers to construct an X509 header if no authentication is otherwise provided or modify existing invocations to call to add the X509 header.
4. Remove usage of the x-rh-swatch-psk header from _get_header
5. Modify the call method to add mTLS to the REST call
6. Ensure that the service account certificate and key are present in the ephemeral environments in a secret, that they are mounted into the IQE pod, and that the IQE configuration is set to reference them

Steps for simulated post-TLS termination testing:

1. Create method in auth_utils.py to construct an X509 authentication header that can take a provided subject DN.  The issuer DN should probably just be a static configuration value set to /O=Red Hat/OU=prod/CN=Certificate Authority by default.
2. Either update _get_headers to construct an X509 header if no authentication is otherwise provided or modify existing invocations to call to add the X509 header.
3. Remove usage of the x-rh-swatch-psk header from _get_headers

Acceptance Criteria

• Add a method to IQE utils to construct and use the x-rh-identity header with placeholder X509 information 
• Determine if TLS termination happens before it gets to our pods
• IQE shouldn't pull in the existing psk value from vault or anywhere anymore swatch-psk / swatch_psk reference