fix: use DB fields encryption key as the Django SECRET_KEY (alternate to #287) - #288
Closed
rooftopcellist wants to merge 2 commits into
Closed
rooftopcellist wants to merge 2 commits into
rooftopcellist wants to merge 2 commits into
Conversation
pulpcore 3.105.13 removed its insecure hardcoded SECRET_KEY = "SECRET" default (pulp/pulpcore#7873), so galaxy-ng pods now crash-loop with "The SECRET_KEY setting must not be empty." unless SECRET_KEY is set. Rather than generating and managing a brand new Secret for this, reuse the Fernet key the operator already generates and persists for DB_ENCRYPTION_KEY (roles/common/tasks/db_fields_encryption_configuration.yml). That key is already random, already 256 bits of entropy, and already has full backup/restore support - no new Secret, CRD field, or backup/restore wiring needed. Alternate to the separate-secret approach in ansible#287; see the linked internal writeup for the tradeoffs between the two (mainly: this reuses key material across two different cryptographic purposes - DB field encryption vs Django's session/CSRF signing - which is a deliberate simplicity-for-key-separation tradeoff worth discussing before picking one). Signed-off-by: Christian M. Adams <chadams@redhat.com>
…on_key CI failed on every job with "'db_fields_encryption_key' is undefined". roles/common/tasks/db_fields_encryption_configuration.yml only sets db_fields_encryption_key inside the block that runs on first-time generation (when: not _db_fields_encryption_secret['resources'] | default([]) | length) - i.e. only on the very first reconcile. Every reconcile after that skips the block entirely, so the fact is never set and this task blew up as soon as CI reconciled an existing deployment a second time. The fact that's actually populated unconditionally, on every reconcile, is db_fields_encryption_secret_contents (from the unconditional "Retrieve db_fields_encryption_key Secret" task at the end of that file). Read the key from there instead. Signed-off-by: Christian M. Adams <chadams@redhat.com>
Member
Author
|
Closing, this approach would be less secure. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Alternate fix for the pulpcore 3.105.13
SECRET_KEYcrash (django.core.exceptions.ImproperlyConfigured: The SECRET_KEY setting must not be empty.), also being addressed in #287.Instead of generating and persisting a brand-new Secret for
SECRET_KEY, this reuses the Fernet key the operator already generates and persists forDB_ENCRYPTION_KEYinroles/common/tasks/db_fields_encryption_configuration.yml. That key is already random (32 bytes / 256 bits of entropy fromcryptography.fernet.Fernet.generate_key()), already has full backup/restore coverage, and already survives upgrades via its existing Secret.Verified locally that a Fernet-format key works correctly as Django's
SECRET_KEY(signs/verifies viadjango.core.signingwith no errors). It does fall a few characters short of Django's own recommended 50-character minimum (security.W009), which is a soft warning only surfaced bymanage.py check --deploy— neither pulpcore nor galaxy_ng invoke that anywhere, so it has no functional or CI impact.This is intentionally a much smaller diff than #287 (one file, six lines) versus generating/tracking a wholly new secret. The tradeoff is reusing one key across two different cryptographic purposes (DB field encryption vs. Django session/CSRF signing) instead of keeping them separate. See the internal writeup linked below for the full pros/cons comparison between this approach and #287 before picking one.
ISSUE TYPE
COMPONENT NAME
STEPS TO REPRODUCE AND EXTRA INFO
Deploy galaxy-operator with
quay.io/ansible/galaxy-ng:latest(any build after 2026-09-01). All api/content/worker pods crash immediately withSECRET_KEY setting must not be empty.