Update patch set 1

Patch Set 1:

(1 comment)

Patch-set: 1
Attention: {"person_ident":"Gerrit User 27900 \u003c27900@4a232e18-c5a9-48ee-94c0-e04e7cca6543\u003e","operation":"ADD","reason":"Ian Wienand replied on the change"}
Attention: {"person_ident":"Gerrit User 7118 \u003c7118@4a232e18-c5a9-48ee-94c0-e04e7cca6543\u003e","operation":"REMOVE","reason":"Ian Wienand replied on the change"}

b219eb72ba325da6590324535dc81aad95464971

@@ -16,6 +16,24 @@
       "message": "in most cases security regulations of companies are requiring that any type of secret is being periodically rotated. Storing them in Zuul is making that both hard and reduces secret safety with each iteration (as also written in Zuul docs if I read them correctly). We will not go this way. Instead we created analog sys-config project in the private repository and merge their states on the bridge. In addition private repo is also not having secrets directly, but knows where to get them from (Hashi Vault in our case). With this secrets themselves are stored in Vaul where they can be easily rotated, and jobs/playbooks are knowing how to get secrets (actually we rely mostly on lookup plugins not even ti take care of that).\nThis is correct that bootstraping step need to be rethought, but simply puting secrets as zuul secrets is not proper from security pov.",
       "revId": "b219eb72ba325da6590324535dc81aad95464971",
       "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
+    },
+    {
+      "unresolved": true,
+      "key": {
+        "uuid": "b61912d7_0bdd05c5",
+        "filename": "/PATCHSET_LEVEL",
+        "patchSetId": 1
+      },
+      "lineNbr": 0,
+      "author": {
+        "id": 7118
+      },
+      "writtenOn": "2022-02-15T20:15:32Z",
+      "side": 1,
+      "message": "Thanks, I\u0027m definitely interested in iterating on any ideas that we can come up with.\n\nI agree on the need for rotation; I\u0027m not sure it\u0027s particularly easier or harder than any other way to rotate.  Ultimately you just have to run a little script and propose a change with this model.\n\nI\u0027m not sure that rotating and re-encrypting a zuul value makes it any less secure. Can you clarify this a bit more?  I will admit that this creates a side-channel where you give away some information by committing a change that tells everyone the key was just rotated, but I\u0027m not aware it would weaken the secret value as such.\n\nThe back-end system on the bastion/bridge we can consider opaque I guess (our bastion has something similar to get keys into place from repos for ansible to read).  The general point is that this system is managed by selected operators who need explicit permission to add/remove/rotate secrets.\n\nWe are trying to live an open-infrastructure model, where we would ideally like non-privileged users to be able to manage production systems.  (Sometimes, when things have really gone wrong, you need to log in.  But we want to make this the absolute exception, as much as possible.)\n\nI\u0027ve just put up for review some related work that will allow production deployment logs to be viewed by people who have a GPG key committed to the system-config repo [1].  That is in a similar orbit of allowing anyone with interest to help manage the systems.\n\nSo this does have to be filtered though a lens of trying to achieve these goals. This obviously isn\u0027t every project\u0027s goal, but it is ours 😊\n\n[1] https://review.opendev.org/q/topic:bridge-encrypt-logs",
+      "parentUuid": "d0753f42_6848365c",
+      "revId": "b219eb72ba325da6590324535dc81aad95464971",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
     }
   ]
 }