other words, how you can, and your services perform actions securely? All types of IAM roles: • Service roles • Controls what the service can access on your behalf( for example, access to DynamoDB) • User roles • Represent a person, and what they can access. Forexample,a role “abby” with administrator access • Groups • logical groupings of IAMUsers with shared permissions
worth a whole talk on its own. A few words of advice: • Rotate your keys, don’t share them between a) services, b) humans • Go for “principle of least access” • Where possible, store your keys somewhere else, and then control access (for example, store keys in KMS, and control access with IAM/service roles) • There are also third party tools out there (lots): for example, Vault
your containers themselves Lean on tools to check your images for vulnerabilities. A couple of options, both paid and open source: • Aqua MicroScanner (community edition) • Aqua continuous image assurance • Docker Security Scan with Trusted Registry • Clair from CoreOS
local environments help eliminate “well it worked on my machine” • Some common approaches to this: Vagrant and/or VirtualBox, EC2 box with local access • Any approach should have a few things in common: shared configuration between team members (i.e., running the environment uses the same versions of packages), and is as close as possible to the production environment.
commands against Kubernetes clusters. • kops: kubectl for clusters. Can use to manage production Kubernetes infrastructure in AWS. • kubeadm: bootstrap production-ready Kubernetes clusters, following best practices. Not production ready, but cool: • kubicorn: helps users manage their Kubernetes infrastructure
code: automate and template everything from your containers to your infrastructure. This makes everything repeatable and portable! • Containers can be built directly from repositories as part of your CI/CD process. • After that, automate your AWS!
for describing, creating, and deleting AWS resources. • Created and maintained by Amazon. • Free to use, just pay for the resources created. Don’t like writing Cloudformation templates? There are samples and snippets here.
Either one works! Both focus on resource management. Cloudformation: planning and execution in one step. Meaning, just executes. Terraform: planning and execution in two steps (terraform plan, terraform apply) A less JSON-y option: Terraform!
noise • Page only on issues that require immediate, emergency attention • You need all of it- both monitoring AND observability (more than just logs!) • Make sure you’re asking and answering the right questions.
AMI, but life is too short to not have custom AMIs. A few steps to registering your own AMI with ECS: 0. Make sure your AMI has the right requirements! 1. Install ecs-agent 2. Install Docker daemon (if it’s not already installed) 3. Register instance with cluster Most of these options can be set in EC2 user-data (more on that in a sec)