Hacker News Reader

Comment by Lucasoato | Hacker News Reader

Is it just my impression or security in Jenkins seems much more challenging and more time-consuming than in GitLab? This post gives many examples where GitLab was attacked, so of course bad practices like privileged containers can lead to the compromise of a server independently by the technology used, but from my experience with Jenkins, I've seen using passwords in plaintext so many times, even in big companies.

View on HN

Jenkins is security game over if you overlook a small crucial configuration option or if you install any plugin (and it's unusable without some plugins), as plugin development is a free-for-all and dependencies between plugins are many. We basically decided that one instance of Jenkins plus slaves was unfixable and unconfigurable to use securely across multiple teams with developers of differing trust levels (external contributors vs normal in-house devs) and started fresh with a different CI design.

Jenkins is a batteries excluded pattern in one of its worst possible incarnations.

Jenkins is basically a CI framework for trusted users only. Untrusted workloads must not have access to anything Jenkins.

I don’t really like either. Both have traditionally been bad & related to on-prem legacy workloads. Building for SVN apps or teams new to git. It’s usually a mess.

As someone adjacently interested in the field: care to elaborate on what systems you do like? It's always interesting to get new perspectives.

We've been happy with buildkite and hashicorp vault. One nice feature we've leveraged in our CI is that vault lets us revoke tokens after use, so we have very short lived tokens and they're made that much shorter by having the jobs clean up after themselves.

going cloud native (AWS/GCP/Asure) & using their build tools makes things simple for things like container management and integrated development.

GitHub because it’s better UX. It’s even quite simple to setup good automation around a codebase.

Platform teams are using Argo, dev teams not really doing too much ci/cd which I like.

& to be honest CI/CD requires continuous investment as things continuously change. Not that it isn’t necessary… but in an enterprise environment you I’ve seen teams become more successful on their own rather than trying to fulfill any “reciprocity” bs.

Jenkins was also affected by numerous Java serialization vulnerabilities. It also used to be that any worker could escalate to the main Jenkins server pretty much by design, not sure what the current situation is.

> but from my experience with Jenkins, I've seen using passwords in plaintext so many times, even in big companies

I reckon this has to do with how the CI tools are configured.

Everyone knows you shouldn't commit a secret to Git, so tools like GitLab CI which require all their config be in git naturally will see less of this specific issue.

Jenkins is a tire fire, and security is just one of their tires on fire. Every aspect of it encourages bad practices.

Reply on news.ycombinator.com