Spring 2018 AWS Labs

We’ve locked in our Spring lab schedule:

  • January 17: 9:15 to 11:15 a.m. in 28 Illini Hall
  • February 7: 9:15 to 11:15 a.m. in 27 Illini Hall
  • March 7: 2:30 to 4:30 p.m. in 27 Illini Hall
  • April 11: 9:15 to 11:15 a.m. in 28 Illini Hall
  • April 25: 2:30 to 4:30 p.m. in 28 Illini Hall
  • May 9: 9:15 to 11:15 a.m. in 28 Illini Hall
  • May 23: 2:30 to 4:30 p.m. in 28 Illini Hall
  • June 6: 9:15 to 11:15 a.m. in 28 Illini Hall
  • June 20: 2:30 to 4:30 p.m. in 28 Illini Hall

During each lab session, you’ll have your choice of topics:

  • AWS 101: Introduction to EC2
  • Identity and Access Management
  • S3 and CloudFront for content distribution
  • Relational Database Service
  • Automating AWS with CloudFormation
  • Introduction to Lambda
  • Building clusters with Alces Flight
  • Elastic MapReduce

You may run through multiple labs if time allows.

Technology Services will grant you access to a shared AWS account for the lab; you don’t need your own. Computers will be available onsite, though you’re welcome to bring your own laptop if you prefer.

An Amazon solutions architect will be on site along with University of Illinois staff to guide you through lab materials and discuss cloud topics.

Please register here to reserve your seat.

AWS Security Maintenance: Meltdown & Spectre

Amazon is in the process of planning how to patch their remaining EC2 hosts to protect against Meltdown and Spectre. Official details are here:

https://aws.amazon.com/security/security-bulletins/AWS-2018-013/

We’ll probably receive a small number of maintenance notifications in the next few days. I’ll try to forward those onto account owners in a timely fashion. Since Amazon is trying to fully remediate as quickly as possible, we can expect substantially less lead time than Amazon provides for normal maintenance.

Amazon’s work should protect their hypervisors, disallowing use of the attacks to break out of a VM, but you’ll still need to update the OS inside your VM to protect at that level.

re:Invent Service Launches

Amazon re:Invent was held last week in Las Vegas. We saw a lot of exciting announcements, some expected and some more surprising. Amazon has the major launches detailed here:

https://aws.amazon.com/new/reinvent/

For our campus usage, I’m most excited about these:

  • Fargate – makes containers easier than ever before.
  • ECS for Kubernetes – allows container management with Kubernetes, which may be how you’re already doing it.
  • Hibernation for Spot Instances – don’t lose your work if you get outbid.
  • New Spot Pricing Model – smooths out spot market pricing to avoid sudden surprises.
  • Aurora Serverless – auto-scale database capacity, even down to zero (with a quick scale-up when you need it again)
  • DynamoDB Backups – I can get rid of the scripts I wrote to back up DynamoDB; they don’t work as well as the new service.
  • Comprehend – process spoken language.
  • Translate – translate between spoken languages.
  • SageMaker – machine learning made easy.
  • Inter-Region VPC Peering – we’re evaluating how we can make the UOFI Active Directory available in regions outside us-east-2.
  • PrivateLink – access private services without advanced VPC configuration.
  • GuardDuty – use AWS’ behind-the-scenes machine learning to alert on unexpected behavior within your account.

git-secrets and AWS credential management

We’ve seen a few account compromises on campus resulting from AWS IAM credentials checked into a public Github repository.

I encourage our customers to implement Amazon’s git-secrets package, which will automatically scan your code for keys and reject a git check-in if they’re found.

But if you’re not putting keys in your code, where should they go? A few suggestions:

  1. If you’re running from an EC2 instance, you can use an EC2 role to grant access to any API calls originating from that instance. This is my preferred method because no key management is required.
  2. Create local profiles that store credentials outside your application. “aws configure” will get you started with the AWS CLI.
  3. Populate your environment variables, again pulling the data out of your code.

Amazon documents their best practices for managing AWS access keys, which includes more options and more detail.

Besides handling credentials carefully, it’s useful to give your application the least privileges it needs. I recommend creating a dedicated IAM user or role for each application and granting it only the permissions it needs. Attackers tend to be most interested in credentials that allow them to launch EC2 instances. If your application doesn’t need that capability, you can dramatically limit the potential for attack.