Introduction

There is no simple "disable network logs for kubectl exec" switch in Kubernetes because several different logging layers may be involved. The important question is what you actually want to suppress: client-side verbose output, API server audit logs, proxy logs, or container shell history. In most clusters, the relevant place is the API server audit policy, because kubectl exec is an API request to the pods/exec subresource.

Understand What Gets Logged

When you run:

kubectl exec -it my-pod -- sh

several systems may record something:

• your shell history on the machine running kubectl
• Kubernetes audit logs on the API server
• reverse proxy or ingress logs in front of the API server
• application logs inside the container if the executed command writes output

That is why "network logs" is too broad unless you identify the exact layer first.

kubectl exec Is an Audit Event

From the Kubernetes control plane point of view, kubectl exec is generally a request against the pods/exec subresource. If you want to reduce or remove audit visibility for that operation, you do it through an audit policy, not through the kubectl command itself.

A simplified audit-policy example:

1apiVersion: audit.k8s.io/v1
2kind: Policy
3rules:
4  - level: Metadata
5    verbs: ["create"]
6    resources:
7      - group: ""
8        resources: ["pods/exec"]

This keeps metadata but avoids full request and response logging for exec events.

Be Careful Before Disabling It Completely

You can set the audit level to None for pods/exec, but that is a significant security decision.

For example:

1apiVersion: audit.k8s.io/v1
2kind: Policy
3rules:
4  - level: None
5    verbs: ["create"]
6    resources:
7      - group: ""
8        resources: ["pods/exec"]

This removes those events from audit logs entirely. That may reduce noise, but it also removes traceability for a sensitive administrative action. In many production clusters, the better choice is to downgrade the detail level rather than remove the event completely.

Often the Better Fix Is Scope Reduction

If the goal is not total removal but lower noise, use narrower rules:

• reduce pods/exec logging to metadata
• restrict by user or service account
• restrict by namespace for noisy non-production environments

That approach usually gives a better security balance than disabling the event cluster-wide.

Client-Side Logging Is Separate

Sometimes people say "network logs" when they really mean noisy kubectl debug output. That is a different issue. If kubectl itself is verbose because flags such as -v=8 are being used, remove those flags or lower the verbosity.

This is separate from audit logging. Changing local kubectl verbosity does not change what the cluster records.

RBAC Is Still Important

Even if you reduce logging, kubectl exec should still be limited through RBAC because it is a powerful capability. Logging policy is not a substitute for access control.

A good operational posture is:

• restrict who can exec into pods
• log exec events at a level appropriate for your environment
• document why any suppression rule exists

That keeps the tradeoff explicit instead of accidental.

Common Pitfalls

• Saying "disable network logs" without identifying which log source is actually the problem.
• Trying to solve audit logging by changing only kubectl client flags.
• Disabling pods/exec audit events entirely when metadata-only logging would have been enough.
• Forgetting that kubectl exec is a sensitive operation that often should remain auditable.
• Reducing logs without also reviewing RBAC and administrative access policy.

Summary

• 'kubectl exec logging is usually controlled at the Kubernetes audit-policy layer.'
• There is no single built-in toggle that disables every possible log source.
• The most relevant resource is usually the pods/exec subresource.
• In many cases, reducing audit detail is safer than disabling logging completely.
• Always pair any logging change with clear RBAC and operational review.