3

We have a series of Jenkins nodes that are used to deploy changes onto our SQL Servers, which works fine as long as everyone behaves and can be trusted.

The worry is that a rogue developer or hacker could simply add something like this into a Jenkins file and trash our data or performance:

   node (production) {
         stage ‘deploy_straight_to_prod’ {
               …<do something bad here>
        }
    }

How do we protect against this? Ideally, only scripts that have been actively aproved by a DBA should be allowed.

Anders
  • 64,406
  • 24
  • 178
  • 215
Lobsterpants
  • 131
  • 2
  • This is not really specific to Jenkins. It basically asks how to prevent a hacker in your own network and how to prevent a developer turning malicious. Both are separate and by themselves very broad questions which makes the question in my opinion too broad and a bad fit for this site. – Steffen Ullrich Feb 08 '20 at 12:57
  • Did you actually read the question? it is totally specific to Jenkins and allowing only agreed scripts to run. – Lobsterpants Feb 10 '20 at 06:27
  • Yes, the question is specific to Jenkins but the underlying problem of having developers you cannot trust or a hacker in the network is not. And in my opinion this underlying problem is actually the main point: if you cannot control who can configure your Jenkins then you've lost. – Steffen Ullrich Feb 10 '20 at 06:31
  • Really? so you allow everyone in your company to have SA access to your databases ? or you allow anyone to run any script they like? Its nothing to do with who can configure jenkins, its about limiting what people can do on those servers, a pretty basic requirement of a secure system IMHO. – Lobsterpants Feb 10 '20 at 09:07
  • If you don't trust somebody to make changes to the DB don't give them the permissions to access the DB. Similar with developing code. And, Jenkins also allows you to set permissions on what specific people can do - just have a look at [this documentation](https://wiki.jenkins.io/display/JENKINS/Matrix-based+security). The problem is if you give others a permission to do something and they abuse this permission or got hacked and this is what I see as the main point of your question and which is independent from Jenkins. – Steffen Ullrich Feb 10 '20 at 10:31
  • We give them permission to do a subset of things. In order to do those things the user ID the script runs under needs to be SA. We need to make sure that only that subset of things can be executed. – Lobsterpants Feb 10 '20 at 11:23
  • Why not just don't give them the permission but let them send their code to the DBA which then approves and installs it? Isn't that basically what you want: only active when approved by a DBA? – Steffen Ullrich Feb 10 '20 at 12:55
  • Not really. All we want is to say "this jenkinsfile is approved" so you can automatically deploy using it whenever you like. If it changes it is no longer approved & needs to be reassessed. – Lobsterpants Feb 10 '20 at 13:35
  • Now I understand. Based on this I did a simple search for [jenkins preapproved script](https://www.google.com/search?q=jenkins+preapproved+script) and [the first hit](https://plugins.jenkins.io/script-security/) points to a jenkins plugin which seems to provide exactly what you want. – Steffen Ullrich Feb 10 '20 at 14:06
  • Yeah, we looked at that but the control seems to be on a server basis, not a node basis (drop database is fine in dev, more of an issue in prod). I think the only real solution is a second Jenkins instance that the DBAs control, only builds that they allow will be on the machine. Just need to add some monitoring that flags if the Jenkinsfile has changed and we are good. – Lobsterpants Feb 10 '20 at 14:26
  • Do you realize that these comments contain many information which should have been in your question from start? If you still want the question to be answered please edit it and put all the details in there instead of expecting others to dig through the comments. – Steffen Ullrich Feb 10 '20 at 14:53

0 Answers0