Amazon Web Services

Cloud Providers

Use this graphic and write-up to upskill on AWS ECR super fast. You'll know enough to build containers and push them live in a few minutes

Cheat Sheet: AWS Elastic Container Registry (ECR)

Level up on AWS Secrets Manager, IAM, and learn to store and manage secrets

Cheat Sheet: AWS Secrets Manager

Level up on AWS KMS, IAM, and learn to secure AMK (AWS) and CMK (Client managed) keys and manage access

Cheat Sheet: AWS KMS

Level up on AWS S3, IAM, and learn to store data and manage permissions to the resource and stored data

Cheat Sheet: AWS S3

High quality and independent AWS content from Andreas and Michael Wittig. 

Cloudonaut

Assume AWS IAM roles from GitHub Actions workflows with no stored secrets

Action2AWS

Security summaries and snark by the infamous Corey Quinn

Last week in AWS Security

Unauthenticated enumeration of services, roles, and users in an AWS account or in every AWS account in existence.

Quiet Riot

IAM Least Privilege Policy Generator

Policy Sentry

This tool is designed to prevent the deployment of unwanted IAM identity-based and resource-based policies to your AWS environment.

IAM Policy Validator for AWS CloudFormation

AWS Elastic Container Registry (ECR)

Cloud Services

Permits connection from only a specific public IP range

AWS ECR Resource Policy: Block Outside Specific Public IP Range

Grant n AWS accounts, any principal, to connect to ECR resource and upload images with any tag

AWS ECR: Permit Cross Account Image Upload

Grant n other accounts access to this ECR, account-wide. Use more specific principal for better security

AWS ECR, Permit Cross Account Image Download

AWS Secrets Manager

AWS KMS

Policy for principal (User, Service) to access cross-account secret and KMS CMK (decryption key)

Principal Policy - Permit Access to Cross-Account Secret and KMS Key

AWS CloudFront

For public access, permit only specific CloudFront distribution

S3: Permit Only CloudFront Specific Distribution

IAM assume role trust policy which permits assuming only from specific role(s)

Assume Role Trust Policy with Conditional to Limit to Specific Role

Amazon RDS

Terraform

Code Frameworks

Working backward from a resource to see who can access it based on which policies

Traversing Access Paths From a Specific AWS RDS Instance 

What happens when you encounter implicit differences in AWS services?

Handling Implicit Differences in AWS IAM Defaults

Amazon S3

Removing S3:* in favor of explicit actions to better control access to sensitive data

Changing AWS S3 Shadow Permissions

AWS IAM Deep Dive. Chapter 3: Credential evaluation, Principals, Conditions, Policy variables

AWS IAM: Best practices [Part 1]

As a software developer, you're constantly in demand... and being demanded to learn new things constantly. AWS IAM is a topic that keeps coming up – but how much should you really learn about it?

IAM a Developer - What Do I Really Need to Know About AWS IAM?

Least Privilege, IAM Groups, and IAM Strategy

Takeaways from AWS IAM

 is the Cloud Security Chick (well, officially the Cloud IAM Advocate) at IAM Pulse. She's part of our community team, and loves to connect with cloud operations and developers (read: that's you!). If you'd like to meet up with the community team and discuss your solutions, hacks, or how you'd like to help us elevate the practice of IAM, please reach out! 

Calm Cloud Security - AWS ECR Primer - Theory

GitHub Repo with all Commands and Terraform Code

 - You can and should run the entire demo yourself

I hope you're all doing great. Welcome back to our series on Calm Cloud Security - where we learn the theory and practice of cloud security without any gatekeeping.

As I'm recording this video, it's almost seventy degrees out, after a long, long winter! As soon as I'm finished with this video I'm going to go soak up the sun.

In our last video, we talked about what an ECR does as well as some basic theory around containers. After all that lofty theory, I want to put it into practice, and I bet you do too! In this video we'll build a container image with docker, test it, and push it to an ECR.

