investigate validity of all table fields in docs/packages.md

It was noticed during the 1.46 release cycle that a few fields in the tables of docs/packages.md had to be updated to accommodate recent package updates. Several engineers concurred, during discussions in this release cycle, that some values may not have been appropriately updated in past release cycles and therefor may be invalid.

changed milestone to %1.48.0

added kinddocs label

set weight to 1

added 1 deleted label

removed milestone %1.48.0

marked this issue as related to #1349 (closed)

added priority6 teamXForce labels

removed 1 deleted label

set weight to 2

changed iteration to Big Bang Iterations Dec 13, 2022 - Dec 26, 2022

changed milestone to %1.50.0

added 1 deleted label

removed 1 deleted label

added 1 deleted label

removed 1 deleted label

added 1 deleted label

removed 1 deleted label

added 1 deleted label

removed 1 deleted label

added 1 deleted label

removed 1 deleted label

added 1 deleted label

removed 1 deleted label

changed iteration to Big Bang Iterations Dec 27, 2022 - Jan 9, 2023

changed milestone to %1.51.0

set weight to 3

assigned to @snekcode

added statusdoing label

@micah.nagel @ryan.j.garcia Are you able to provide better definitions of done for the columns?

Network Policies and mTLS are easy to identify if they are a yes or no. For Logging, Telemetry, Tracing and Behavior Detection these descriptions seem generic. Any insight on how these can be better defined and tested is most welcome!

• Logging - fluentbit configurations for standardized logging
• Telemetry - Integration with Prometheus and dedicated Grafana dashboards as appropriate
• Tracing - Insertion of Tracing data for application traffic
• Behavior Detection - Twistlock Policies for applications

• Logging: Not sure on this one, @ryan.j.garcia have any ideas? I don't know what an app specific fluentbit config actually means in this context, or if the idea was just "fluentbit is scraping this apps logs".
• Telemetry: I think this definition almost good as is. We could rewrite to be something more like "Automatic metrics scraping with Prometheus and dedicated Grafana Dashboards/PrometheusRule alerts as appropriate", or some other way to include prometheus alerts.
• Tracing: Application sends traces for traffic to centralized tracing location (Jaeger/Tempo). This should be true for almost everything that is istio injected, provided it has a networkpolicy in place. Not sure if this one holds value as a standalone category
• Behavior Detection: Might want to redefine or change this to (1) include twistlock and neuvector (or generically "runtime security") and (2) focus more directly on what feature(s) we are looking for here (WAF, malicious process detection, etc)

Any thoughts here @michaelmcleroy ?

For Tracing, you inherit this with Istio injection. Might be better to just call this Service Mesh? I don't think any of the non-injected applications can claim tracing/service mesh.

Behavior detection - I'm guessing this has to do with Twistlock's behavior learning ability, which isn't specific to an app. We wouldn't need a column for that. WAF on the other hand would make sense. But, we don't even have an epic to implement that yet. I'd be in favor of nuking that column for now.

The behavior column could have been Tom's idea of adding pre-defined behavior models to Twistlock. But, the models are specific to configuration and image tag. So, I'm not sure that is maintainable for us.

Didn't see emails for these notifications. I believe Logging is essentially yes flb/promtail is scraping application logs and they show up in the in-cluster logging engine.

Tracing I believe should be it's own category, or maybe under another ubmrella of fully integrated into the mesh. It may warrant it's own column because in order for an injected app to send it's traces to jaeger/tempo an explicity egress NetworkPolicy is required from injected-pod > tempo/jaeger.svc:9411 so we'll have to be sure that's checked off.

Removing the Behavior Column.

@micah.nagel @michaelmcleroy I agree with @ryan.j.garcia I don't think tracing and mTLS is mutually exclusive as you can have mTLS checked with no network policy for tracing.

For Logging are the only two apps FluentBit and Promtail?

For Tracing are the only two apps tempo and jaeger?

Asking here for #1349 (closed).

Agreed on the distinction of tracing/mTLS - tracing requires istio injection + network policy for traces. mTLS (PERMISSIVE) requires istio injection and nothing more, but mTLS (STRICT) requires more. Tracing is a weird column that overlaps with both networkpolicies and mTLS.

Logging - yes, only fluentbit/promtail do log tailing/scraping.

Tracing - yes, only tempo/jaeger collect traces (soon to be only tempo in 2.0).

removed iteration Big Bang Iterations Dec 27, 2022 - Jan 9, 2023

changed iteration to Big Bang Iterations Jan 10, 2023 - Jan 23, 2023

changed milestone to %1.52.0

created branch 1348-investigate-validity-of-all-table-fields-in-docs-packages-md to address this issue

mentioned in merge request !2429 (merged)

added statusreview label and removed statusdoing label

removed iteration Big Bang Iterations Jan 10, 2023 - Jan 23, 2023

changed iteration to Big Bang Iterations Jan 24, 2023 - Feb 6, 2023

changed milestone to %1.53.0

set weight to 1

closed with merge request !2429 (merged)

mentioned in commit 43855c55

mentioned in commit a11ef8f3