Replies: 1 comment 2 replies
-
Your proposal looks good to me in general :). Like you've identified in your 'questions' section, I'm also concerned about whether it should be possible to reference 'infrastructure resource' outputs in runtime code. There is a draw to this - for example, being able to reference a dynamically generated API gateway URL or passing data between the boundary of a build system via command line parameter to notation to modify the lambda's runtime behaviour without changing the code (such as passing the 'deployment environment name' letting the lambda know it's part of a test environment.) Like you said though, this sort of thing requires a lot of care security wise (particularly around secrets like API keys, etc.) Where runtime code is concerned, if we're exposing resource outputs at runtime then these secrets would inevitably be 'static' data in the code itself (injected at notation compile time) which would make it visible to an adversary in the AWS lambda console when viewing or downloading code. Such data should be encrypted at rest and only accessible to people and lambda executions with sufficient AWS permissions. It's a bit safer to pass such data at 'infrastructure compile time' via lambda environment variables if they're configured to be encrypted (and safer still to use Secrets Manager or KMS like you mentioned.) I think I'm therefore comfortable with 2 options: 'Environment' configuration param in
|
Beta Was this translation helpful? Give feedback.
-
context
lambda modules compile to two targets – an infrastructure definition and the actual runtime module.
to achieve this the compiler needs to create two modules – one that can be evaluated during the creation of the orchestration graph, and another that is only ever evaluated at runtime.
challenges
currently, the compiler just looks for the config export, and statically parses its values. to be able to infer more about the desired infrastructure, more capabilities are required. this has been discussed in #2.
this RFC explores the idea of using macros to create safe code paths that are capable of building more capable features.
approach
generally, a macro is a function that can be evaluated at compile time, modifying the resulting compiled code.
as lambda modules have two compile paths, the lambda macros will also define two implementations – one implementation that modifies the compiled infrastructure module, and another that modifies the compiled runtime module.
spec
@notation/**.runtime
&$
prefix.fn
filesquestions
part of what will makes lambda macros useful, is being able to reference other infrastructure resources within them (and have access to their outputs).
this raises the question of whether those imported infrastructure resources should be referenced by runtime code that is also has the import in scope.
possible approaches:
what would it mean to have infra resources available at runtime?
proposal
example usage
runtime output
infra output
macro runtime
macro plugin
Beta Was this translation helpful? Give feedback.
All reactions