Let's start in the AWS console. I've already authenticated and run a terraform apply of our github terraform code, so we have an ECR. You can see the name there is "our-new-ecr", with the resource address over on the right.

Let's click into the ECR and you can see there are no images. If there were any, each one would be listed here with size, date and other info

Let's look at the image we'll be building.

First let's look at our Dockerfile. Here it is in Visual Studio Code so we get the pretty colors.

On line 1, we're grabbing the latest version of ubuntu:20.04 from the docker hub online. Docker will cache this image locally so next time we build it'll be even faster

On line 4, we're copying a script called "docker_start.sh" into the image at the "." location, which means working directory of the container's disk. Since we didn't set a working directory, docker defaults to the disk's root. We'll look at that script in a second.

On line 5, we're setting that script to be executable, which we need since we'll be running it as our next step.

And on line 9, we set an ENTRYPOINT of that same script, which means when the container launches, this script is run. As soon as the script finishes, the container will shut down and self-destruct. That's totally normal and desirable.

On line 1 and 2, we tell this script to run using bash, and "set -e" which means to exit if there's an error.

On line 5, we check to see if MY_NAME variable is set to empty. If it is, we immediately send some custom error message and exit with an exit code of "1". In almost all software, an exit code other than 0 indicates something went wrong.

If we get past that check, then on line 12 and 13 we print out a few lines of response using the MY_NAME variable. Let's not dig into that too much yet - it'll be more fun when we actually build and run it!

Let's switch to our terminal and build our docker image.

Right off, let's set some variables we'll use in our commands. First, a local docker name. Docker calls this a "repository", but this is all local, and you can use whatever name makes sense to you.

Then let's set a docker tag to use when we publish to our ECR. We'll use a really easy pattern - "latest". Latest is also assigned to images in an ECR by default if they don't have a tag.

Finally, let's actually build this container. Let's run docker build. The period means to look in the directory we're in, and the -t means a tag of the variable we set above of "hello-name". If you get an error here about failing to connect to docker make sure you have the docker service started!

Let's run "docker image ls" to look at the local docker images, and sure enough, we see our "hello-name" docker image built only a few seconds ago, awesome.

Let's test our docker image locally. The command to run a container is, intuitively, "docker run" and then the local image name.

When we do that, we see our custom error message reminding us that we forgot to set the name variable. Remember, from the entrypoint script? Checking to make sure we have all the variables we need to run successfully is a super common pattern, and custom error messages are even more best practice. Let's set the variable and build again.

We use the "-e" flag to set an environmental variable inside the launched container of MY_NAME=Kyler. Feel free to set this to your name and run it!

We get a different message, this one telling us that our container ran properly without issues, and it even politely said hello. Pretty cool.

Next up, let's push our image to the ECR!

We could hard-code the name of the ECR and the region name we built everything in, but we have direct access to terraform, and it can print these outputs, which is a really cool way to harvest info from Terraform, so let's do that instead.

We'll use the "terraform output" command to print some outputs from the configuration. Here's what that will look like.

Next let's run the same commands but trap the response as variables so we can use that info in other commands.

The way to prep our image to be pushed to a repository is to map the local image name to a remote ECR name with a tag. The "docker tag" command does the trick, like this.

And then run the "docker image ls" command to look at our images again. Now we can see what looks like a totally new image, but we didn't build a new image! If you look under "Image ID", you can see that this is the exact same image, but using a different "repository", or name.

Okay, let's push our image to the ECR! Or not! When we push, we get an auth denied message. Even though we have valid AWS credentials in the environmental variables of this terminal, our push fails. That's because the docker tool isn't able to use the AWS credentials to authenticate.

However, clever AWS engineers are prepared for this. First let's grab our region, then we can run "aws ecr get-login-password" to print a password out, and we'll use some neat bash to trap the response and pipe it right into a "docker login" command.

