Request: ContextProvider plugins

[ddneilson]

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.

Other

None

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

---

This is a 🚀 Feature Request

[eladb]

Duplicate #18

[eladb]

I have transferred this to the RFC repo, copied the contents and closed as duplicate. Let's continue the discussion over there.