Verified Permissions L2 Constructs
reste85 opened this issue · comments
Description
Create L2 Constructs for Amazon Verified Permissions. Amazon Verified Permissions is a scalable permissions management and fine-grained authorization service for the applications that you build. Using Cedar, an expressive and analyzable open-source policy language, developers and admins can define policy-based access controls using roles and attributes for more granular, context-aware access control.
This proposal will cover only the constructs related to Amazon Verified Permissions, not Cedar (as i see in the issues list, this will be covered in a different RFC). All the properties / fields that will contain Cedar resources (schemas or policies) will be treated as simple strings.
Constructs will be created for:
- PolicyStore
- Policy
- PolicyTemplate
- IdentitySource
Main idea of implementation:
- Exposing proper Enum for PolicyStore property ValidationSettings.Mode
- Throwing error in case ValidationSettings.Mode is set to STRICT and PolicyStore schema is not defined
- A set of methods will be created on PolicyStore to grant read/write/authorization api access to a specific iam.IGrantable
- (To be verified) A set of methods will be created on PolicyStore to add directly to the store the following resources:
- Policies
- PolicyTemplates
- IdentitySource
Aiming to build L2 constructs with some convenience methods/properties
Roles
| Role | User |
|---|---|
| Proposed by | @reste85 |
| Author(s) | @reste85 |
| API Bar Raiser | @alias |
| Stakeholders | @alias, @alias, @alias |
See RFC Process for details
Workflow
- Tracking issue created (label:
status/proposed) - API bar raiser assigned (ping us at #aws-cdk-rfcs if needed)
- Kick off meeting
- RFC pull request submitted (label:
status/review) - Community reach out (via Slack and/or Twitter)
- API signed-off (label
api-approvedapplied to pull request) - Final comments period (label:
status/final-comments-period) - Approved and merged (label:
status/approved) - Execution plan submitted (label:
status/planning) - Plan approved and merged (label:
status/implementing) - Implementation complete (label:
status/done)
Author is responsible to progress the RFC according to this checklist, and
apply the relevant labels to this issue so that the RFC table in README gets
updated.
This is an important and useful thing to add to CDK. Related to #523 and somewhat less related to #521
Of interest is that there is now a JSON representation of CEDAR, which will make creating the policy significantly easier and less error prone that the text format.. https://github.com/cedar-policy/cedar-docs/blob/main/docs/json-format.md. However as yet, it is not possible to pass the Json object to the api/ cfn L1, as it only takes the string format. There is rust based code ( cedar is Rust centric ), that does the conversion, which could be the basis for creating some ts code.
In any case, a construct should be future proofed to accomodate for the the possiblity that either a string or json may be passed on, so that non breaking changes can be made.
Apart from this the problem for this construct are not particuarly complex compared to some constructs that are in CDK, provided the construct sticks to just AVP, and does'nt attempt to provide opionated L3 'solutions'.
This would be a good project for someone familar with CDK, but not having built a construct set themselves, and an ideal candidate to be community mentored to get it to 95% good stage, so that the effort required by the CDK team, can be minimized since they are overly committed and unable to take on much additional work.
I have an nearly immediate need for this, and so have already done quite a bit of work for my own construct and in this case, dont' have a need for it to be in the cdk-lib. I'd be happy to assist someone getting on with this.
Hi @mrpackethead, can you link the rust-based tool to convert policies from json to strings here?
This is an important and useful thing to add to CDK. Related to #523 and somewhat less related to #521
Of interest is that there is now a JSON representation of CEDAR, which will make creating the policy significantly easier and less error prone that the text format.. https://github.com/cedar-policy/cedar-docs/blob/main/docs/json-format.md. However as yet, it is not possible to pass the Json object to the api/ cfn L1, as it only takes the string format. There is rust based code ( cedar is Rust centric ), that does the conversion, which could be the basis for creating some ts code. In any case, a construct should be future proofed to accomodate for the the possiblity that either a string or json may be passed on, so that non breaking changes can be made.
Apart from this the problem for this construct are not particuarly complex compared to some constructs that are in CDK, provided the construct sticks to just AVP, and does'nt attempt to provide opionated L3 'solutions'.
This would be a good project for someone familar with CDK, but not having built a construct set themselves, and an ideal candidate to be community mentored to get it to 95% good stage, so that the effort required by the CDK team, can be minimized since they are overly committed and unable to take on much additional work.
I have an nearly immediate need for this, and so have already done quite a bit of work for my own construct and in this case, dont' have a need for it to be in the cdk-lib. I'd be happy to assist someone getting on with this.
Hello @mrpackethead, since the submission process is currently stopped i think we'll release it in ConstructHub first. Stay tuned, i'll let you know
Closing this ticket. We believe the functionality is beneficial, but does not intersect with the core framework and should be vended and maintained separately.
FYI:
We released the constructs in ConstructHub --> https://constructs.dev/packages/@cdklabs/cdk-verified-permissions/