| > Is there a way to abstract away these extra configuration steps and keep it simple yet secure by default? Secure from what? What is your threat model? It's hard to imagine 'default' security because everyone is worried about different things. > I just want them to talk securely and minimize any attack vectors and keep any configuration to a minimum Your application is more likely to expose a SQL injection vulnerability than someone gaining unauthorized access to your network. I'm not saying you shouldn't secure it, I'm just saying that it is probably pointless since your application has access to :all-the-things: and it is probably the weakest link. Further, if you're doing this on a developer machine, you're just making it harder to debug issues. As the user of the host machine, you have access to everything by default. > How do you do (not the configuration management) but manage an inventory of what configuration is needed to run your environment (or a subset for ci)? Documentation, documentation, documentation. Basically, have a markdown file with each config item, it's value in each environment (not literal values, but ex: 'github token for production, with X,Y,Z scopes'), why it exists, and who is responsible for it. |
So say the application is compromised, it can't connect to the internet, from there it could only connect to the declared database and webservice. So those would need to have vulnerabilities too that could be exploiting from that end, hence limiting the blast radius.
So not really worried about physical access, but more in the lines of a RCE(Spring4Shell) probing the rest of the network or a supply chain attack that tries to send out data...