MMS • Matt Campbell
Article originally posted on InfoQ. Visit InfoQ
AWS has created a new language for defining access permissions using policies called Cedar. Cedar is currently used within Amazon Verified Permissions and AWS Verified Access. Created by the AWS Automated Reasoning Group, Cedar is designed to be agnostic of AWS and simple to understand the effects of policies.
Cedar policies are comprised of an effect, scope, and condition clause. The effect is either one of permit
or forbid
. As with IAM policies, an explicit forbid
overrides any permit
statement. However, an explicit permit
is required to gain access as the requests are implicitly denied.
permit(
principal,
action == Action::"connectDatabase",
resource == Database::"db1"
) when {
context.port == 5432
};
The scope is used to specify which principals, actions, and resources the policy affects. It can be left undefined, which causes the policy to be applied to all possible requests as long as the condition clause is met. Ian Mckay, Cloud Principal at Kablamo, notes that
The scope is generally used for role-based access control, where you would like to apply policies scoped to a specific defined or set of resources, actions, principals, or combination thereof.
The condition clause is used to specify the context in which the effect applies. Typically there will be one or no condition clauses, but Cedar supports any number of clauses. There is a basic set of operators available including comparison operators, Boolean operators, and collection operators such as exists
, in
, and has
. Mckay notes that condition clauses are “intended to perform attribute-based access control”.
Cedar has built-in support for defining policy templates. A policy template can be used to simplify creating policies that have similar structures but differ only in principal or resource keywords. If the base template changes, any derived policies will be automatically updated. The question mark operator is used to provide a placeholder for later variable substitution:
permit(
principal == ?principal,
action == Action::"download",
resource in ?resource
) when {
context.mfa == true
};
Cedar also has built-in support for IP addresses and decimals through extensions. Extensions are called using a function-style syntax and must be operated on using the built-in methods. A policy that confirms that the IP address is within a valid CIDR range would look like this:
permit(
principal,
action,
resource
) when {
ip(context.client_ip).isInRange("10.0.0.0/8")
};
Designed by AWS’s Automated Reasoning Group, Cedar is built such that automated reasoning tools can be built to analyze policies. Reasoning as it relates to policies could be attempting to deduce if two policies are the same or if a particular policy will grant access. According to Byron Cook, Distinguished Scientist at AWS,
An automated reasoning tool does this work for us: it attempts to answer questions about a program (or a logic formula) by using known techniques from mathematics.
Reception to the news was mixed on social media with user rendaw sharing that “rather than make a new language, they should have made a WASM or eBPF API and just let people use the full power of whatever language they want.” User Taikonerd worried that the agnostic nature of the language won’t be effective, stating that “my worry is that there will be statements that only make sense with one cloud provider”.
At the time of writing, Cedar is available within Amazon Verified Permissions, AWS Verified Access, and the Cedar playground.