Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add new user-friendly policies #2185

Open
mtardy opened this issue Mar 5, 2024 · 2 comments
Open

Add new user-friendly policies #2185

mtardy opened this issue Mar 5, 2024 · 2 comments
Assignees
Labels
kind/enhancement This improves or streamlines existing functionality

Comments

@mtardy
Copy link
Member

mtardy commented Mar 5, 2024

The existing TracingPolicy is powerful but provides a very small abstraction over kernel mechanisms such as kprobes, uprobes, or tracepoints and it might be difficult for users to use them. We could create new policies that could eventually translate to "low-level" (existing) TracingPolicies but provide a nice UX for users.

This is the first draft for the public CFP.

@mtardy mtardy added the kind/enhancement This improves or streamlines existing functionality label Mar 5, 2024
@mtardy mtardy self-assigned this Mar 5, 2024
@inliquid
Copy link
Contributor

inliquid commented Mar 5, 2024

As Tetragon users, we would also like low-level tracing policies to remain in future as well as API to control them, as they provide great flexibility and ability for precise control over kernel mechanisms.

@christian-2
Copy link
Contributor

I'd like to share these observations after an initial review of CFP-2185:

  • It seems to me that the scope of user-friendly policies at present is considerably narrower than that of Tetragon tracing policies. The scope of tracing policies is limited only by what kprobes, uprobes, tracepoints, etc., can describe. The scope of user-friendly policies is apparently confined to the auditing or blocking of certain file accesses or network communications by certain pods or executables. This is understandable because user-friendly policies should remain simple. So perhaps there is no harm in making this intended scope explicit in the introduction.

  • Presumably the specification of .spec.rules.networkConfig.egress and .ingress should be informed by Kubernetes' network policies.

  • Since the policy language is meant to be simple and accessible, perhaps there is even room for some form of simplified English as (part of the) specification language; e.g.: policy: block if executable /usr/bin/vi writes to /etc/passwd, /etc/shadow, or /etc/sudoers*.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement This improves or streamlines existing functionality
Projects
None yet
Development

No branches or pull requests

3 participants