|
|
|
|
|
by wdella
1731 days ago
|
|
> the CI system basically had admin access over our infrastructure. It has to in order to do infrastructure as code. > Public CIs are fine though. Ones that literally only do code builds, tests etc I couldn't agree more. Even internally, the security and authorization needs of deployment/release are wildly higher than those for running an ephemeral build and test. "CI/CD" needs to be un-bundled, for the sake of security, such that CI doesn't have admin access over infrastructure. Only a much more limited CD has this access. In the case of open core products that use public facing CI, I'm inclined to put the average employee's CI on the public system; for transparency, but also to make sure external contributors don't become second class citizens using an irregular workflow/toolset. Maintain a separate internal release system limited to trusted employees. Principle of least privilege, and all that. :) |
|