3 ms·
I think that publicly exposing your build/deployment system is a very bad idea. It contains too much sensitive and valuable information (credentials, commits, c
by kovrik 8y ago
I think that publicly exposing your build/deployment system is a very bad idea. It contains too much sensitive and valuable information (credentials, commits, commit author names, paths, hostnames, scripts etc.) and it is too hard to make it secure the right way.
Unfortunately, many people do that. For example, here in New Zealand there is a new startup Onzo (bike sharing). When they launched, I tried to google about them (just out of curiosity). And in 1 minute I found their Jenkins server exposed to everyone as well. I could see how their build process works, who commits what etc. I decided to try to login using simple credentials (something like admin:password) and it didn't work. But there was a Register button. "Why not?" I thought and clicked it and created my own account. And voila, it gave admin permissions by default - I could delete their projects, change variables etc. Emailed them about that.
Moral: never expose your build/deployment systems. If you really want to expose some parts (for whatever reason), then use/write client/UI that has no permissions. 'Build Status' badge is a good example -- it exposes build status info, but doesn't show too much and doesn't give any permissions whatsoever.
- falsedan 8y agoJenkins sucks for a lot of reasons but it does have a perfectly serviceable credentials store exactly for hiding these kinds of secrets from the parameters page and the build output. Any release engineer with the slightest inclination to avoid incidents would have set it up, this just looks like a lack of experience at breaking everything for everyone.