Use of Bitnami postgresql as a subchart/dependency is fragile and may reprsent a security issue going forwards

[anthonysomerset]

this is a follow on issue to #14 that was mittigated in #15

Bitnami deprecated their free docker images and kind of by proxy the helm charts

The helm charts work but they target the bitnami "secure" images which are no longer free to access as tagged/pinned versions or you are forced on to the "latest" tag which while might be fine in a testing/ci scenario are a complete no no in a production environment, especially when the environment in question itself is about managing change of your infrastructure more broadly

The quick fix mentioned above basically changed the postgresql image to target the bitnamilegacy images whcih are a snapshot in time of the original bitnami images and no longer recieve any form of updates - this represents a longer term security issue overall

This issue is to initially prompt a discussion about how best we should mittigate this, they way i see this is that there are a number of possible options (personal opinion will come in a second reply)

1. Do nothing - continue to use Bitnami Helm Chart with an image pinned at bitnamilegacy
2. Update the subchart dependency to the latest version of bitnami's postgresql and/or use the "latest" tag for postgresql
3. Remove all support for managing postgresql within this chart - expecting the user to pre-configure postgresql however they desire
4. Migrate to an alternative more stable helm subchart for postgresql

Throwing the gates open for discussion and views or alternative ideas so we can come up with some consensus on a way forwards

[anthonysomerset]

ok personal thoughts

1. no further work needed but risks exposing us to longer term security issues due to stagnant postgres version, leaves users with limited options to mittigate themselves
2. living on the bleeding edge of "latest" is a recipe for pain and additional work and reliance on bitnami always publishing a working image - and gives us no control over major PG version upgrades, minimal work in the short term but gives every user of this chart that uses the built in pg features lots of potential future work and pain
3. simplest for us and only a moderate amount of cleanup work to achieve but somewhat breaks the model of being able to run a few helm commands to get to a working operation, this also represents potential major breaking change issues if/when users upgraded from a version with DB package vs no db packaged - this would need lots of documentation/warnings etc in order to manage and even then i am sure it will get missed and issues happen - a great case for make sure folks have backups..
4. probably represents the most amount of work and particularly with handling this in as graceful a manner as possible - at the very least one would need to make a major version change and likely have to make a migration guide to get users from old to new and functionality would need to be availed to make that easy (e.g. a restore route to compliment current backup options)

I personally favour 4 but i suspect we will need to really put a lot of effort into the upgrade path - to me it almost feels like one should go as far as saying there is NO upgrade path and one should stand up a new environment and manage the migration (backup/restore CA and DB content or a swing migration from old puppet to new puppet)

If we were to end up taking that route then one might as well go the whole 9 yards and also update all the values.yaml to reference openvox as much as possible instead of puppet, something that has been avoided to avoid backwards compatibility issues to date

[ke5C2Fin]

I've been using CNPG https://cloudnative-pg.io/
It allows deployment of standalone of highly available postgres in kube via an operator and CRDs.
It has been easy and convenient to use so far and looks like it will have longevity.

[JGodin-C2C]

CNPG may be an overkill in that case. Also, the installation of operators needs high privileges in the cluster, which a user may not have. One solution would be to use the official postgres image, but this would need some adaptations.

@anthonysomerset i am available on slack if needed.