Skip to content

multi-tier.md

Latest commit

 

History

History
84 lines (56 loc) · 6.65 KB

multi-tier.md

File metadata and controls

84 lines (56 loc) · 6.65 KB

Secure Multi-tier Application Use Case

One of the most common application design patterns makes use of a frontend application leveraging a database for persistent storage. Instead of traditional methods for accessing the database from the frontend application using static values stored within the application, this pattern will make use "just in time" methods for obtaining these database values from a credential store. A more detailed overview is located below:

  • qtodo - Quarkus based frontend application. Access is protected via OIDC based authentication with users defined within an external identity store (Red Hat Build of Keycloak by default)
  • PostgreSQL - Relational database for use by the qtodo application. Credentials are generated dynamically and stored within Vault.
  • External Identity store - Users have been defined to enable access to the qtodo frontend. OIDC clients have also been created and configured within the todo application
  • HashiCorp Vault - Several features are being leveraged within this use case for the external identity store
    • Secrets store - Storage of sensitive values for components including PostgreSQL and RHBK
    • JWT based authentication - Enables access using ZTWIM based identities
  • Zero Trust Workload Identity - Enables an identity to be assigned to the qtodo application to communicate with HashiCorp Vault and obtain the credentials to access the PostgreSQL database
    • spiffe-helper - Supplemental component provided for the qtodo application to dynamically fetch JWT based identities from the SPIFFE Workload API.

Investigating the qtodo Application in depth

With an understanding of the goals and architecture of qtodo, launch the OpenShift Console of the Hub cluster and navigate to the qtodo project

  1. Select Home -> Projects from the left hand navigation bar
  2. Locate and select the qtodo project

The qtodo Quarkus application and qtodo-db PostgreSQL database are found within this namespace.

View the running pods associated with these components

  1. Select Workloads -> Pods from the left hand navigation bar
  2. Explore both the qtodo and qtodo-db pods.

Take note that the qtodo Pod makes use of a series of init containers and sidecar containers that are used to supply the application with credentials needed to support the application.

Access the qtodo application in a browser. The URL can be located from the OpenShift Route in the qtodo Project

  1. Select Networking -> Routes from the lefthand navigation bar
  2. Click the arrow next to the the URL underneath the Location column to open the qtodo application in a new browser tab

You will be presented with a login page to access the application. When using the default External Identity Provider (RHBK), two users (qtodo-admin and qtodo-user1) were provisioned automatically. Their initial credentials are stored in a Secret in the keycloak-system namespace called keycloak-users. You can reveal the credentials by switching to the tab containing the OpenShift Console using the following steps:

  1. Select Home -> Projects from the left hand navigation bar
  2. Locate and select the keycloak-system project
  3. Select Workloads -> Secrets from the left hand navigation bar
  4. Select the keycloak-users Secret
  5. Click the Reveal values link to uncover the underlying values for the users

Switch back to the qtodo application and enter the username and password on the login page for one of the users using the values discovered previously.

Once you have authenticated to RHBK, you will be instructed to change the temporary password and set a more permanent password. Once complete, you will be redirected to the qtodo application verifying the OIDC based authentication functions properly.

Feel free to add new items to the list of todos. By being able to add and remove items from the page, the integration between the Quarkus application and the backend PostgreSQL database using credentials sourced from HashiCorp Vault was successful.

TLS Termination Options

The qtodo application uses reencrypt TLS termination on the OpenShift Route by default, ensuring that traffic is encrypted end-to-end from the client to the pod. Ingress TLS communication is terminated at the OpenShift Router and reencrypted with a certificate generated using the Service Serving Certificate feature.

Configuration

The qtodo Helm chart provides options to control how and where TLS communication is terminated:

  • app.route.termination — Specifies the TLS termination type for the OpenShift Route

    • reencrypt (default) — TLS is terminated at the Router and reencrypted to the pod using the certificate specified in app.tls.secret
    • passthrough — TLS traffic passes through the Router without decryption and is terminated at the pod
    • edge — TLS is terminated at the Router; backend communication uses HTTP

  • app.securePort — The HTTPS port used by the application (default: 8443)

    • Used when app.route.termination is set to reencrypt or passthrough

  • app.insecurePort — The HTTP port used by the application (default: 8080)

    • Used when app.route.termination is set to edge or when TLS is disabled

  • app.tls.secret — Name of the Kubernetes Secret containing the TLS certificate and key (default: qtodo-tls)

    • Used for pod-level TLS termination with reencrypt or passthrough routes

  • app.tls.serviceServing — Enable automatic certificate generation via Service Serving Certificates (default: true)

    • When enabled, OpenShift automatically generates and rotates the certificate in app.tls.secret
    • When using custom certificates (e.g., for passthrough mode), set this to false and provide your own certificate in the secret

Termination Types

Termination Type TLS at Router TLS to Pod Certificate Source Use Case
reencrypt (default) Yes Yes Service Serving Certificate End-to-end encryption with automatic cert rotation
passthrough No Yes User-provided in app.tls.secret Custom certificates or strict no-decrypt requirement
edge Yes No Route certificate Legacy apps without TLS support

Note

When using passthrough termination with custom certificates, ensure the certificate's Subject Alternative Name (SAN) matches the Route hostname. The Service Serving Certificate feature cannot be used in this mode.