Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open Context Providers #18

Closed
1 of 7 tasks
eladb opened this issue Dec 8, 2019 · 9 comments
Closed
1 of 7 tasks

Open Context Providers #18

eladb opened this issue Dec 8, 2019 · 9 comments
Assignees
Labels
framework status/stale The RFC did not get any significant enough progress or tracking and has become stale. tools Tools

Comments

@eladb
Copy link
Contributor

eladb commented Dec 8, 2019

PR Champion
#167 @rix0rrr

Description

e.g. constructs should be able to say they use a 3rd party vended context provider

Progress

  • Tracking Issue Created
  • RFC PR Created
  • Core Team Member Assigned
  • Initial Approval / Final Comment Period
  • Ready For Implementation
    • implementation issue 1
  • Resolved
@MrArnoldPalmer MrArnoldPalmer added the status/proposed Newly proposed RFC label Jan 4, 2020
@eladb
Copy link
Contributor Author

eladb commented May 26, 2020

Copied from #166
The CDK has a super-handy feature in the form of the ContextProvider ( https://docs.aws.amazon.com/cdk/latest/guide/context.html ). The CDK can use this to, say, use the AWS SDK to query information about a customer's Vpc setup (i.e. Vpc.fromLookup()).

Development within the CDK Construct library itself benefits greatly from this capability. When a new ContextProvider is needed, then a CDK contributor can just create it. Unfortunately, since the providers are hard-coded into the CDK, no 3rd party construct library can create their own ContextProvider; other than by contributing it to the CDK, of course. Some ContextProviders may be too specialized for reasonable consideration as a CDK contribution.

Instead 3rd party libraries are required to implement workarounds, like CfnCustomResources that resolve during deployment instead of during synthesis. This increases the size of the Cfn template generated by the app, increases the time required to deploy the stack, adds unnecessary extra resources to the user's account, and makes it possible for a value generated by the CfnCustomResource to differ from one deployment to the next.

Unfortunately, these CfnCustomResources required by 3rd party construct libraries may also be a security risk to the user. The lambda that backs them persists as long as the stack is deployed, and that lambda is granted permissions into the account that may be possible to leverage by an attacker that gains access to the lambda; depending on the lambda's purpose, of course.

Use Case

I'm developing a third party construct library, and am running into exactly this problem. I have a requirement that would best/most-securely be met by a ContextProvider, but need to implement it with a CfnCustomResource instead.

Proposed Solution

Not sure how this might be implemented; not familiar with these guts of the CDK. Should a plugin be attachable at run-time, or only on the command-line when invoked?

ex:

ContextProvider.register("ProviderKey", ObjectDerivedFromContextProviderPlugin)

or

cdk --register-provider my_provider ...

The former is nice in that it's pretty easy to use, but may be a security risk -- a construct could register whatever provider it likes to get whatever data it likes. The later is clunky, but at least requires the user to take an explicit action to enable the provider.

@ddneilson
Copy link

RFC created: #167

@mbonig
Copy link

mbonig commented Feb 7, 2022

I think the former of the two examples seems the nicest. I'm not sure I see the security risk of having constructs add their own providers, considering all the other things a construct could do that's just as malicious (like running arbitrary network code).

@mrpackethead
Copy link
Contributor

This topic has come to get me again. My use case is that i want to use a context provider to get an address allocation from IPAM. I need the allocation at synth time, so ec2.Vpc can calculate the subnets.

@gradybarrett
Copy link

A use case I've been mulling over for a while is pulling metadata from something like backstage.io and storing it in context. While we don't use backstage at my current company we do have internal metadata that can change, so being able to pull it in and ensure deterministic deploys would be great. Seemed like a nice match for a context provider.

@webratz
Copy link

webratz commented Sep 5, 2022

@gradybarrett We do have a similar use case where i would like to fetch some project metadata, but have it in the context to ensure it does not change unexpectedly.

@j5nb4l
Copy link

j5nb4l commented Oct 27, 2023

Any updates on this? I would like to be able to create context providers to import resource not currently supported by the existing ones. The primary motivation is to shift-left errors caused by referencing a resource that does not exist, instead of waiting until the stack operation to fail because I fat fingered the Arn of the execution role of a function. Thank you.

@ddneilson
Copy link

If anyone wants to take this over, then I won't stand in their way. I do not have the bandwidth for tackling this, and I've mostly moved on to other projects that do not involve the CDK.

@evgenyka
Copy link

Won't implement. This is not a feature that we believe is beneficial to the wider install base.

@mrgrain mrgrain added status/stale The RFC did not get any significant enough progress or tracking and has become stale. and removed status/proposed Newly proposed RFC labels Dec 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
framework status/stale The RFC did not get any significant enough progress or tracking and has become stale. tools Tools
Projects
None yet
Development

No branches or pull requests