[5/8] coordinator: support insecure manifests behind opt-in#2356
Conversation
4a00b00 to
657abac
Compare
552c173 to
27802b6
Compare
27802b6 to
7073c58
Compare
657abac to
41b8d92
Compare
7073c58 to
af50bbe
Compare
41b8d92 to
c596cca
Compare
72898ef to
f2897e6
Compare
af50bbe to
65b519a
Compare
f2897e6 to
91b1df7
Compare
65b519a to
891d7f0
Compare
91b1df7 to
db7cd22
Compare
6223484 to
acaa9fd
Compare
a8f6eb6 to
fd0d094
Compare
9eeeeba to
55e4947
Compare
bbf67f4 to
9da6471
Compare
21d6bec to
1cd7565
Compare
9da6471 to
aa5ba51
Compare
1cd7565 to
c26922a
Compare
4e3d618 to
c168265
Compare
c26922a to
708ea30
Compare
708ea30 to
b1dd9dc
Compare
c168265 to
28e1b1e
Compare
b1dd9dc to
746bc55
Compare
28e1b1e to
464e044
Compare
746bc55 to
9b0cc73
Compare
464e044 to
0762a6e
Compare
9b0cc73 to
50a85ba
Compare
0762a6e to
1cff241
Compare
50a85ba to
abb75b8
Compare
1cff241 to
62ac3e2
Compare
62ac3e2 to
9d6a048
Compare
abb75b8 to
2701421
Compare
charludo
left a comment
There was a problem hiding this comment.
Thanks! Sorry review took so long. I have a couple of comments, see below; the one architectural one I want to get your opinion on is if we should allow mixed manifests. Is that something you actually require? Because if not, then I'd strongly urge to allow either all-secure, or all-insecure manifests, no mix.
| if !g.allowInsecure && mnfst.AllowInsecure() { | ||
| return nil, ErrInsecureNotAllowed | ||
| } |
There was a problem hiding this comment.
Sorry if this has been decided already, I might just be OOTL and wanted to make sure: Do we also care about the reverse? I.e. is it acceptable to allow users to have a secure deployment run with an insecure coordinator?
| // | ||
| // If allowInsecure is true, the Guard will accept manifests that contain insecure platforms. | ||
| // Otherwise, setting such a manifest will be rejected with ErrInsecureNotAllowed. | ||
| func New(hist *history.History, reg *prometheus.Registry, log *slog.Logger, allowInsecure bool) *Guard { |
There was a problem hiding this comment.
Not super happy with just passing an unnamed bool into here. Invocations don't make it super obvious what a serious effect this has. How would you feel about instead leaving New as-is, without the option to allowInsecure, and instead add something like func (g *Guard) MakeInsecure() that needs to be explicitly called?
| default: | ||
| return nil, fmt.Errorf("unsupported platform: %T", cpuid.CPU) | ||
| log.Warn("No TEE platform detected, using insecure attestation issuer") | ||
| return insecure.NewIssuer(), nil | ||
| } |
There was a problem hiding this comment.
This should not default to insecure. Any chance to something similar here as with allowInsecureAttestation() in the initedata processor?
| logger.NewWithAttrs(logger.NewNamed(c.logger, "validator"), map[string]string{"reference-values": name}), &authInfo, name)) | ||
| } | ||
|
|
||
| if state.Manifest().AllowInsecure() { |
There was a problem hiding this comment.
IMO there need to be two variants of AllowInsecure. One to use here, that is only true when all platforms allow insecure in the manifest (just as an additional guard), and the other one in the current form for use in
if !g.allowInsecure && mnfst.AllowInsecure() {
return nil, ErrInsecureNotAllowed
}below, that is true when any platform allows insecure.
| _, allowInsecure := os.LookupEnv(allowInsecureEnvVar) | ||
| if allowInsecure { | ||
| logger.Warn("Coordinator is configured to allow insecure manifests") | ||
| } |
There was a problem hiding this comment.
Check value, not just presence. CONTRAST_ALLOW_INSECURE=0 should not enable insecure mode. I can easily see users deliberately "disabling" insecure mode like this. strconv.ParseBool should do the job.
Split from #2337 as part of a stacked review series.
Depends on: #2355
This PR wires insecure manifests into the Coordinator behind explicit opt-in: