Last Updated June 17^th, 2023

Every year, I look forward to AWS re:Inforce, a gathering that allows me to reconnect with friends and colleagues, discover new AWS security services, and expand my knowledge.

Event Overview

This year was no different, although the keynote announcements were a little less explosive than usual with no big new blockbuster service being announced. However we did get some new toys, like Verified Permissions going Generally Available, Amazon EC2 Instance Connect Endpoint (a bastion replacement), Amazon GodeGuru Security, and Amazon Inspector Code Scans for Lambda going GA and adding SBOM exports (among other items).

In addition to those, probably the two most talked about topics at re:Inforce this year were AWS Security Lake, announced as Generally Available back in May, and GuardDuty’s runtime monitoring of Amazon Elastic Kubernetes Service (EKS), first announced back in March. These are both making a big splash in terms of detecting and responding to unwanted activity in your AWS environments. Personally, I’m a fan, especially of something that helps to protect a Kubernetes runtime using telemetry from eBPF (Extended Berkeley Packet Filter; a way to run software inside of the kernel which is extremely low overhead and performant), while also being easy to deploy, maintain, and monitor. Historically, I’ve used third party tooling like Falco or Cilium, which are still very valid options for many situations, just with a bit more maintenance overhead.

Verified Permissions and Cedar

One of the big announcements, Verified Permissions, is backended by a project announced in May called Cedar. This project has a lot of overlap with the Open Policy Agent in the CNCF and when asked, the researchers who created Cedar said there were two reasons for creating an alternative. First was the need to run at much higher speed regardless of the policies defined; Cedar claims < 1 ms policy evaluations due to being written in Rust and performance-optimized. Second, OPA’s policy language, Rego, is very expressive which makes it flexible but also difficult to identify whether two different policies are equivalent.

On top of all of this Cedar is also formally verified... Kind of. The implementation which they formally verify is actually different from what is used in production, but they use a technique called Dynamic Random Testing (DRT) to approximate equivalence between their formally verified Cedar implementation and their production equivalent. A cool approach, which caught a few bugs in their production implementation when it was put in place, but still not enough for me to consider it 100% covered (albeit it is close, and better than many alternatives).

This may be interesting if you’re building a new application and need to include some level of Access Control. Instead of writing this as business logic in your application, you can manage it with Verified Permissions and write your policies in Cedar. That way you can be ensured that regardless of the complexity of your policies, it should be performant, and you can also decouple policy updates from your code deploys. It even works with API Gateway as a lambda authorizer, and has some other nice guarantees like a verified default deny to avoid accidental allows.

Interestingly enough, I learned a little of the background on the project which probably lands in the realm of trivia. Prior to releasing Cedar, AWS used a variety of trees as internal code words, starting with A, and Cedar is the third iteration of that project, which is how it got its name.

CNCF Projects used in AWS

At the conference I also got a chance to poke around with AWS Lattice and speak with some of the AWS team about it. I learned (unsurprisingly) that AWS Lattice uses the CNCF project Envoy proxy as a big part of its backbone, along with other AWS services such as private link to institute the network connectivity. Very cool!

Finally, I got a chance to talk with the AWS team about supply chain security and AWS Signer, a code-signing service. In that conversation, I learned that they chose Notation from the CNCF Notary project over an OpenSSF project called cosign (another excellent project in my opinion) when they compared the two, at least partially due to privacy concerns with rekor (according to the speaker), and the fact that the overall design of cosign is intended more for open source projects than enterprise projects (their words, summarized by me).

The Rumor Mill

While I look forward to the potential for a 2024 AWS re:Inforce, there was also talk that because last year’s re:Inforce targets were not hit (as far as I’m aware, this is unverified), and this year’s event did not seem to have a significant draw (which also seemed to be true from my perspective), it’s likely that they were will not be another one of these events. But, all is not lost! I have also been attending fwd:cloudsec for the past few years and they’ve announced that they will be decoupling from AWS re:Inforce, meaning that it will likely be growing to take the place of AWS re:Inforce, at least for me.

If this sounds interesting, I suggest keeping an eye on fwd:cloudsec and picking up tickets quickly when they go on sale, and you can catch Scott Piper’s “State of the Union” talk here to get an idea of what’s to come.

If you'd like to talk over any of my thoughts here, please connect and reach out on LinkedIn.