If you see "login succeeded" like we do, docker is now able to authenticate to the ECR, woot! Let's try that push again:

Okay, something is happening, it looks like it's pushing! Let's jump ahead to when it finishes, and we see a new error message which is very helpful - it says there is a IAM resource policy on our ECR that denies us from writing to it.

Let's switch to the AWS Console and find that ECR again, and pull up the "ECR Permissions" to find the resource policy. We do see a policy at the bottom that denied my user from putting an image into the ECR, oh no!

Let's fix it in the console. There is a graphical policy editor specific to just ECR, but I'm more comfortable editing the json directly, so let's hit "edit policy JSON" in the top right. Let's find the second stanza that is blocking my user from uploading an image to this ECR and delete it. Then let's hit save in the bottom right.

Let's switch back to our terminal and run the same command again. This time it'll succeed!

Let's spend 1 minute looking at our ECR to verify the new image is there.

When we click into the repository this time, we see the image we just pushed is now present. This ECR is internal, so any of our team can download it and run it themselves.

We can also see over on the right that AWS has already scanned this image and there are some vulnerabilities within it. Let's select details and we can see a run-down of all the vulnerabilities AWS has found.

We could take this information and go bug hunting, but that's beyond the scope of this video.

In this video we covered a lot of ground! We went over common docker and scripting patterns, build a docker image, and tested it. Then we figured out docker authentication into AWS ECR, and THEN fixed an ECR resource policy issue that blocked us from uploading an image.

We confirmed the image was present in the ECR and very briefly saw that AWS has scanned our image for vulnerabilities and we could start remediating them if we wanted.

Please find all the code we ran in the GitHub repo displayed on-screen.

I hope this has been helpful to you! You can find more of these videos at 

, and you can find me @KyMidd on Twitter if you have any feedback or questions, and I look forward to next time.

In this video we'll build a container image with docker, test it, and push it to an ECR

Calm Cloud Security - Containers and AWS ECR

Kyler's is @KyMidd on Twitter - https://twitter.com/kymidd

IAM Pulse is @CheckIamPulse on Twitter - https://twitter.com/checkiampulse

Other Primer videos - https://iampulse.com/videos

Hey all!

I hope you're doing great. I'm working with a friend to plan a tropical vacation, our first in years. It'll be the first time we've traveled further than Costco with our infant daughter, so please wish us luck!

Today we're going to be talking about the AWS ECR, or Elastic Container Registry. This is AWS's container image hosting resource - image meaning a bootable file built by docker or a similar tool. In our next video we'll actually build an ECR and docker image, then push the image to ECR with tags.

For you to understand what ECR is and how IAM can help secure it, you'll need to understand the basics of what Docker and containers are. Let's start there.

Let's do a quick walk through the history of enterprise compute and how we got to containers. 

Back in ye olden days, we had big mainframe computers! Okay, it wasn't that long ago. But these were individual operating systems on very big hardware. These are like your laptop or desktop computer - 1 OS on 1 hardware box.

Then we had virtual machines, where we had newer versions of these huge mainframe computers, and we put lots of VMs on them. Each VM is isolated, and we had a hypervisor which helped each VM share the hardware that these VMs needed to work. This saves a lot of money and provides great flexibility and operational ease. No more walking to the data center to reboot a stuck host for you!

Containers are the next evolution of compute, and they're springing up everywhere. Containers share their kernel, the central part of the OS, with the underlying hardware's kernel. This is slightly less secure, but much faster - booting a container takes only a few seconds! Containers are built to scale out, by launching more containers in a cluster, rather than scale up, like launching a larger VM or buying bigger hardware.

Lots of companies you've heard of are starting to use containers due to a host of benefits. Google, Netflix, and Uber use them extensively, but also smaller companies are finding the benefits outweigh the cons.

Let's talk about how container images are built.

