This approach doesn't seem to follow our practices of handling different environments. E.g. when handling webapp_url in keyserver instead of having an env variable staging or prod, we allow flexible configuration on any platform using a dedicated env variable.

fair enough. i've added a dedicated env var in the latest revision and now we actually enumerate the allowed origins in the previous diff in the stack (in terraform)

Another issue: what should be the value of REMOTE_ENVIRONMENT when running the Identity service locally?

.ok() converts any error to None. i.e., when running locally, REMOTE_ENVIRONMENT doesn't need to be provided.

It seems like we should have an env variable dedicated to just the allowed origins for CORS and set it differently for different environments. (E.g. COMM_SERVICES_IDENTITY_ALLOWED_ORIGINS). What do you think?

I'm good with this. didn't prefix with COMM_SERVICES_IDENTITY, though, since we don't do this for the other env vars

added 10 in the previous diff in stack

your point about catching invalid config in from_cli makes sense. i think we should just call slice_to_allow_origin directly from from_cli, then. this will let us catch issues with HeaderValue::from_str, too.

this rearrangement is intentional. we should be separating imports into 3 groups: std, external, and local

server_setup is more closely associated with path_buf than with keyserver_public_key so moved the blank lines around a little