[FEATURE] Helm Chart option to use existing resources

[jeremymcgee73]

It would be nice to be able to use existing resources with this helm chart. I would like to use my existing postgres database, Keycloak instance, and ingress controller/class. Also, you should be able to use existing secrets, so there aren't secret values stored in the values file.

I also could see this as a step towards getting OpenRMF as an app in Platform Ones Big Bang. Feel free to reach out if anyone wants to talk privately.

[DaleBinghamSoteriaSoft]

You should be able to right now use the dnsNameKeycloak and identityProviderURL to make it go to an existing Keycloak. Check those in the values.yaml file.

You will want a separate realm for openrmf to point to with the identityProviderRealm and ensure the roles and script at are setup with the proper script from https://github.com/Cingulara/openrmf-docs/blob/master/deployments/kubernetes/setup-realm.sh.

Feel free to do a fork and update the secrets as you see fit for options.

The OpenRMF OSS open source one will not realistically go in Platform One. That is not on the roadmap to worry about. OpenRMF Professional may in the future as that is. There is already a USAF CTF for OpenRMF Professional.

[jeremymcgee73]

Yeah I saw those. But, there isn't a conditional on the Keycloak deployment, so it will still be created. We were just wanting to demo this in our existing k8s environment quickly.

https://github.com/Cingulara/openrmf-docs/blob/master/deployments/chart/openrmf/templates/keycloak.yaml

Thanks for your quick response!

[DaleBinghamSoteriaSoft]

Right. It tries to regardless you cannot "turn it off" in essence. You can run the helm template and generate the files and adjust in the interim.

The PRO version has this in the values.yaml to turn it off. Feel free to do something like that with the {{ }} type of test in the template YAML for Keycloak. So it skips it.

deployKeycloak: "true"

This will get looked at and adjusted/edited/fixed eventually but realistically not until 2024 early. If you and your team want to do a fork an PR for updated it, go for it.

[6un9-h0-Dan]

Here are a few things to keep in mind:

As you customize the Helm Chart:
Database Configuration: Modify the Helm chart to connect to your existing PostgreSQL database. This typically involves setting the database connection URI, username, and password in the Helm chart's configuration. These should be referenced from existing Kubernetes secrets rather than hardcoded in the values file.

Authentication Service Integration: To integrate with your existing Keycloak instance, you'll need to update the Helm chart with the appropriate authentication endpoints, client IDs, and secrets. Like with the database configuration, these should reference existing Kubernetes secrets.

Ingress Configuration: If you have an existing ingress controller or class, you'll need to specify this in your Helm chart. This could involve setting the ingress class in the chart's values and ensuring the ingress rules match your cluster's configuration.

Secrets Management:
Instead of including secret values directly in the Helm values file, use existing Kubernetes secrets. Reference these secrets in your deployment configurations. This approach enhances security by avoiding plain text secret exposure in your Helm chart.

Testing and Validation:
After making these changes, deploy the Helm chart in a test environment to ensure everything is working as expected. Pay special attention to connections to your PostgreSQL database and Keycloak for authentication.

Documentation and Support:
As always, ensure to update documentation to reflect changes and provide guidance for future deployments so others can help pick up where you left off or know what's going on with it.

Platform One's Big Bang Integration:
If you're considering submitting OpenRMF as an app in Platform One's Big Bang, ensure your Helm chart and deployment process align with P1 requirements and standards. Let me know how easy that may be to integrate, also let me help out when/if possible.

Collaboration with the Platform One team or just within the OpenRMF community can continue to help provide insights into requirements and assist in streamlining your application for approval.

A few additional things to think about and maybe try:

Configure Keycloak Integration:
In values.yaml file for the OpenRMF Helm chart, set dnsNameKeycloak and identityProviderURL to point to your existing Keycloak instance.
Ensure to have a separate realm set up in Keycloak for OpenRMF. You can use the identityProviderRealm field in the values.yaml file to specify this realm.

The roles and script setup for this realm are crucial. You should set up the realm as per the instructions and scripts provided in the OpenRMF documentation.

This script should help configure the necessary roles and settings in Keycloak for OpenRMF.

Customize Secrets:
You can fork the OpenRMF Helm chart repository (if you haven't done already) for testing, and a separate one for operations, and then modify the secrets configuration according to the requirements and maybe even use one as a backup and 1-2 as a test case approach. This might help to allow you to manage secrets more securely and tailor them to the environment and maybe alter it just slightly for testing purposes.
Ensure that any sensitive information is not hardcoded in the Helm chart but instead pulled from existing Kubernetes secrets or securely injected into your deployment. There are "fake" sensitive information creators out there.

Platform One Integration:
OpenRMF Professional might be the best bet for integration into P1, but integrating a free version is optimal for resilency and optimal usage by multiple contributors.

Also, I believe there is an existing USAF CTF (Cybersecurity Test and Evaluation Facility) for OpenRMF Professional, which could be relevant if you are considering a more advanced or supported version of OpenRMF for enterprise or government use. I haven't used/see that integration myself, but something to consider if you haven't used it yourself yet.

[6un9-h0-Dan]

Some key points and recommendations overall to keep in mind:

Keep the Helm Charts Flexible:
Modern Kubernetes deployments often require flexibility, especially when integrating with existing infrastructure. The ability to toggle components like Keycloak on and off is not just a convenience but a necessity for many users who already have these services running.

This issue reflects a common challenge in Helm chart development, where balancing simplicity and configurability is crucial. A Helm chart that is too rigid in its deployment strategy can limit its usability in diverse environments.
Best Practices in Helm Chart Development:

A best practice in Helm chart development is to provide parameters in values.yaml that allow users to enable or disable specific components of the chart. This approach enhances the chart's adaptability to different environments and use cases.
Implementing conditionals using {{ if ... }} blocks in the Helm templates is a standard method to achieve this. It allows the chart to be more dynamic and responsive to user preferences set in values.yaml.

Long-term Maintenance and Support:
While contributing a feature is a significant first step, it's also important to consider long-term maintenance. If you contribute this change, consider the willingness and capacity of your team to support this feature, especially if it becomes widely used.

Engaging with the maintainers (or if you and the rest of us contributors may be the ones maintaining it) to ensure that this feature aligns with the future roadmap of the project can also be beneficial. It's important to understand how your changes fit into the overall vision and future updates of the software.

[Cingulara]

We will not put massive effort into the helm chart.

This is a free application. Feel free to fork and do all this work correctly and do a P/R so we can review and inject it. That would be great.

Our resources will not allow us to dedicate time to do all this. So the helm work we do is a start.

We will update the image tags at least.