Derive and pass workload secrets to initializer #788
Conversation
3u13r
force-pushed
the
feat/coordinator/pass-workload-secret-to-initializer
branch
2 times, most recently
from
e6340e7 to
d2fec5b
Compare
|
3u13r
force-pushed
the
feat/coordinator/pass-workload-secret-to-initializer
branch
3 times, most recently
from
4341506 to
68662a9
Compare
| // SeedEngine is the seed engine used to derive secrets. | ||
| SeedEngine *seedengine.SeedEngine |
There was a problem hiding this comment.
The SeedEngine's lifecycle is simpler than the State's - from the consumer point of view, it is either present or absent, and if it's present it does not change again. So instead of tacking the seedengine to the channel, we could pass the getter to meshapi directly.
There was a problem hiding this comment.
Sure but the meshapi (server) is created in the main.go and the seedengine is internal to the authority, since it's also initialized from there. So we need some form of channel either way, or is there something I'm missing?
There was a problem hiding this comment.
we could pass the getter to meshapi directly
The meshapi needs to be configured with a seedengine getter, but that does not need to be part of the channel state is what I'm trying to say.
There was a problem hiding this comment.
So, as stated above, I think I might be a bit more comfortable without the seedengine in the state, but also unsure whether it makes sense as a getter interface in the meshapi. If somebody else has more concrete opinions, shoot.
There was a problem hiding this comment.
I tried to implement your suggestion in fee113c. I'll take any opinions on which one is better.
| @@ -108,6 +108,7 @@ systemd | |||
| tardev | |||
| tarfs | |||
| Terraform | |||
| themself | |||
There was a problem hiding this comment.
| themself |
3u13r
force-pushed
the
feat/coordinator/pass-workload-secret-to-initializer
branch
2 times, most recently
from
043687c to
2b800a5
Compare
3u13r
force-pushed
the
feat/coordinator/pass-workload-secret-to-initializer
branch
3 times, most recently
from
f695e97 to
7ab7870
Compare
| // SeedEngine is the seed engine used to derive secrets. | ||
| SeedEngine *seedengine.SeedEngine |
There was a problem hiding this comment.
So, as stated above, I think I might be a bit more comfortable without the seedengine in the state, but also unsure whether it makes sense as a getter interface in the meshapi. If somebody else has more concrete opinions, shoot.
3u13r
force-pushed
the
feat/coordinator/pass-workload-secret-to-initializer
branch
from
383c8a8 to
fee113c
Compare
|
Note: I misclicked and re-requested Markus despite already having an approval. |
| @@ -108,6 +108,7 @@ systemd | |||
| tardev | |||
| tarfs | |||
| Terraform | |||
| themself | |||
DeriveWorkloadSecret takes a string an uses it as info parameter for a hkdf derivation using the seed
3u13r
force-pushed
the
feat/coordinator/pass-workload-secret-to-initializer
branch
from
fee113c to
fb55114
Compare
Previous work in the manifest: #785
Note: the openssl, service-mesh, and workload secret ci yaml seem repetitive.
Should we just combine the second to last the (the "just" step) with the last step (nix step) since we already have a just target for e2e tests? we'd only need to pass the undeploy flag.