AWS Creates New Policy-Based Access Control Language Cedar
infoq.com
infoq.com
At the moment, it usually takes me several iterations to tune the policy.
People forget, AWS is massive and taking care of edge case after edge case while being in a bullet point war with other cloud providers.
Request logging can be performed asynchronously and has much more relaxed latency requirements, but data needs to be aggregated and replicated for durability.
The extremely different requirements pretty much guarantee that these will be two completely separate systems; by Conway's Law, this means two completely separate teams. In practice, logging is more aimed at business analytics and billing.
You're right that the information should be available, and there's no technical reason why it can't be made available, but there are technical reasons which influence the social reasons why it's not available.
On the other hand, I have a tool that calls some AWS services that may in turn call other AWS services. Now if something fails because of IAM denial, I have to go through the logs to figure out what it needed, sometimes it's not even in the logs (S3). Then add it to the policy and repeat to see the next failed call.
I imagine being able to call real API calls, make them succeed and record what permissions it needed for each of those API calls. I don't need that as a permanent log, just as a development tool.
https://docs.localstack.cloud/user-guide/aws/iam/#explainabl...
afaics the only challenge is mapping some of the apis to iam as its only 85% 1:1
There's also tools for helping with iam like (generator, and linter)
Yeah. Try to create an Elastic beanstalk app with only EB permissions.
Is it reliable though? I have experienced many situations where a role has access to a policy and yet the policy simulator said that access is denied due to "organization policy" with no further ability to drill down to which policy it thinks denies access. And it did that when the role did have access to the resource and could work with that resource successfully. So I stopped trusting the simulator. I wonder if others too have experienced similar issues with the simulator.
[1] https://www.oreilly.com/library/view/aws-cookbook/9781492092...
[2] https://docs.aws.amazon.com/IAM/latest/UserGuide/access-anal...
We have some buckets where the cloud trail storage with 1y retention is more than the bucket itself.
When we started working on Cerbos[1] the very first external bit of tooling we released was the Cerbos Playground[2] which does exactly what you say - allows you to see the requests and responses as they make changes to their policies, making it easier to test and refine their rules.
This is a great starting point to prototype and test whether a decoupled authorization system is right for your use case. Cerbos uses YAML rather than a custom DSL to try and address the fact that authorization requirements generally don't sit with developers, rather a product owner of some sorts who is going to want to be able to comprehend the logic behind the permissions model.
It gives me a little hope on the direction and ability to embed Cedar in non-AWS contexts.
In the real case I don't know what context the actions carry that I may use for filtering, I don't know the action names and I may not even know the full list of API calls the tool I use wants to make.
AWS knows (could record) all of the above for me.
You do know all of this with Cedar as the service owner though. You know the attributes on the entities, you know the policies. Something is going over my head, because I don't think I understand the use case. Can you give a concrete example?
Imagine I'm a new AWS customer that creates their account, starts an Elastic Beanstalk application and tries to automate deployment via CI. The access key will need some permissions to EB, EC2, S3, maybe RDS, ECR... The best thing I can do at the moment is to expect that an example policy is somewhere in the docs.
I've been in that position and more often than not I end up doing the "wrong" thing and give a key wider permissions than needed because trying to lock it down is so frustrating (especially if your CI process is long/expensive). Having to wait 5+ minutes for a CI to reach to the end and realized you missed 1 permissions, rinse and repeat 10+ times for "just one more permission" is frustrating/time consuming.
EDIT: Just saw this further down in the thread https://github.com/iann0036/iamlive (which you already replied to) which looks like it does pretty much what I'm looking for.
Cedar has nothing to do with AWS except that it's open sourced by AWS (I think?). It has nothing to do with IAM, an existing way to model policy specifically for AWS owned resources.
What you do once you model your application's authorization concerns in Cedar to make it so action:foo is exposed as usable on resource:bar is up to you, and your business. An anaylzer can be implemented on top of this for your domain and offer the functionality you're describing, but that seems out of scope for Cedar the modeling specification and evaluation engine to provide.
Imagine Cedar as a way for you, a SaaS provider, to add granular access policies like AWS for your own specific resources be it customers, rental cars, food orders, or advertising campaigns. I suspect the majority of use cases aren’t multi-tenant SaaS concerns but very complex authorization over resources internally across services in an organization. Does micro service A have access to update data on resource bar? It’s still hard to model and enforce those things as organizations grow, especially in a domain specific way.
It seems to me it's a tool made in AWS by some team close to AWS IAM. My original comment didn't relate that much to Cedar itself. Rather, I tried to express my long held frustration with AWS IAM which Cedar doesn't solve even though it must have costed a lot of effort.
Don't worry too much about it. I'm just a random Internet commenter talking about a topic that's not even mentioned in the original article but tangentially connected.
The hosted offering is AWS runs an evaluation engine at scale ensuring it's low latency so your own customers can access resources gated by your own entity and policy definitions.
Seems like a missed opportunity to invest in, say, OPA or something in the community to me. Probably was some dude’s L7 promo project in AWS.
Actually a former CS prof at Maryland moving to industry. https://mhicks.me/
These low-effort, borderline ad-hominem comments like yours make these comment threads a terrible reading experience. These comments add nothing to the discussion.
That background was already provided in the comment by fuklief.
What value does the comment by margorczynski add to this discussion?
> which is often how oss projects start
lol
This is yet another ad hominem which I frankly find very distasteful. Plenty of real world software that you see around has been designed by academics and are hugely successful in the real world.
Academics come in all varieties just like your engineers. There are good engineers and there are engineers with years of experience who design terrible software. There are academics who do not design for real world and there are academics who do.
Just throwing around the term "academic" in a loose manner offers no insight on the quality of the work. If there is any valid criticism it should be made on the work, not about the person behind it. That you come to defend ad hominem in more elaborate words goes to reaffirm my original point about why these comments make these threads a terrible reading experience! They often seem to show a shallow understanding of both the academia and the professional IT industry.
We're pointing out that experience provides essential knowledge that a person who hasn't had experience lacks, a simple truth of life. Reading a book about performing surgery is much different than having actually performed the surgery. And someone who has worked in academia (aka "an academic") lacks experience in industry. An academic has not been actually applying the policies in a large organization for years, and thus cannot know or predict all the ways in which the practice of applying the policy can cause problems that do not present themselves in a non-industry setting.
Again, we are not attacking a person. We are specifically saying that any person who lacks experience is not going to make as good of a solution. This is not a controversial statement.
Ad hominem applies to an argument wherein you try to discredit an argument by discrediting the person making the argument. I.E. “Person A is B therefore not C”. In this situation the argument that “This guy is an academic therefor his tool is unneeded” is absolutely an ad hominem.
But even so, let's assume this person has worked directly with customers, and knows how to design for the real world. Why might someone whose job is not being a practitioner, maybe not come up with the best design?
Take for example the product "Terraform", by HashiCorp. It has severe design flaws which anyone who has been forced to use it at scale will find immediately. But the person who invented it, and its subsequent developers, follow a "philosophy" that has nothing to do with working with it in the real world. It was not created by practitioners, for practitioners, but by idealists, for a corporation to ensnare hapless clients that have sadly adopted their freeware and now need to pay for add-on software to manage it. The end result? It sucks balls.
For an Amazon-centric example, take Terraform's competitor, CloudFormation. It's even more horrible. You write your configuration in a data serialization format, in verbose and clunky huge chunks, and (afaik) can't validate or test them without applying them in the cloud. There's no modules or extensions, and it doesn't really change or improve. It's like someone decided to only build the guts of a configuration management engine and told all the users to just figure out for themselves how to use it. You still need to build a whole 'nother software project just to interface with it in a sane way.
Back to the topic: Many other policy languages and tools already exist, many of them open-source. They could have simply adapted those existing solutions and extended them to include whatever novel, genius ideas they had that those other solutions didn't have. But they didn't. Why? I have no idea. But I'm betting it's not because they couldn't write patches for the other tool.
The advantage here is that I can then simulate end-to-end policy what-ifs, and do build-time policy unit tests.
I can also handle business rules in a similar fashion for better visibility - how much of the business understands python/Go/Java/etc code?
I understand the OPA from your description of it as a "datalog(prolog) based search approach" but you didn't characterize what the "Zanzibar based approach" is. Is there a similar short descriptive summary of its approach?
Disclaimer: I am the cofounder of AuthZed, where we are building an open source version of Zanzibar known as SpiceDB [2]
[1] https://zanzibar.tech [2] https://github.com/authzed/spicedb
permit(
principal == ?principal,
action == Action::"download",
resource in ?resource
) when {
context.mfa == true
};Using CEL for writing IAM policy: https://cloud.google.com/iam/docs/conditions-overview
What the machine needs is usually different from what you need. The machine solution sometimes comes first
Terraform is better but lots of shops are wary of relying on third party foundations.
I talked with the team building CDK... their market analysis was essentially: SysDEs love CFN or declarative. Developers hate repeating themselves and lack of abstractions. I generally agree with the latter. The lack of real modules, dependency management, compilers, etc are a put off for CFN and TFN for me. I'm loving CDK.
For instance we run a linter for security issues and best practices during the cdk build... We have tools applying changes across our abstractions and against our non-abstractions.
In a declarative form the changes don't make it back into the declarative form unless you're pullling cfn state back into say git, or harder reversing it back into TFN state.
It's possible of course that I don't know enough about CDK and these examples have CDK solutions.
Imperative and declarative are not hard requirements for this but they make the domain easier to reason about and they are a good fit to the CF model of configuration-as-data instead (vs CDK's configuration-as-imperative-code).
I did not expect from AWS to simply support OPA in this phase of problem/market fit for the complex system Auth. Still, not happy with yet another siloed solution which is proprietary to one cloud.
I’m a bit unclear on why they needed a new DSL to be able to do “automated reasoning” on policy effects though. It doesn’t seem semantically that different from the existing policy docs we all know and love.