(multiple) Randomize osp-secrets.env default passwords - #4114
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
This complements #4110. They both attack the same problem for different secret keys in different ways, so perhaps we could converge on a preferred approach. |
The architecture repo ships `osp-secrets.env` with hardcoded default passwords that end up in the `osp-secret` K8s Secret via kustomize `secretGenerator`. This is a security risk for any environment that deploys using these defaults. Add a new `randomize_secrets.yml` task file to the `kustomize_deploy` role that rewrites values in `osp-secrets.env` with randomly generated replacements after the architecture repo is cloned but before `oc kustomize` runs. The task uses a three-tier resolution per key: live cluster secret, local cache, then fresh generation. Value format handling: - Hex-encoded keys (e.g. `HeatAuthEncryptionKey`): random hex of the same length - Skipped keys (e.g. `BarbicanSimpleCryptoKEK`): preserved as-is - Plain passwords (everything else): 20-char alphanumeric string The task is wired into both `cifmw_setup/deploy_architecture.yml` and the deprecated `06-deploy-architecture.yml` playbook, running right after `check_requirements` and before `reduce_ocp_cluster`. Signed-off-by: Andrew Bays <abays@redhat.com> Co-authored-by: Cursor <cursoragent@cursor.com>
72803ce to
b947518
Compare
abays
changed the title
|
Build failed (check pipeline). Post ✔️ openstack-k8s-operators-content-provider SUCCESS in 3h 39m 16s |
|
recheck |
|
Build failed (check pipeline). Post ✔️ openstack-k8s-operators-content-provider SUCCESS in 6h 23m 08s |
|
recheck |
|
Build failed (check pipeline). Post ✔️ openstack-k8s-operators-content-provider SUCCESS in 2h 44m 07s |
|
recheck |
|
Build failed (check pipeline). Post ✔️ openstack-k8s-operators-content-provider SUCCESS in 3h 30m 27s |
|
recheck |
|
Build failed (check pipeline). Post ✔️ openstack-k8s-operators-content-provider SUCCESS in 4h 05m 54s |
|
recheck |
|
Build failed (check pipeline). Post ✔️ openstack-k8s-operators-content-provider SUCCESS in 3h 42m 38s |
|
recheck |
|
Build failed (check pipeline). Post ✔️ openstack-k8s-operators-content-provider SUCCESS in 3h 48m 27s |
|
recheck |
|
Build failed (check pipeline). Post ✔️ openstack-k8s-operators-content-provider SUCCESS in 2h 14m 56s |
|
recheck |
|
Build failed (check pipeline). Post ✔️ openstack-k8s-operators-content-provider SUCCESS in 3h 44m 29s |
|
recheck |
1 participant
The architecture repo ships
osp-secrets.envwith hardcoded default passwords that end up in theosp-secretK8s Secret via kustomizesecretGenerator. This is a security risk for any environment that deploys using these defaults.Add a new
randomize_secrets.ymltask file to thekustomize_deployrole that rewrites values inosp-secrets.envwith randomly generated replacements after the architecture repo is cloned but beforeoc kustomizeruns. The task uses a three-tier resolution per key: live cluster secret, local cache, then fresh generation.Value format handling:
HeatAuthEncryptionKey): random hex of the same lengthBarbicanSimpleCryptoKEK): preserved as-isThe task is wired into both
cifmw_setup/deploy_architecture.ymland the deprecated06-deploy-architecture.ymlplaybook, running right aftercheck_requirementsand beforereduce_ocp_cluster.