helm: integrate PostgreSQL

[flavio]

This is a first step to make our helm chart aware of PostgreSQL.

This is the user experience we want to achieve:

• By default, we take care of creating a PostgreSQL that is used by SBOMbastic
• The user can disable the creation of the database and just point us to an existing one to be used

Acceptance criteria

• By default a PostgreSQL database is created, these are its requirements:
  • Must be persistent
  • Credentials must be randomly created and stored inside of a Secret
  • Connection must be secured with a certificate that is generated by cert-manager
  • Certificate rotation must be handled
• The user can disable the creation of the PostgreSQL database and point use to an existing one. The user must also point us to a Secret that contains the user credentials. It also must provide us a ConfigMap the holds the CA used to validate the TLS endpoint
• All the data (Secrets, ConfigMaps) are mounted into the storage pods
• Ensure everything works smoothly inside of the tilt dev environment
• The CNPG instances and storage (class and size) are tunable
• The user can opt-out from the CNPG cluster creating and provide their own secret

[pohanhuangtw]

Hi @flavio

Based on the CloudNativePG documentation, deploying CNPG actually involves two separate Helm charts:

1. Operator chart (cnpg/cloudnative-pg)

   • Installs the CRD definitions and the controller that will reconcile our database Pods.

2. Cluster chart (cnpg/cluster)

   • Installs the Cluster CustomResource, which the operator then turns into actual PostgreSQL Pods.

---

Why add the Cluster as the dependency?

1. Ensure the customer can smoothly landing

   • If the operator is used as a dependency, Sbombastic must wait until the PostgreSQL cluster is fully installed by customer before the storage component becomes fully functional.

2. Protect the Cluster CR from accidental deletion

   • By installing the CRDs first (via the operator chart), the API server knows about Cluster before we ever apply it.
   • If we ever uninstall or upgrade without that ordering, Helm or a user could accidentally remove the CRD and the CR, losing our custom resource (unless its PVCs are retained).

3. Simplify mTLS certificate setup for users

   • We generate and inject the server/client certificates (via cert-manager) as part of the cluster chart.
   • By making the Cluster chart as dependency, we ensure those secrets and Issuers exist first—users don’t have to manually create certs before spinning up their database.

Why add the Operator as the dependency?

1. minimal setup
   • just needs to expose the necessary filed for storage, keeping our Helm templates concise and easy to read.
   • As for the cluster / cert-manager, we can provide a guide line for them to install.

---

The benefits of Cluster as the dependency

• Reliable installs: helm upgrade --install sbombastic … will always work, no extra kubectl apply steps or manual cert generation.
• Clear developer/user experience: Everything comes up in the right order, and our docs can simply say “run this one command.”

---

Next steps

• I’ll update the Quick-Start guide to document the ordering and manual cleanup steps.

Please let me know if this ordering makes sense or if you’d like to discuss any alternative!

Thanks!

[pohanhuangtw]

Summary for Issue #287

We have decided on the following installation and configuration flow for SBOMbastic:

1. CNPG Operator Installation:
   Users must install the CloudNativePG (CNPG) operator before installing SBOMbastic.

2. Secure Communication (mTLS):
   The connection between the CNPG cluster and the SBOMbastic application requires mutual TLS (mTLS) and server authentication.

3. Cluster Provisioning Options:
   Users can choose one of the following:

   • We provision the cluster:
     In this case, we will use cert-manager to issue and manage certificates for mTLS.
   • User-provided cluster:
     If users bring their own cluster, they must create and provide a client certificate so SBOMbastic can authenticate via mTLS.