# Mesh Desk

> Audit Istio service-mesh configuration before applying it: how requests are routed, and whether mutual TLS actually protects the workloads. The free check runs in the browser and uploads nothing: it parses every pasted VirtualService, DestinationRule, Gateway, ServiceEntry, PeerAuthentication, AuthorizationPolicy and RequestAuthentication (plus the Kubernetes Services and Deployments behind a host) with line numbers, resolves short host names the way Istio does, and runs 35 deterministic routing and mTLS checks. The paid traffic audit confirms or dismisses every flag, gives a YAML fix per finding and describes what each host's requests get today; the paid mTLS check answers the posture of every scope, fixes each finding and writes a rollout to STRICT. The page checks every quote, line, posture mode and fix against the paste, and re-runs its own checks with each whole-resource fix applied.

App: https://mesh-desk.skillsafe.ai/
API tutorial: https://mesh-desk.skillsafe.ai/api.html

## Input

- Istio YAML pasted into one box: several documents separated by `---`, a `kind: List`, or kubectl `-o json` output. Dropped files are joined into one paste, each introduced by a `# file: name` comment.
- Nothing talks to a cluster or istiod: every flag is a reading of the text, with the resource and line it points at.
- Short host names are resolved against the namespace of the rule that names them (reviews in bookinfo is reviews.bookinfo.svc.cluster.local). A resource without metadata.namespace is read as default and marked "(not set)".
- Cross-resource checks see only what is pasted: paste the DestinationRule with the VirtualService to check subsets, the Service and Deployment to match subset labels against real pods, and the root-namespace (istio-system) PeerAuthentication to read the mesh default instead of assuming PERMISSIVE.

## Flags the free check raises

Traffic lane:

- TR-01 (high; medium when no DestinationRule for the host is pasted): route or mirror to a subset no DestinationRule defines - 503 NR.
- TR-02 (medium): weights in one route that do not total 100.
- TR-03 (high; medium for a duplicate match): a catch-all route above other routes, so they never run.
- TR-04 (medium): retries that do not fit the route timeout.
- TR-05 (medium): more than 5 retry attempts.
- TR-06 (low): http routes with no timeout.
- TR-07 (low; medium when routes to the host retry): DestinationRule without outlierDetection.
- TR-08 (medium for maxEjectionPercent 100; low for pool limits of 1): self-defeating circuit-breaker settings.
- TR-09 (medium): traffic mirroring left on.
- TR-10 (high when the route matches every request; medium otherwise): fault injection left on.
- TR-11 (medium): more than one DestinationRule for one host.
- TR-12 (medium): more than one mesh VirtualService for one host.
- TR-13 (high): a short host name the VirtualService and the DestinationRule resolve in different namespaces.
- TR-14 (high): subset labels that select none of the pasted pods behind the Service.
- TR-15 (low): a subset no pasted route sends traffic to.
- TR-16 (medium; info when the Gateway is not pasted): VirtualService host not served by its Gateway.
- TR-17 (high): Gateway server terminating TLS without a credentialName.
- TR-18 (medium): Gateway server accepting any host ("*").
- TR-19 (low): plain-HTTP server beside HTTPS for the same hosts without httpsRedirect.
- TR-20 (info): networking.istio.io/v1alpha3 in use.
- TR-21 (low): gateway-bound VirtualService for an in-mesh host without `mesh`.
- TR-22 (info): EnvoyFilter present, not checked.

mTLS lane:

- MT-01 (high): PeerAuthentication mode DISABLE.
- MT-02 (medium): PeerAuthentication mode PERMISSIVE.
- MT-03 (info): no PeerAuthentication pasted - Istio's default is PERMISSIVE.
- MT-04 (high for DISABLE, medium for PERMISSIVE): a port-level mode weaker than its policy.
- MT-05 (high): portLevelMtls on a policy without a workload selector.
- MT-06 (high toward a STRICT server; medium otherwise): DestinationRule tls.mode DISABLE for an in-mesh host.
- MT-07 (medium): DestinationRule tls.mode SIMPLE or MUTUAL for an in-mesh host instead of ISTIO_MUTUAL.
- MT-08 (high): tls.mode MUTUAL without a client certificate.
- MT-09 (high): insecureSkipVerify: true.
- MT-10 (high for DENY, medium for ALLOW): AuthorizationPolicy on principals or namespaces while the workloads accept plaintext - a plaintext request has no identity, so a DENY never matches it.
- MT-11 (high for `rules: [{}]`, info for no rules): allow-all and deny-all ALLOW policies.
- MT-12 (medium): Gateway minProtocolVersion below TLS 1.2.
- MT-13 (medium): RequestAuthentication with no AuthorizationPolicy requiring a request principal - requests without a token still pass.

The mTLS posture: one row per PeerAuthentication (mesh, namespace or workload scope, with port-level modes) and one effective row per namespace in the paste (workload over namespace over mesh over Istio's PERMISSIVE default).

## Paid lanes

- `traffic`: verdict unsafe | needs_work | ready; findings with catalogue id, the page flags confirmed, resource, line, severity (high | medium | low), title, verbatim evidence, why, and a YAML fix; one answer (confirmed | dismissed with a reason) per page flag; one plain-words description per VirtualService host of what its requests get today; an ordered plan.
- `mtls`: verdict exposed | permissive | strict; one posture row per scope the page computed (same mode, or a comment saying why not); findings and flag answers as above; an ordered rollout to STRICT (or, when strict, what to monitor).
- Handoff: a traffic audit offers "Check mTLS for these hosts", which runs the mTLS lane on the same paste with the traffic reply's verdict, hosts and findings in a `traffic_handoff` field.

## What the page checks in each reply

- Every finding names a pasted resource and a line inside it; its evidence is really in the paste (whitespace-insensitive); its id belongs to the lane; its fix parses as YAML, has no tabs and embeds no private key.
- A fix that is a whole resource (or several) is put back into the paste - replacing the resource of the same kind and name, or added when the paste lacks it - and the free check runs again: the fix must clear the flag it answers and introduce no new high flag.
- Every high, medium and low flag is answered exactly once, consistently with the findings; the verdict fits the severities.
- Traffic: every VirtualService host is described in routes, and nothing else. mTLS: every posture scope is answered with the mode the page computed; strict is refused while any namespace is effectively PERMISSIVE; a traffic handoff's hosts are covered by a posture row or a finding.

## Sources

- istio-traffic-management, wshobson/agents (github.com/wshobson/agents, plugins/cloud-infrastructure/skills/istio-traffic-management), MIT - https://skillsafe.ai/skill/@wshobson/istio-traffic-management
- mtls-configuration, wshobson/agents (plugins/cloud-infrastructure/skills/mtls-configuration), MIT - https://skillsafe.ai/skill/@wshobson/mtls-configuration
- Istio documentation (istio.io/latest/docs/reference/config/networking and /security) for the routing order, subset, timeout and retry defaults, PeerAuthentication precedence and AuthorizationPolicy semantics the checks rely on.

Model: gpt-terra, metered per run; the free check needs no account.