How Origin Access Identity works

Origin Access Identity is used to access private S3 buckets. Unfortunately, this is the only use case it supports

Background

The Origin Access Identity (OAI) is the primary way to make CloudFront access private content stored in S3. Without it, CloudFront is like an anonymous user, it only has access to content everybody else has access to.

When you make the bucket private, you forbid even CloudFront from accessing it. In many real-world scenarios, you want your visitors access the content only through the distribution, and not directly. This is where OAI helps.

When you point the distribution to an S3 bucket, you have the option to create an OAI and provide access to the content. It can be done by updating the bucket’s resource policy either by hand or by checking the “Grant Read Permissions on Bucket” option and let CloudFront do that for you automatically.

But how does it work exactly?

How OAI works

OAI is an IAM subject that can be referenced in a resource policy. It does not create a full-fledged IAM user, so you don’t see it in the IAM service and you also can’t attach policies directly to it.

Then in a resource policy you can reference it as a Principal. When you do that, you can write a policy that only allows a specific subject to access a resource and nobody else:

{
	"Effect":"Allow",
	"Principal":{"CanonicalUser": "<OAI>"},
	"Action":"s3:GetObject",
	"Resource":"<bucket>"
}

Can it be used for anything else?

It seems like there is nothing S3-specific in how CloudFront uses OAI to access a resource, so I was curious is there any other service it can be used?

These are other services that support resource policies, and maybe they also support specifying the OAI in a permission?

As it turns out, only S3 is supported, as you can not add OAI to any origin besides S3.

Revoking permissions

If you need to revoke an OAI’s permissions to a bucket, keep in mind that it is only used when CloudFront fetches the origin. Therefore, the content may still be available from the caches.

In the rare case you need to revoke OAI permission, make sure to also issue an invalidation to purge the cache after changing the resource policy.

Conclusion

While the name “Origin Access Identity” has nothing to do with S3 and should be a general concept, it can only be used to access private buckets and nothing else.

27 November 2018

Interesting article?

Get hand-crafted emails on new content!