trikosuave
commented
9 years ago Im not sure what the best way to deal with this is. Jenkins would not need to be "hacked", as login credentials are in plaintext in public repo. We could add this to secrets management, or simply lock down tcp/8080 (jenkins) to a specific group of IPs (original intention). With jenkins publicly accessible, as well as the credentials publicly available, anyone could login to a running demo and deploy malicious web server code (to docker and/or codedeploy), or turn the jenkins box itself into a malicious bot attacking foreign networks, or even replacing jenkins with a different service on port tcp/8080.
Nando brought this to my attention. The minimum codedeploy policy that was added to the Jenkins IAM Role Policy allows the possibility of malicious code to be pushed out from the jenkins server. This requires the jenkins server to be compromised and likely wouldn't be an issue in an actual, production environment where Jenkins wouldn't be public facing.
One idea we came up with is to create a cloudwatch script that can monitor the process and the script itself. Since the security groups limit access to only port 80, we can write a script that will assure that the python flask process is connected to port 80 and confirm the Python code itself matches an md5sum generated at deployment time. Of course, if these conditions are not met, we are notified via cloudwatch.