add new import type that is only resolved during rotation #439
Conversation
imports can now either be a list, or an object representing multiple import types:
imports:
open:
- a # imports resolved during open
rotate:
- b # imports only resolved during rotate
when imports is a list, it represents "open" imports, preserving existing behavior.
This reverts commit 3c61343.
This reverts commit e5bd5d9.
This reverts commit c22ef1a.
nyobe
force-pushed
the
claire/new-import-type
branch
from
7753126 to
73169d2
Compare
nyobe
changed the title
nyobe
force-pushed
the
claire/new-import-type
branch
from
73169d2 to
a092b78
Compare
nyobe
force-pushed
the
claire/new-import-type
branch
from
a092b78 to
704a8a8
Compare
| @@ -482,6 +486,9 @@ func (e *evalContext) evaluateImport(myImports map[string]*value, decl *ast.Impo | |||
| return | |||
| } | |||
| val = imported.value | |||
| } else if rotateOnly && !e.rotating { | |||
| // this import should only be evaluated during rotation, and we're not rotating, so resolve it as unknown | |||
| val = &value{def: newMissingExpr("", nil), schema: schema.Always(), unknown: true} | |||
There was a problem hiding this comment.
I know we talked about adding a new type of missingExpr for this, but I haven't quite wrapped my head around how it would work.
I think we need to keep track of the imported environment name somewhere? I'd like for a rotation provider to be able to return an error saying it tried to use an unknown value / you may not have permission to access , but I'm not sure how to recover that information from esc.Value.
There was a problem hiding this comment.
Ah, I'd put that in the evaluator itself--if the unknown value is accessed when not rotating, the evaluator should error. This could be done via a patch to evaluateExprAccess to handle the distinguished expression type in its type switch.
There was a problem hiding this comment.
Hm, though I suppose that wouldn't work, since it's not clear whether or not the value is actually used by the provider. Ick.
There was a problem hiding this comment.
I almost wonder if we want rotators to have two input schemas? one that's user-facing and one that's internal? that would at least allow the evaluator to handle this instead of the rotator.
There was a problem hiding this comment.
yeah, the evaluator doesn't have the context to know if the value is used or not.
adding a second input schema can help give us this context, we could have one input schema that is validated during open and another that is validated during rotate.
this almost works, except that it seems like unknown values are not being treated as missing for required properties, so it's still validating successfully 😕 65c34a5
Design doc
Add an additional
rotateOnlymetadata for imports, (similar to merge.) Imports withrotateOnlyset to true will only be evaluated during rotation, not during open, and are otherwise treated as unknown.Additionally,
fn::rotatenow tolerates unknown inputs so thatopenwill succeed when using values from such imports.Combining these allows rotation credentials to be imported from a restricted environment, while enabling the rotated environment to be consumed by lower-privileged users.
Resolves https://github.com/pulumi/pulumi-service/issues/25240