#Since ` secret` is removed and with

1 messages · Page 1 of 1 (latest)

rich kelp
#

That's an option, though I'd also be okay with re-adding the CLI interface for now since it probably makes for a better demo? When we flesh out the bash SDK that will obviously Change Everything ™️ but this could hold us over in the meantime

@wanton cairn I think it should still work with the way things are implemented; you'd just need the secret provider to also accept a map of static secrets that can only be loaded when the engine starts, right? Or am I missing something. If it's a ton of effort then we can think more about whether it's worth it

void oak
#

in bash you could still provide the secret ID as an argument to the query, no?

wanton cairn
#

yea, I think you could export TOKEN=$token and then run host { variable(name: "TOKEN") { secret { id } } } to get a SecretID and pass it along

rich kelp
#

Ah right, I forgot we just added the host env part too, that's a good option

wanton cairn
#

(oh you already have $TOKEN set so no need for the extra export, I misread)

#

yeah, the challenge with the static secret map/store approach is we'd need to also introduce a way to construct a SecretID that fetches from it

#

it's doable, but it's a new API

agile tendon
#

I thought issue was that if I run via the engine via the cli I can generate a secretID, but when I call the engine via cli again, it won't know about that secretID and will error out. That's what used to happen.

wanton cairn
#

this is a whole new secrets implementation, so I wouldn't expect the same things to break. only new things 🙂

#

having said that, I haven't actually tried this, but it should work as long as the env var is set where the engine is running

agile tendon
#

I'll try now

agile tendon
#

oh, I see why, since the SecretID is an instruction to fetch the secret from the ENV:

echo eyJob3N0X2VudiI6IlRPS0VOIn0= | base64 -d
{"host_env":"TOKEN"}%