Harden self-hosted installers: generate an embedded IdP session cookie key and restrict config.yaml permissions

[Optic00]

Before posting

• I searched existing discussions and issues for similar requests.
• I checked the documentation to confirm this is not already supported.
• This is a product idea or enhancement request, not a support question.
• I removed or anonymized sensitive details from examples and screenshots.

Product area

Management service / API, Identity provider / SSO, Self-hosting / Deployment

Problem or use case

Fresh self-hosted installations created with the official community or enterprise bootstrap script leave server.auth.sessionCookieEncryptionKey unset.
The embedded IdP supports a dedicated key for authenticated encryption of its session cookie, so generating one during setup would provide an additional defense-in-depth boundary by default.

The existing server-side nonce validation remains in place when the key is absent.
This proposal does not claim an account takeover, an MFA bypass, or a separate vulnerability.

The community installer also writes the secret-bearing config.yaml through a normal shell redirection, while the enterprise installer already creates that file with mode 0600 before rendering its contents.

Proposed solution

• Generate one dedicated Base64 value encoding 32 random bytes for each newly generated community and enterprise deployment.
• Persist it as server.auth.sessionCookieEncryptionKey without reusing the management datastore key.
• Create the community config.yaml with mode 0600 before writing its contents.
• Do not modify existing installations automatically.

Alternatives or workarounds considered

No response

Community impact and priority

• Deployment type: fresh self-hosted community and enterprise installations.
• Frequency: once per newly generated deployment.
• Priority: low, defense-in-depth hardening.
• Number of affected users or teams: unknown.

Examples from other tools or products

No response

Security, privacy, and compatibility considerations

All management instances in an HA deployment need the same persisted key.
Changing or losing the key invalidates existing session cookies and requires users to sign in again.
The change does not protect an already stolen valid cookie and is not presented as an MFA bypass or account-takeover fix.

Implementation ideas

I have a focused local patch and installer regression tests covering decoded key length, separation from the datastore key, YAML placement, and file mode.
The patch remains unpushed pending validation of the scope.

Are you willing to help?

Yes, I can submit a PR if the approach is accepted.

Additional context

Would this be suitable for promotion to a validated Issue and contribution through the normal PR workflow?

[mlsmaycon]

Hello @Optic00, thanks for submitting this topic here too. We would be happy to review your contribution to resolve it.

I've opened issue #7054 for us to follow up.