We've deployed Cato's SDP client across our dev and staging environments (mostly Kubernetes pods, some legacy VMs). The goal was to get proper app-level visibility for our internal tooling.
The problem: Cato's Application Visibility is showing 'unknown' for about half of our internal services. These are standard HTTP/HTTPS and gRPC services. The traffic is flowing, but it's not being classified.
What we've checked:
* The SDP client is running and connected.
* Traffic is definitely routing through Cato (we see the flows under 'Network Connections').
* The apps showing as 'unknown' are not using exotic ports. Standard 80, 443, 50051.
Is this a known issue with internal service discovery? Do we need to manually map IPs/ports to applications, or is the SDP client supposed to handle this automatically?
Our current config for the pod client is basic:
```yaml
args: ["--hostname", "$(HOSTNAME)", "--account", "$(CATO_ACCOUNT)"]
env:
- name: CATO_ACCOUNT
valueFrom:
secretKeyRef:
name: cato-sdp-secret
key: account
```
Are we missing a flag or setting to enable deeper inspection for internal east-west traffic?
slow pipelines make me cranky
Internal service discovery often depends on the client seeing the initial connection handshake. For traffic that's already established before the client attaches, or connections pooled by a service mesh sidecar, classification can fail.
Your pod config is missing the application name mapping arguments. The client needs `--app-name` or similar labels passed from the pod spec to classify internal traffic correctly. Check the docs for the client's label propagation flags for Kubernetes.
Without that, it's just seeing raw TCP flows from pod IPs, which it will mark as unknown.
Beep boop. Show me the data.
That's a very common hurdle when moving from simple client-based routing to full application visibility. The SDP client sees the encrypted traffic flow, but without application context, it can't classify it.
You're likely missing the metadata the client needs to tag those internal connections. The basic args you have are for connectivity, not classification. For Kubernetes, you often need to pass pod labels or environment variables that identify the service. For VMs, a similar manual mapping might be required.
Check if there's a `--service-name` or `--app-label` argument in your client version. You might need to inject it from the pod's labels, like `--app-name $(MY_APP_LABEL)`. For those legacy VMs, you could set a host-based identifier. The client uses this metadata to enrich the flow logs before they're sent to the management console. Without it, everything internal just looks like generic TCP.
Architect first, buy later