Log partial selectors from workload attestation on context cancellation #4846
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In the case when a client hangs up a connection to SPIRE Agent during workload attestation (e.g. timeout, process dies, etc.) while the agent is still discovering selectors from workload attestation plugins, it can be helpful to log whatever selectors the agent could find for debugging purposes. Today, only the pid is captured in logs in this case, which is often not enough information to trace back the caller since: - The caller process may have already died (e.g. crashlooping on startup) - pid alone is only useful if you can query the state of running processes on the host around the time of workload attestation (often not practical) Logging the partial set of selectors fetched by the agent before the caller hung up can help diagnose affected workloads in case a workload attestation plugin is misbehaving or a downstream dependency required by the plugin is down/not responding with accurate information. Signed-off-by: Ryan Turner <turner@uber.com>
rturner3
requested review from
evan2645,
amartinezfayo,
azdagron and
MarcosDY
as code owners
Signed-off-by: Ryan Turner <turner@uber.com>
amartinezfayo
approved these changes
Feb 8, 2024
sriyer
pushed a commit
to spire-vault/spire
that referenced
this pull request
Feb 23, 2024
…on (spiffe#4846) * Log partial selectors from workload attestation on context cancellation In the case when a client hangs up a connection to SPIRE Agent during workload attestation (e.g. timeout, process dies, etc.) while the agent is still discovering selectors from workload attestation plugins, it can be helpful to log whatever selectors the agent could find for debugging purposes. Today, only the pid is captured in logs in this case, which is often not enough information to trace back the caller since: - The caller process may have already died (e.g. crashlooping on startup) - pid alone is only useful if you can query the state of running processes on the host around the time of workload attestation (often not practical) Logging the partial set of selectors fetched by the agent before the caller hung up can help diagnose affected workloads in case a workload attestation plugin is misbehaving or a downstream dependency required by the plugin is down/not responding with accurate information. Signed-off-by: Ryan Turner <turner@uber.com>
rushi47
pushed a commit
to rushi47/spire
that referenced
this pull request
Apr 11, 2024
…on (spiffe#4846) * Log partial selectors from workload attestation on context cancellation In the case when a client hangs up a connection to SPIRE Agent during workload attestation (e.g. timeout, process dies, etc.) while the agent is still discovering selectors from workload attestation plugins, it can be helpful to log whatever selectors the agent could find for debugging purposes. Today, only the pid is captured in logs in this case, which is often not enough information to trace back the caller since: - The caller process may have already died (e.g. crashlooping on startup) - pid alone is only useful if you can query the state of running processes on the host around the time of workload attestation (often not practical) Logging the partial set of selectors fetched by the agent before the caller hung up can help diagnose affected workloads in case a workload attestation plugin is misbehaving or a downstream dependency required by the plugin is down/not responding with accurate information. Signed-off-by: Ryan Turner <turner@uber.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the case when a client hangs up a connection to SPIRE Agent during workload attestation (e.g. timeout, process dies, etc.) while the agent is still discovering selectors from workload attestation plugins, it can be helpful to log whatever selectors the agent could find for debugging purposes. Today, only the pid is captured in logs in this case, which is often not enough information to trace back the caller since:
Logging the partial set of selectors fetched by the agent before the caller hung up can help diagnose affected workloads in case a workload attestation plugin is misbehaving or a downstream dependency required by the plugin is down/not responding with accurate information.