cilium
deprecate sensors gRPC interface
The sensors gRPC interface is outdated. We should deprecate it and use tracingpolicies instead. Before deprecating, however, we need to provide the functionality to disable a tracingpolicy as we, currently, do with sensors.
- [x] implement disable tracing policies gRPC call: https://github.com/cilium/tetragon/pull/1562
- [ ] deprecate sensors
In an offline discussion, @mtardy mentioned that:
disable [a policy] without modifying the resource does not sounds very "declarative"/"k8s" way. I think you can end up in a very confusing situation where you don't understand why you perfectly fine tracing policy does not apply. Having a field in the policy [that allows you to disable it] would make more sense indeed
@kkourt could you please clarify a little bit, does that mean that in order to "disable" policy I will have to delete one and then apply it with some additional field disabled set to true?
As a side note, I think when it comes to working with policies over gRPC instead of CRD, it's already some sort of not very "k8s way". But at the same it's the reason why we want to use it, as it's much more flexible.
@kkourt could you please clarify a little bit, does that mean that in order to "disable" policy I will have to delete one and then apply it with some additional field
disabledset totrue?
You would not have to delete the policy. We want to keep a distinction between removing and disabling. The idea would be that you will have a field in the policy to disable the policy's functionality and then you would just update the k8s resource (without deleting).
As a side note, I think when it comes to working with policies over gRPC instead of CRD, it's already some sort of not very "k8s way". But at the same it's the reason why we want to use it, as it's much more flexible.
Agreed. The problem is that mixing the two can get confusing and have unexpected results.
Does above make sense?
The idea would be that you will have a field in the policy to disable the policy's functionality and then you would just update the k8s resource (without deleting).
Thanks, the point here is that we are managing tetragon through gRPC, and there is no API method to update the policy, only AddTracingPolicy, DeleteTracingPolicy and ListTracingPolicies, so how do I disable a policy it in this case?
The idea would be that you will have a field in the policy to disable the policy's functionality and then you would just update the k8s resource (without deleting).
Thanks, the point here is that we are managing
tetragonthrough gRPC, and there is no API method to update the policy, onlyAddTracingPolicy,DeleteTracingPolicyandListTracingPolicies, so how do I disable a policy it in this case?
I think we would need to add a new gRPC method for that. I haven't thought it through, but I can see two options: (i) having an UpdateTracingPolicy method that you can use to disable a policy or (ii) have a DisableTracingPolicy method.
(ii) have a DisableTracingPolicy method
That's what I thought of initially.
(ii) have a DisableTracingPolicy method
That's what I thought of initially.
so I think a DisableTracingPolicy method is perfectly fine for non-k8s use-cases. But for folk deploying tracing policies via the k8s API server (as a custom resource), I think we are going to need a different approach (e.g, the field I mentioned above). so I think we would need to support both k8s and non-k8s use-cases.