#Erik Sipsma3294 Ugh That actually makes

1 messages · Page 1 of 1 (latest)

lone pollen
#

Ah yeah, it's the same issue as when I tried to make FSID be a hash... I guess in this case it might just mean we need the ability to mark something as no-cache

#

Good catch though

cold berry
#

I think there's something "fundamental" with secrets though

We basically have a system that works on the basis that everything is cached, written to caching layers

And then we have secrets that fundamentally work by NEVER hitting a caching layer, being ephemeral / in-memory, etc

The two are polar opposites

#

I'm still thinking there ought to be a first class "secret provider" support that provides entirely different guarantees than regular extensions:

  1. promise we never cache, never end up in persistent storage
  2. JIT resolving (needed for rotation, etc) // this is less important but it's something vault etc will assume
lone pollen
#

Oh I completely agree that we need secret providers, my only attachment to addSecret was that it is possible today whereas secret providers need more design and time. Use of no-cache when an extension needs to call addSecret would just be a stopgap.

However, given that it's not exactly clear how to support no-cache today, it could just be worth jumping right to secret providers

lilac wagon
#

I have some philosophical questions around this

  1. Should any extension be able to add secrets? Or should they be given some sort of privileged permission (or scope) to do so?
  2. Should any extension be able to read all secrets? Or should the be given access to (or request access to) specific secrets