Building and running containers are totally separate processes. Let's talk building them.Container images are built from a flat text file that looks like a simple shell script. Docker's build process reads this file from top to bottom, and executes the instructions to generate a binary container image that can be run by docker. Let's look at one of these files at the most common actions.


On line 1, there is a FROM command, which tells docker to use the local image on our build computer named "ubuntu" with a tag (after the colon) of "20.04", which is a version of Ubuntu. If docker can't find the image locally, it reaches out to the Docker hub, a public container registry hosted by the company that makes the docker tool. These images are very lean, and will download quickly.


Then on line 4 we have a COPY command, which takes a file from our build computer and puts it into the docker image.

Then on line 5 a RUN command which uses the native shell in the container and executes a command. In this specific example we're using chmod to make that copied file executable, but you could do anything the native shell could do. It's very common to load up tools you need for your workloads with YUM or APT.

And on line 9, the ENTRYPOINT. This is the command or service that is natively run when the container is launched. This is often the single job the host has to run. Most container running tools watch this entrypoint service, and once it stops, the container is terminated - its job is done.

Let's talk layers.

Docker's build and image registry all support the concept of layers. Each of the commands we just went over in the last section is treated as a "layer" of the container image.

Each layer is only rebuilt if that layer's command has changed, or if an upstream command has changed. For instance, if the only difference since the last build is the command on line 5, line 1 and line 4's commands aren't re-run - those layers are saved from last time and used again.

However, line 5's command has changed, so we have to recompute that layer, and that changes all the layers past it, so we have to also computer line 9, and any other line after line 5.

This isn't super important until you get into making containers build really efficiently, but you'll see layers during your build and push process and I want you to know what they are.Let's talk about tagging images.

When you build an image with docker, you have the ability to set a tag. And you should! It makes it way easier to keep track of what is what by assigning a human-readable name to your images.

Tags are comprised of a name, like "ImageName" and a version, like "v1.0.4". Both can be characters or numbers or both. You set the local tags when you build the image, and then you create a mapping between the local image name and tag to a remote name and tag, even if the remote tag doesn't exist yet.

That mapping is created entirely on your build computer, and then you "push" the image to the ECR. If "tags" and "push" sound familiar, it's because docker uses a lot of the standard concepts from git to manage code.

Push requires authentication, and we'll go over how to do that in the next video.

One other important note in container tagging on an ECR, there is the concept of tag "mutability" which is a true/false flag of whether a tag over-write is supported. Some business units want to over-write a tag like "prod" and some never want that - they'll pin their services to specific image versions and carefully control what points where.

Let's talk security!

We'd be remiss to skip over security and IAM resource policies for this resource. By default, ECRs don't have an IAM resource policy, and permit any same-account principal to connect to it from any region.

If you want to protect your ECR more strongly, or share access among several accounts, you're going to need an IAM policy for this resource. You can permit principals to only upload, only read, or anything in between.

In this video we learned all about docker and how the AWS ECR can host and protect our images.In the next video in this series we're going to get down and dirty with AWS ECR. We're going to build an ECR, build a docker image and test it locally, then tag and push that image to the ECR where other services and humans can get to it.

Please like and subscribe and come visit us at IAM pulse.com. I'm Kyler Middleton, 

 on twitter, and I hope this helps you level up your cloud security skills.

A walkthrough of AWS's container image hosting resource Elastic Container Registry (ECR) 

Stephen Kuenzli of K9 Security walks us through how to evaluate cloud environments and secure them using Identity and Access Management (IAM), as well as other tools.

I'm Stephen Kuenzli, author of Effective IAM for AWS and IAM Pulse contributor.

I spent years leading AWS migrations and we always found IAM to be the hardest part. Now I’m making AWS IAM usable for Cloud teams.

Today we're going to talk about what to do when you need to clean up an AWS organization that maybe you just inherited. Or maybe it's your own organization that’s grown messy and you need to clean it up quickly.


