Do not make creating a secret for PostgreSQL a prerequisite

[rm3l]

Do not make creating a secret for PostgreSQL a prerequisite

[gazarenkov]

A couple questions to this DoD (in addition to #68 (review) ) :

It should create random values for password fields in the Secret

Is it really important to generate a random value for the local, namespace scoped database or static default value (which can be changed) would be sufficient?

It should not create a Postgres Secret if enableLocalDb is true (the user probably wants to use their own external DB)

you meant "is false"?

[rm3l]

A couple questions to this DoD (in addition to #68 (review) ) :

It should create random values for password fields in the Secret

Is it really important to generate a random value for the local, namespace scoped database or static default value (which can be changed) would be sufficient?

I think it might be important to have different creds for each DB (at least from a security perspective). I guess different people could work on a shared namespace and have multiple Backstage instances in that namespace, right?
And from what I understand from the various DB images out there (including the fedora/postgresql-15 we use here by default), the only method for changing passwords after the DB has been created is through SQL statements, as passwords are written once during the first initialization and stored into the volumes associated with the Database. So that means changing the value in the secret will probably not affect the DB container even by restarting it (unless everything including the volumes is recreated).
So IMO, we should at least prevent those DBs from having the same creds by default.

It should not create a Postgres Secret if enableLocalDb is true (the user probably wants to use their own external DB)

you meant "is false"?

Oh right, good catch. I thought I had changed that after renaming the field from skipLocalDb to enableLocalDb 🤦🏿

[gazarenkov]

A couple questions to this DoD (in addition to #68 (review) ) :

It should create random values for password fields in the Secret

Is it really important to generate a random value for the local, namespace scoped database or static default value (which can be changed) would be sufficient?

I think it might be important to have different creds for each DB (at least from a security perspective). I guess different people could work on a shared namespace and have multiple Backstage instances in that namespace, right?

Well, it is a good question. TBH I do not see a lot of sense in making several instances in one namespace (we do not prevent it though). And, anyway, even if several instances, do you expect them to be production ready or we are talking about development case (dummy data anyway)? (I tend to think it is second case?)

And from what I understand from the various DB images out there (including the fedora/postgresql-15 we use here by default), the only method for changing passwords after the DB has been created is through SQL statements, as passwords are written once during the first initialization and stored into the volumes associated with the Database. So that means changing the value in the secret will probably not affect the DB container even by restarting it (unless everything including the volumes is recreated). So IMO, we should at least prevent those DBs from having the same creds by default.

Good to know but I am not sure what problem you're trying to solve here...
If you just want to make "non-default" password - you can use your own db-secret.yaml with customized password in raw config.
Does it make sense?

It should not create a Postgres Secret if enableLocalDb is true (the user probably wants to use their own external DB)

you meant "is false"?

Oh right, good catch. I thought I had changed that after renaming the field from skipLocalDb to enableLocalDb 🤦🏿

[rm3l]

A couple questions to this DoD (in addition to #68 (review) ) :

It should create random values for password fields in the Secret

Is it really important to generate a random value for the local, namespace scoped database or static default value (which can be changed) would be sufficient?

I think it might be important to have different creds for each DB (at least from a security perspective). I guess different people could work on a shared namespace and have multiple Backstage instances in that namespace, right?

Well, it is a good question. TBH I do not see a lot of sense in making several instances in one namespace (we do not prevent it though). And, anyway, even if several instances, do you expect them to be production ready or we are talking about development case (dummy data anyway)? (I tend to think it is second case?)

During the previous RHDH Test Day, I remember most of the test cases revolved around a Helm release created with a local DB (not an external one). That's why I was thinking we could take that into account as well.
As pointed out in #68 (comment) (and I tend to agree with that), a local DB could probably be sufficient for smaller-sized customers; in which case, it should be production-ready as well.
Or either we disable the local DB feature altogether (and expect customers to provision and manage a DB themselves as a prerequisite, which I think the Keycloak Operator does), or we should treat it as first-class as well security-wise.

And from what I understand from the various DB images out there (including the fedora/postgresql-15 we use here by default), the only method for changing passwords after the DB has been created is through SQL statements, as passwords are written once during the first initialization and stored into the volumes associated with the Database. So that means changing the value in the secret will probably not affect the DB container even by restarting it (unless everything including the volumes is recreated). So IMO, we should at least prevent those DBs from having the same creds by default.

Good to know but I am not sure what problem you're trying to solve here... If you just want to make "non-default" password - you can use your own db-secret.yaml with customized password in raw config. Does it make sense?

I am trying to have a local DB somehow secure "by default", without users having to do too much customization. That's why a random password per DB can help alleviate potential issues in the future, I think.

[gazarenkov]

@rm3l "somehow secure" is too fuzzy :)
It all depends on RBAC policy you want to apply for the backstage namespace. For example, with "secret get access" your users will be able to see the secret data, or with shell access for pgsql container they even do not need to know the secret to access the database locally.

Anyway, like i said, I do not mind (and like) secret generation option but details matter.
My proposal is based on taking this secret as a first class citizen of our data model. What I propose and partially implemented in ths PR :

• db-secret.yaml key on default configuration for defining the shape of generated default secret
• same as for others it can be redefined in the raw configuration (with db-secret.yaml key) and (according to your proposals) on CR.spec too
• if the Secret does not contain (or it is empty) POSTGRES_PASSWORD field - Operator generates it, otherwise uses defined one
• Note: in my code the secret is generated on CR create only but after some thoughts I think it is NOT correct b/c this way we silently violate the contract on CR.update/patch - user updates the Secret but it is not updated in fact and still working with old values. It is more correct if Backstage fail. I think, it should be fixable by recreating the pod or scaling to 0 and back the statefulset
• generated secret (with own-runtime) is fully synchronized with Backstage CR (again the same as other data objects), i.e. user has no chance to change the Secret value or delete secret (not changing the CR), the state will be restored according to (default) desired state
• unlike generated, standalone (defined by name in raw or CR.spec) secret is the sources of desired state and changing it user is able to change the behavior (pgsql password in this case, see my note above)