Conversation
this add a threat model covering threat surface analysis, actor profiles, attack scenarios and more. Signed-off-by: Paul Arah <paularah.self@gmail.com>
✅ Deploy Preview for tetragon ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
mtardy
left a comment
mtardy
left a comment
There was a problem hiding this comment.
So I haven't reviewed the content yet but here a few points already:
- could we wrap the lines (use
gqin vim), we wrap for all the pages in the tetragon docs. - the figures after the first one are not rendering properly, see https://deploy-preview-4697--tetragon.netlify.app/docs/threat-model/.
- I was thinking maybe we could put this under an existing section but actually it might make sense to have this new one 🤔 because not sure it would fit elsewhere
Signed-off-by: Paul Arah <paularah.self@gmail.com>
Signed-off-by: Paul Arah <paularah.self@gmail.com>
Signed-off-by: Paul Arah <paularah.self@gmail.com>
|
@ferozsalam you might want to take a look at this. |
| ## Conclusion | ||
|
|
||
| While eBPF provides unparalleled visibility and enforcement capabilities, its security is still tied to the integrity of the adjacent environment it operates in, particularly the host operating system and the Kubernetes control plane. Implementing mitigation strategies that encompass the recommended controls in this threat model will ensure Tetragon continues to remain a trusted source of truth. The table below summarizes the attacker profiles, primary vectors, severity, and the primary mitigation. | ||
|
|
There was a problem hiding this comment.
I don't think the table below is how we should be summarising our recommendations. A lot of the suggestions above are specific to particular use cases, and the table below implies that reducing risk is a matter of implementing the primary mitigation. I think it makes more sense not to have the table - operators should read the entire set of recommendations and assess which potential controls are relevant/useful for them.
| - Prometheus metrics collection also benefits from encryption. Enabling TLS on the Prometheus metrics endpoint prevents casual interception of operational metrics, and configuring Prometheus scrapers to use authenticated TLS connections ensures both confidentiality and authenticity of the metrics channel. Users should weigh the operational overhead of managing TLS certificates for metrics collection against the risks associated with metrics disclosure in their specific threat model. | ||
|
|
||
|
|
||
| ## Operational Security Considerations |
There was a problem hiding this comment.
I'm not certain where the best place would be to add this, but a frequent report we receive to the OSS mailing list concerns TOCTOU issues due to hooking on syscalls. It would be good to link to the warning at the top of https://tetragon.io/docs/concepts/tracing-policy/hooks/, to highlight to users that there is a security/visibility risk in using the wrong hook points when writing policies, and that this does not indicate a security vulnerability in Tetragon itself.
3 participants
this add a threat model covering threat surface analysis, actor profiles, attack scenarios and more.