grpc-cdh: Return detailed error in get_resource #1123
Conversation
The get_resource endpoint currently returns only the top-level error message (e.g., "Get Resource failed") while logging the full error chain with root causes. The detailed error is already computed using format_error!() but only used for logging. This changes the response to include the full chain, which would help with debugging without the need to see server logs. Signed-off-by: Beraldo Leal <bleal@redhat.com>
|
We should be careful about what we expose outside of the Tee via logging. |
CDH logging will be expose via containerd log to host side. We need to avoid exposing confidential information that some times get resource log carries to the untrusted host. Thus now we use a hard solution to just return a single log to client. |
I imagined something like this the moment I sent the PR, thanks for clarifying that. Today the client only gets the "Display" of the top-level error, which usually doesn’t say much (e.g. just "GetResource failed"), so it’s not very informative. I was wondering if a middle ground could be: returning both the top-level error and the deepest error in the chain, while keeping the full chain of causes, backtrace, and internal fields only in the logs. Wdyt? Would that be acceptable, or do you see any issue with that? |
|
I don't think we have to be concerned with specific confidentiality aspects here, it's just a question of good old API design. You want to give the user errors that are informative/useful/actionable to without leaking internals of a service which would be potentially harmful to the service owner. E.g. "400. Error: can't write /opt/kbs/policy/bla: no space of left on device" is not actionable for the user, and leaks insights about the folder structure of the service host. an opaque 500 error would be sufficient it that case. It would hopefully be picked up by a monitoring system, and fixed the by the operator. Or a "404: secret foo not found error" and a "403: unauthorized, not allowed to access secret bar" will give an unauthorized user hints about the presence of certain secret keys on the system, etc... Having very rich error messages might be convenient for us who glue those things together (because we don't have to look at service logs to see actual the error) but for a security-related API we probably want to err on the side of being overly cautious rather than unintentionally leaking info. |
|
Hi @beraldoleal I wonder if this PR can be closed - or if there are more considerations? |
4 participants
The get_resource endpoint currently returns only the top-level error message (e.g., "Get Resource failed") while logging the full error chain with root causes.
The detailed error is already computed using format_error!() but only used for logging. This changes the response to include the full chain, which would help with debugging without the need to see server logs.