are software users • The quality of their experience (i.e. ease-of-use) affects productivity • Inefficient security practices will impair both Dev & Ops productivity but … foregoing security is not an option • The security threat gets a lot of attention, but the UX threat is real, and not getting enough attention
Secure practices should not inhibit Dev velocity • DevOps tools are meant to be collaborative ◦ Anyone can submit code for a pull request ◦ Anyone can contribute scripts to Puppet, Chef, Ansible or Salt ◦ All developers should have read and execute access to Jenkins • These environments are intended to be open to all • Thereby putting them at odds with good security hygiene
• Continuous Integration ◦ Constant flux ◦ Always building working code • Continuous Deployment ◦ Conscious decision to share w/ a wider customer base ◦ Hide flux of development from end users • Fences are necessary here ◦ CI != Development
an attacker • Don’t conflate build & deploy roles ◦ Keep sensitive info out of Puppet Master and Jenkins ◦ Cuz you have to lock that stuff down ◦ Secrets can inhibit collaboration • Best practice is “no standing access to production” ◦ Grant access to production on an exception basis ◦ Manage the production “control plane” most carefully
good practices in place It’s a fallacy that secrets management slows things down. In fact, it speeds things up because: • Needed secrets are always declared in a repo • There’s only one way to get access to secrets; so, there’s no confusion about how to get access. Goal: make secrets access transparent to development • Centrally vault the secrets • Grant access by role • Rotate important secrets regularly
by role • DevOps practitioners are increasingly being targeted ◦ You are a gateway to Production ◦ But, you’ll be reluctant to inhibit velocity • Rule: No secrets are statically deployed to any machines ◦ Aside from a user or machine identity credential • Rule: Developer SSH access uses their own private keys - no SSH key sharing • Rule: Root SSH keys are vaulted and managed by role
Security policies evolve - version everything ◦ Secrets in version control? NO ◦ Security policies in version control? YES • Track changes, not just to what, but why ◦ Fine if in human readable form for now ◦ Automation templates: CF, Terraform, BladeLogic, Puppet • Enforcement ◦ Chef InSpec - codifies and enforces compliance w/ above • If you don’t do this, things will get messy quickly ◦ Piecemeal changes made via UI tools ◦ No audit trail, no repeatability, no reference for compliance checking • Security-policy-as-code is the end goal ◦ Automated execution ◦ Automated enforcement ◦ Automated compliance checking • Helps w/ resilience overall ◦ Keeps Dev functions separate from Deployment ◦ Tracks workflow evolution
time • Separated AWS accounts into CI, Dev, Prod. ◦ It sucks to untangle that if you’ve already mixed up the concerns • No SSH key sharing from day 1 • No hard coded secrets in Jenkins
out • A good workflow for registering new secrets and applications. • How to separate build and release concerns ◦ v0 - General purpose Jenkins executor ◦ v1 - Remote web service (release-bot) ◦ v2 - Privileged Jenkins executor • Secrets rotation - still a work in progress ◦ Difficult for things like 3rd party apps • etc
• Principles ◦ Secure by default ◦ Easy to understand ◦ Deliver workflows (not tools) ◦ Transparent ◦ Satisfy audit & compliance teams with minimal overhead • Recommendations ◦ Separate Dev, CI and Production “concerns” ◦ Map the roles and workflows ◦ Manage security policies like code
camiha
4o1sobblue
glaforge
techtekt
tetsuya28
shugo
yut0naga1_fa
yuuuuuuu168
syuchimu
shuta13
colopl
mohab1
lynnandtonic
katarinadahlin
deanohume
swwweet
kimpetersen
sarafernandez
bryan
techseoconnect
aleyda
marktimemedia
