Survey Results
46 institutions attending, 4 vendors, 81 unique roles among 90 attendees.
40% cloud first, 12% have a documented cloud exit strategy.
82% AWS, 14% Azure, 4% Google, 2% other
Staff readiness is the #1 obstacle to broad adoption
42% have signed the I2 Net+ agreement, 11% have enterprise agreement with cloud provider
21% have containers/serverless in production, 9% non-prod, 70% not currently adopting.
Managing and Automating a Multi-Account Strategy in AWS: Brett Bendickenson (Arizona)
Have their own agreement with AWS. Currently have about a 75 accounts in their consolidated billing. 24 accounts in central IT.
UITS Cloud Advisory Team — cross functional group from within UITS to advise and decide on cloud practices and policies.
- Tagging Policy – extremely important to get right up front. Service, name, environment, created by, contactnetid, accountnumber, sub account
Multi-account strategy. Workloads segregated into production and non-prod accounts. Tipping point was properly restricting everything by permissions – can do it with IAM roles, but it’s a lot of work. Decided on further segregation by teams / technologies, e.g. Kuali, PeopleSoft, IAM. Each has prod and non-prod accounts.
Each account has an account steward (director or dept. head) — responsible for spend, security, etc. Each account has an email list, with the address used for the root login address. Password stored in common vault, secured with MFA hardware token (kept in Ops). Linked to a central billing account. Set of account foundation templates are deployed. Started using AWS Organizations.
Account foundation modeled after the AWS NIST 800-53 Quickstrart CloudFormation Template. Set of CloudFormation templates which deploy roles, security controls, etc. Sets up an EC2 instance that runs a set of Ansible playbooks that set up Shib, bas AWS info, IAM, Logging, Lambda.
Federated Roles – SysAdmin, IAMAdmin, InstanceOps, ReadOnly, BillingPurchasing. Using Grouper for authorizations.
Using federated identities, no IAM users (generally).
CloudTrail enabled in all accounts. Enabled for all regions, records all API calls, sent to a central S3 Bucket in root account. CloudTrail logs also saved to CloudWatch logs in account for local reference.
Alarms set for changes in Network ACL, Security Group changes, Root Account activity, unauthorized access, IAM Policy changes, access key creation, cloud trail changes. (not all used in non-prod)
Lambda Functions – Alarm details (interrogates cloud trail events and sends actual API calls that raised the alarm); CreatedBy automated tagging for EC2 instances; OpsWorks tagging helper; OpsWorks tagging helper; Route53 helper (updates DNS); Tag monitoring – checks tags on instance launch (looking at Cloud Custodian from CapitalOne (open source)); AMI lookup
Arizona’s code: https://bitbucket.org/ua-ecs/service-catalog
Oren Sreebny 