DOCA Flow gRPC Server (docaflowgrpc)

DOCA Flow gRPC Server (doca_flow_grpc)

CRITICAL transport-security correction (Run-12 + R13). The shipped doca_flow_grpc / doca_flow_grpc_client binaries hard-code the gRPC plaintext credentials surface: the server uses grpc::InsecureServerCredentials() (the C++ gRPC server-side API in tools/flow_grpc_server/server/); the C++ client uses grpc::InsecureChannelCredentials() (the C++ gRPC client-side API; the client lives in libs/doca_flow/grpc/client/, compiled into the doca_flow library, NOT under tools/flow_grpc_client/); the Python client uses grpc.aio.insecure_channel(...). Do NOT cite the server-side string as grpc::InsecureChannelCredentials() — that is the client-side API name and a Grep-against-source verification will fail. There is no TLS, no mTLS, and no token-auth knob on the shipped control plane today. Any prose below (or in CAPABILITIES.md / TASKS.md) that frames "mTLS / token auth / TLS posture" as a configurable knob on this server is the bundle's previous aspirational framing and is wrong against the shipped source. Treat the server as plaintext-on-a-trusted-segment only: it MUST be bound on a control-plane-only network segment behind an external proxy, sidecar, or VPN that itself enforces TLS + identity. Any "TLS / mTLS / token- auth" discussion below is about the operator's external hardening layer, NOT a knob on this binary. Routing for an TLS / identity design discussion must stay on the selected external proxy, sidecar, or VPN; never route it to a shipped-today binary knob.

Where to start: This is a tool skill for standing up and operating doca_flow_grpc, the DOCA-shipped gRPC remote- control surface for doca-flow. Open TASKS.md and start at ## configure to decide whether a remote control plane is the right answer at all (vs talking to libdoca_flow.so directly), then ## run for the start → bind → one-client-smoke sequence, then ## test for the smoke-before-bulk loop that