Verified Access L2 Constructs

[mrpackethead]

Description

• Create a construct for Verified Access. With AWS Verified Access, you can provide secure access to your applications without requiring the use of a virtual private network (VPN). Verified Access evaluates each application request and helps ensure that users can access each application only when they meet the specified security requirements.

Verified Access is well suited for IAC, as to build it manually is a complex and error-prone process.

Verified Access uses Cedar policy. Today Verified Permissions and Verfied Access are the AWS services that use Cedar, and it appears that it may get wider traction for other services, as it has been opensourced and other vendors are using it as well.

For clarity, this proposal covers a construct for Verified Access, and not Cedar [this will be covered in a separate RFC. Intially This construct, will take a cedar policy document ( it is a string ). It is anticipated that the Cedar construct could be 'similar' to the IAM module, bearing in mind that there is not a 'cedar' service, and related API's for it.

It is anticipated that constructs would be created for;

TrustProvider
AccessInstance
AccessGroups
AccessEndpoints

A set of statics would be created for Logging, which are attached to AccessInstance(s).
Methods would be created on the AccessGroups to share them across accounts, and to add policy.
Methods would be created on the AccessEndpoints to add policy.
Methods woudl be created on the AccessINstance to provide WAF integration.

The constructs should follow the general intention of being Level2, without being overly opinonated, or attempting to provide complex integrations which create the associated services/loadbalancers/vpcs etc. Those opinonated constructs are valuable, but would be published to constructs.dev.

Roles

Role	User
Proposed by	@taylaand
Author(s)	@mrpackethead,
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-approved applied 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.

[mrpackethead]

FYI, Code is written.

https://cloud-networking-as-code.com/2023/07/20/aws-verified-access-alpha-vpn-less-application-access-with-cdk/

[awsmjs]

Closing this ticket. We believe the functionality is beneficial, but does not intersect with the core framework and should be vended and maintained separately.