如何禁用Kubernetes Pod的交互式会话（kubectl exec/SSH访问）

Got it, let's walk through how to disable interactive access to your Kubernetes Pods—covering both kubectl exec sessions and SSH logins. These steps will help you harden your cluster against unauthorized interactive access:

There are two key ways to lock down kubectl exec: via RBAC (to block the API call entirely) and via Pod configuration (to prevent interactive sessions even if exec permissions exist).

Using RBAC to Deny Exec Permissions #

This method directly blocks the Kubernetes API endpoint used by kubectl exec. Create a ClusterRole that denies the pods/exec action, then bind it to the users/groups you want to restrict:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: deny-pod-exec
rules:
- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["deny"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: deny-pod-exec-all-authenticated
subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: deny-pod-exec
  apiGroup: rbac.authorization.k8s.io

• If you only want to restrict access in a specific namespace, replace the ClusterRole with a Role and ClusterRoleBinding with a RoleBinding, adding a namespace field to the binding.
• Test this with kubectl auth can-i create pods/exec to confirm the permission is denied.

Disabling Interactive Sessions via Pod Spec #

Even if someone has exec permissions, you can prevent interactive -it sessions by disabling stdin and TTY in your Pod definition:

apiVersion: v1
kind: Pod
metadata:
  name: non-interactive-pod
spec:
  containers:
  - name: my-app
    image: my-app-image
    stdin: false  # Disable standard input
    tty: false    # Disable terminal allocation

Running kubectl exec -it non-interactive-pod -- bash will fail here, since the container isn't configured to accept interactive input.

SSH access to Pods is generally an anti-pattern in Kubernetes, but here's how to eliminate it entirely:

• Don't install SSH servers in your container images: This is the most critical step. When building your images, avoid including packages like openssh-server—there's almost never a need for SSH when you can use kubectl exec (which you're already locking down).
• Block SSH port traffic with NetworkPolicies: If you can't avoid images with SSH servers, create a NetworkPolicy to deny all inbound traffic to port 22:

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: block-ssh
    namespace: your-namespace
  spec:
    podSelector: {}  # Matches all pods in the namespace; use labelSelector for specific pods
    policyTypes:
    - Ingress
    ingress:
    - ports:
      - port: 22
      action: Deny
  

• Restrict container privileges: Use Pod security contexts to prevent root access (which is required to start most SSH servers):

  spec:
    securityContext:
      runAsNonRoot: true
      runAsUser: 1000
    containers:
    - name: my-app
      image: my-app-image
      securityContext:
        capabilities:
          drop: ["ALL"]
  

• Audit permissions regularly: Use kubectl auth can-i commands or cluster auditing tools to monitor who has pods/exec access.
• Follow least privilege: Only grant pods/exec permissions to users or service accounts that absolutely need it—avoid broad, cluster-wide access.
• Scan images for SSH servers: Use container image scanning tools to detect unexpected SSH server packages in your images before they're deployed.

内容的提问来源于stack exchange，提问作者Souvik Dey