Let's set the scene. You've just acquired another company and there are eight AWS accounts.

There are 25 known apps and at least as many data stores. Some apps are sharing IAM roles.

The access controls found in due diligence are spotty, at best.

You've been challenged with securing the critical data in those accounts within three months.

So your company can integrate features from the acquisition into your services while maintaining your security posture.

The project which created equivalent controls with custom least privilege policies for each app took a year for your other accounts. What are you going to do?




The old way? It’s too slow. It’s not going to get you there in time.

There are 25 known apps in these accounts. Each has at least one data store. Some data stores are shared.

It's not going to be possible for your organization’s two IAM experts to learn and secure two unfamiliar apps each week.

The app engineers aren't IAM experts, so they're not going to be able to write least privilege policies. At best, they can provide high-level information about what data each app needs to access.

Looks like we're headed for overloaded experts, ineffective security or both.

But there is another way. We can focus our efforts on the critical data, which is the goal of this project.

And we can use resource boundaries to protect that data.

But we still have to deploy this solution to 25 applications and at least as many data stores in time.

So we need to codify protecting data with a resource boundary in easily usable component.

So let's dig into this new solution.


Slide: Control data access with Resource Boundaries (02:27)

A resource boundary controls access to critical data and can simplify access review.

You create resource boundaries with resource policies that control access to that data resource or encryption key.

First, you control the Identity dimension: who can access the data? How?
Second, you control the Network dimension: where can authorized identities access the data from?

So you can put the access control close to the resource being protected.

Our secret weapon here is the Key Management Service, KMS.


Slide: Control Access to data with KMS (02:59)

We can control access to data with KMS. I mean, that's what encryption is all about. Encryption is not just a compliance checkmark. It’s about access control.

Encryption scrambles data, so no one can understand it unless they have the key. AWS makes encryption easy. And KMS supports resource policies so you can control who can use the key.

More than 65 data services in AWS support encrypting data with KMS. That includes all the core data services like DynamoDB and RDS.

When you encrypt data with your own customer managed key, you can control who can call encrypt, decrypt, and administration operations.

So we can identify the data for each application or data domain like Accounting, Ecommerce, or User Profiles.

Then we can encrypt that data with a dedicated key.

Now we can use KMS key policies to allow authorized applications & people the access they need and deny everyone else.

When an app or person needs to access encrypted data in a service like S3, the service will request an encryption operation on the requesting principal’s behalf.

For the request to succeed, the requesting principal must have permission to use both the data service api with the resource and the key protecting the data in that resource.

So to read an encrypted object from S3, an IAM principal must be allowed to call S3:GetObject on the object, and KMS:Decrypt on the key protecting the object.

And if you don't have privileges to encrypt or decrypt with that key, you can't read or write the data.

The details of this are explained in the book Effective IAM: Simplify AWS IAM chapter 5.


Slide: Identify Critical Data Sources (04:52)

Okay, so what are we going to do practically?

First, let's identify the critical data sources. We'll start by asking app engineers where the critical data is. They may not be able to describe a policy, but they can tell you where the data is and generally who should have access to it.

And they should be able to describe what kind of access is needed. Does their app need to read data?

Should it be able to write data to that RDS database or a DynamoDB table? Does it need to create SQS queues?

You also need to inventory the existing KMS keys and see where they're used.

Based on my experience it’s unlikely they have a key policy that prevents use by over-permissioned identities with KMS:Decrypt on all keys.

Determine what data goes together and draw a diagram. Group data resources together into their natural data domains, just like on the previous slide. This will typically align to an app or functional grouping. We’re going to create a security domain out of each of these data domains by protecting it with an encryption resource boundary.


Slide: Design your resource boundaries (05:52)

Now let’s design the encryption resource boundaries.

And pair with the application engineers to determine who needs to read and write in and out of that domain.

