Read on Twitter
I want to talk a bit about how @DonMagee, @rafalwilinski, and I are working to build an internal cloud platform/security team at Stedi that is not vilified by the rest of the company. Something I've seen many companies get wrong and always ends up causing internal "shadow ops."
1) The rest of the company is our customer, not our subjects. We are working to earn their trust. When we provide tools or opinions, they are of high quality, and teams want to use them. Guaranteed internal "support contracts" are a path towards this.
2) Trust in the collective is paramount to institutional success. Recognize we've hired extremely talented people (and continue to do so http://stedi.com/careers ). We aren't here to get in your way; we are here to make doing the easy thing and the right thing, the same thing. How?
3) Remove friction wherever possible. Some examples...
Provision AWS accounts in literal minutes.
Autoconfigure AWS Config, GuardDuty, etc. Heavy lifting, we got you.
Run (and manage for you) the CDK bootstrap process, wired up build account for your team's accounts.
Provision AWS accounts in literal minutes.
Autoconfigure AWS Config, GuardDuty, etc. Heavy lifting, we got you.
Run (and manage for you) the CDK bootstrap process, wired up build account for your team's accounts.
3 continued)
Fast and easy sign-in and account switching (AWS SSO is great!)
Monitor and automatically lift account limits for teams when reasonable.
Well documented developer onboarding.
Easy to use CI/CD Pipeline CDK constructs.
Fast and easy sign-in and account switching (AWS SSO is great!)
Monitor and automatically lift account limits for teams when reasonable.
Well documented developer onboarding.
Easy to use CI/CD Pipeline CDK constructs.
4) Provide a golden path, but don't fence in folks.
We autoblock all public S3 at an account level, block IAM user creation, EC2 instance usage, etc. However, we aren't here to mandate the one true way. You can do (mostly) whatever you want if you accept the responsibility.
We autoblock all public S3 at an account level, block IAM user creation, EC2 instance usage, etc. However, we aren't here to mandate the one true way. You can do (mostly) whatever you want if you accept the responsibility.
(More on that from @mipsytipsy at https://charity.wtf/2018/12/02/software-sprawl-the-golden-path-and-scaling-teams-with-agency/)
5) Detective controls must pair with preventive controls. Aka shift left. We are working to provide developers with immediate feedback if their resources don't meet compliance BEFORE they even push code and in their pipelines. Actionable insights, not nagging after it hits prod.
6) Compliance is a joint effort, not a dumb set of top-down restrictions.
We've been thinking hard about achieving compliance (before we need it) without burdening teams. That means we are centralizing all sorts of information now and automatically without teams wasting cycles.
We've been thinking hard about achieving compliance (before we need it) without burdening teams. That means we are centralizing all sorts of information now and automatically without teams wasting cycles.
6 continued)
We'll provide guidelines to teams about future requirements in the form of automated checks. No surprises.
If something is hard, we'll spend the cycles to provide a solution that scales across the organization, not piecemeal duct-taped solutions to pass a check.
We'll provide guidelines to teams about future requirements in the form of automated checks. No surprises.
If something is hard, we'll spend the cycles to provide a solution that scales across the organization, not piecemeal duct-taped solutions to pass a check.
If this stuff seems easy or like a "duh", I'd agree. However, organizationally committing to it is something rarely done.
It takes a serious investment in your people and doesn't reflect in your feature velocity immediately. The dividends are in the long term.
It takes a serious investment in your people and doesn't reflect in your feature velocity immediately. The dividends are in the long term.
