Once an account has been provisioned. There are a number of configuration items to set before providing the account to its eventual owner. Admin role creation, linking the account with a campus Identity Provider, and enabling logging are just a few of the items. Some of these can be completed programmatically, but others are a strictly manual process. Below are some examples of how the community is tackling this work.
Using Shibboleth for AWS API and CLI access
A plugin for the AWS command line tool that allows a user to generate temporary credentials via Amazon's STS using SAML via ECP with support for Duo for authentication. This has the obvious security advantage that a user no longer needs to store long term credentials on disk.
Cornell University Example
In consultation with Cornell IT Security Office and Cornell financial administrators, two "standard" configurations of AWS accounts have been defined, one for general uses and one for research. Each configuration follows AWS, Cornell, and security best practices. Not all best practices can be implemented by policy and configuration. Individual AWS users also need to follow best practices see the Cloudification Services Tech Blog and AWS IAM best practices documentation.
AWS Account Setup Example GitHub Repo: https://github.com/CU-CommunityApps/aws-account-setup-example
University of Arizona Example
The University of Arizona has a set of CloudFormation templates we use to set up new central IT accounts.
U of A CloudFormation Template Library: https://bitbucket.org/ua-ecs/service-catalog
University of Iowa Example
Dave Miller presenting on May 22nd, 2017.
University of Illinois Example
University of Illinois uses Active Directory and Shibboleth to grant access to an AWS account. AWS accounts configured under our campus contract use Shibboleth as the default login mechanism to the AWS Console. More information can be found here: https://answers.uillinois.edu/page.php?id=71883