Often there will be multiple applications accessing certain data stores, and you'll need to give them appropriate privileges. Some app identities will need to read, some write, some both. Record this information in that same high level language.

We don't need to get into specific API actions at this point. And you don’t have time for that discussion anyway. Simply: read-write to this data store or that data store.

Now adopt a usable KMS key policy automation solution where the app engineer can understand and review the inputs.

In fact, that automation, library or tool needs to understand what you and the application engineer just described.

AppA needs to read and write to that data store.
AppB only needs to be able to read.
The CI/CD system needs to be able to administer those resources, et cetera.

Let’s see how engineers should be able to specify their intended access control.

So we can see what a usable access control automation interface should look like.

It will be close to our human readable description.

First we translate our access data table into variables that define the principals who should have each access capability.

We've lifted up the conversation from the low level details of IAM security policy to a language nonexperts can understand and review.

Now the library turns these inputs into nearly 200 lines of key policy implementing least privilege. There are statements allowing each capability for authorized principals and denying everyone else.

And this is what we need to get this job done quickly while improving security greatly.

Slide: Encrypt Everything with KMS! (07:54)

Here comes the best part. Encrypt everything!

First provision the KMS keys and policies using automation. Then Enable encryption for each data source.

Do this in Dev first, of course. We don’t want to just slap this into production.

Go switch those DynamoDB tables, switch RDS databases, S3 buckets, etc to use the key for that domain.

Now each of your critical data sources is shielded by a resource boundary.

Also recognize that these policies, and security policies in general, are really part of the application.


Now, celebrate. You've completed your mission!

You’ve also scaled security out to application engineers.

They can now take responsibility for maintaining what those inputs are. After all, they were the source of those high level access definitions. They're not necessarily equipped yet to make enhancements to the automation you adopted. But they can work with you on that.

On top of that, you've simplified Access review. Now you can both use this higher level language to discuss security controls.

And that's how you clean up an AWS kitchen sink.

I hope this has been helpful. Please feel free to contact me with questions or comments on Twitter at 

Shift IAM Left
Bring IAM Up

We provide tools and helpers for cloud teams to right size your IAM permissions with less guesswork

IAM for Everyone

Get IAM Tools

Get IAM Help

The missing clarity in your cloud permissions

Gain IAM visibility in your infra code

Determine risk impact of changes

Visualize & navigate access vectors

Navigate the IAM Landscape

Traversing Access Paths From a Specific AWS RDS Instance

Handling Implicit Differences in AWS IAM Defaults

Changing AWS S3 Shadow Permissions

Learn IAM From the Community

Cheat Sheet: AWS Elastic Container Registry (ECR)

AWS IAM Deep Dive. Chapter 3: Credential evaluation, Princip...

Cheat Sheet: AWS S3

AWS IAM: Best practices [Part 1]

IAM a Developer - What Do I Really Need to Know About AWS IA...

Takeaways from AWS IAM

Join the beta waitlist

Sign Up for the community

Shift IAM Left Bring IAM Up

We provide tools and helpers for cloud teams to right size your IAM permissions with less guesswork

IAM for Everyone

Get IAM Tools

Get IAM Help

The missing clarity in your cloud permissions

Gain IAM visibility in your infra code

Determine risk impact of changes

Visualize & navigate access vectors

Navigate the IAM Landscape

Traversing Access Paths From a Specific AWS RDS Instance

Handling Implicit Differences in AWS IAM Defaults

Changing AWS S3 Shadow Permissions

Learn IAM From the Community

Cheat Sheet: AWS Elastic Container Registry (ECR)

AWS IAM Deep Dive. Chapter 3: Credential evaluation, Princip...

Cheat Sheet: AWS S3

AWS IAM: Best practices [Part 1]

IAM a Developer - What Do I Really Need to Know About AWS IA...

Takeaways from AWS IAM

Join the beta waitlist

Sign Up for the community

Shift IAM Left
Bring IAM Up