5 ms·

>There will always be a small handful of engineers that can push the button to move code into PROD or even change code in PROD live. What? Why? Nobody on my d

>There will always be a small handful of engineers that can push the button to move code into PROD or even change code in PROD live. What? Why? Nobody on my development team has access to the production code signing keys. And nobody - at all - has the ability to remotely make a production system take an unsigned update.

rndgermandude 8y ago
But somebody has access to the signing keys/signing process. And somebody has access to the production machines. Etc.
- finnthehuman 8y ago
  Yes, but that changes the scenario from a "small handful of engineers" that can all do it unilaterally, to needing at least one person from N different teams to collaborate. And in my specific case, the group with the singing keys is also the group paid to tell us "no" whenever a release is blocked by process reasons.
  - rndgermandude 8y ago
    My guess is that most people with access to signing keys or prod environments would have enough skills to code in some sabotage bugs before deployment or siphon off some data, so a lone devops person with (physical) access could probably a lot of harm just by themself.
    - finnthehuman 8y ago
      Sure, I’m just saying our commitment to process is strong enough that the technical systems are a funnel into following a reasonable process. I got dragged into defending my technical solution, but my point was that if the ability isn’t needed, don’t have it. You can break the glass when when you need to. Good process make deviation from it more visible. Our code signing keys belong to a team we already need wet ink signatures from to release software. I can go into the biohazard labs with shorts on easier than I can leverage our technical disaster recovery. I’ve only ever had to do the latter.
gldalmaso 8y ago
If a single person holds the keys, that's a different problem altogether. https://en.wikipedia.org/wiki/Bus_factor https://en.wikipedia.org/wiki/Bus_factor
justinclift 8y ago
Heh Heh Heh You know that backup system your production servers have? That also has perfect _write access_ to everything, and it's needed so _restoring_ after something goes wrong works.

rndgermandude 8y ago

But somebody has access to the signing keys/signing process. And somebody has access to the production machines. Etc.

finnthehuman 8y ago
Yes, but that changes the scenario from a "small handful of engineers" that can all do it unilaterally, to needing at least one person from N different teams to collaborate. And in my specific case, the group with the singing keys is also the group paid to tell us "no" whenever a release is blocked by process reasons.
- rndgermandude 8y ago
  My guess is that most people with access to signing keys or prod environments would have enough skills to code in some sabotage bugs before deployment or siphon off some data, so a lone devops person with (physical) access could probably a lot of harm just by themself.
  - finnthehuman 8y ago
    Sure, I’m just saying our commitment to process is strong enough that the technical systems are a funnel into following a reasonable process. I got dragged into defending my technical solution, but my point was that if the ability isn’t needed, don’t have it. You can break the glass when when you need to. Good process make deviation from it more visible. Our code signing keys belong to a team we already need wet ink signatures from to release software. I can go into the biohazard labs with shorts on easier than I can leverage our technical disaster recovery. I’ve only ever had to do the latter.

gldalmaso 8y ago

If a single person holds the keys, that's a different problem altogether. https://en.wikipedia.org/wiki/Bus_factor https://en.wikipedia.org/wiki/Bus_factor

justinclift 8y ago

Heh Heh Heh You know that backup system your production servers have? That also has perfect _write access_ to everything, and it's needed so _restoring_ after something goes wrong works.