I have provisioned an aws-flavoured Evergreen instance on our AWS company account.
Our mighty Caleb Tennis, from the OPS team, saw scans from various locations on the ports of this instance.
We just had a meeting and Caleb had a few recommendations to make the installation more secure.
Overall reminder/caveat: we can clearly do much better in terms of security. But we have to find the right balance between the additional complexity each item would add, and the level of simplicity we want to offer for Evergreen users.
Sorted by criticality below.
We have the HTTP port enabled by default and no HTTPS. We should likely add an ELB and configure HTTPS OOTB.
Caveat: an ELB costs additional money (34$ base price, higher depending on the load). So we need to see how much more precisely and make this optional or not. This could end up being wasteful if a user plans to put/configure an existing and secure reverse proxy in front of a new Evergreen instance.
This is probably not a big deal, but it would be nice if we can open/close it down on demand. (By modifying the security group?).
Main caveat again: this makes using Evergreen slightly more complex.
This one, though currently disabled at the Jenkins level, is also a potential vector of attack.
We could limit access to it to agents from the same AWS account, but it would probably severely limit what users can do if they want to connect an existing agent manually in addition to the dynamically provisioned EC2 agents.
|Summary||AWS flavor security hardening||Evergreen AWS flavor security hardening|
|Remote Link||This issue links to "install evergreen in a dedicated VPC (Web Link)" [ 22057 ]|