OpenShift Web Console中终端Pod访问的控制与权限问题

Alright, let's break down your questions about OpenShift Web Console terminal access to Pods—this is a common setup folks ask about when securing their clusters.

At its core, RBAC (Role-Based Access Control) is the primary mechanism that controls whether you can open a terminal to a Pod via the Web Console. The OpenShift Web Console doesn't have its own separate access rules here—it simply acts as a frontend for the Kubernetes API. When you click "Terminal" on a Pod in the console, it's making a request to the Kubernetes pods/exec API endpoint under the hood.

Beyond RBAC, there are a few secondary factors that can affect terminal functionality (but not whether you can initiate the connection):

• Pod Security Context settings: Things like readOnlyRootFilesystem or runAsNonRoot might limit what you can do once inside the terminal, but they don't block you from opening the terminal itself.
• Network policies: If network policies block traffic between the Web Console's backend (or your browser) and the Pod's network, the terminal connection might fail after initiation—but this isn't an access control mechanism for the terminal feature itself.

Any valid identity in the OpenShift cluster can request terminal access, provided they have the right permissions. This includes:

• Human users: Individual accounts set up in the cluster (e.g., via LDAP, OAuth, or local accounts)
• Service accounts: Machine identities used by applications or automation
• Groups: Collections of users or service accounts

Required Permissions #

To open a terminal to a Pod, a subject needs two key permissions:

1. Ability to list and retrieve Pod details: This lets the Web Console find the Pod you want to access, which requires the get and list verbs on the pods resource (in the core API group).
2. Ability to create an exec session: This is the critical permission that allows initiating the terminal connection, requiring the create verb on the pods/exec subresource.

Example Custom Role & Binding #

If you need to grant this access to a specific user or group without giving them full edit privileges, you can create a custom Role and RoleBinding:

Custom Role (namespace-scoped)

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-terminal-access
  namespace: your-namespace
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]
- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["create"]

RoleBinding to a User

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: grant-pod-terminal-access
  namespace: your-namespace
subjects:
- kind: User
  name: john-dev
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-terminal-access
  apiGroup: rbac.authorization.k8s.io

Built-in Roles to Consider #

OpenShift has some built-in roles that include these permissions:

• edit role: Grants full edit access to most resources in a namespace, including pods/exec access.
• admin role: Cluster-wide or namespace-wide admin access, which obviously includes terminal access.
• cluster-admin role: Full cluster access, including all Pod terminal capabilities.

Note that the default view role does not include pods/exec permissions—so users with only view access can see Pods but can't open terminals to them.

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