Kubernetes Cluster Component Security practice questions

Configure an RBAC ClusterRoleBinding for system:anonymous.

Why it fails: RBAC does not control the kubelet read-only port, which bypasses normal API authorization.

Enable PodSecurityStandards in enforcing mode.

Why it fails: Pod Security Standards govern pod specs, not node-level daemon configurations.

Apply a NetworkPolicy blocking ingress traffic to port 1055.

Why it fails: NetworkPolicies do not protect host network ports on the node where kubelet runs.

anonymousAuth: "Disabled"

Why it fails: This is not a valid field name in the kubelet configuration specification.

enableAnonymousAccess: false

Why it fails: This is an incorrect syntax for kubelet configuration files.

readOnlyPort: 0

Why it fails: While disabling the read-only port is important, it does not explicitly control anonymous auth on the main secure port.

The etcd consensus module.

Why it fails: Etcd is purely a data store and does not execute certificate approval logic.

The kube-scheduler placement policy engine.

Why it fails: The scheduler assigns pods to nodes; it does not process cryptographic certificates.

The API server admission webhook chain.

Why it fails: While admission webhooks can inspect CSRs, the primary controller loop responsible for auto-approving bootstrapping is in the controller manager.

Configure the API server with --disable-service-accounts=true.

Why it fails: This flag does not exist and would break core cluster controller communications.

Set kubelet flag --encrypt-tokens=true.

Why it fails: This is not a valid kubelet flag.

Enable etcd encryption for service account tokens.

Why it fails: While encryption at rest is good, it does not prevent tokens from being mounted inside compromised pod containers.

protectKernelDefaults: false

Why it fails: ProtectKernelDefaults validates kernel settings, not kubelet API authorization.

tlsCertFile: /etc/certs/kubelet.crt

Why it fails: TLS configuration manages encryption in transit, not authorization decisions.

authentication.anonymous.enabled: true

Why it fails: This enables anonymous access, which increases risk.

ServiceAccount

Why it fails: A ServiceAccount provides an identity for processes running in pods; it holds no permissions itself and only gains them when bound to a Role or ClusterRole. It is tempting because it is namespace-scoped and cluster-visible, but the object granting cluster-wide permissions is ClusterRole.

Role

Why it fails: A Role grants permissions only within a single namespace, so it cannot authorise actions cluster-wide. It is tempting because it is the standard RBAC building block for namespaced access, paired with a RoleBinding. Cluster-wide permissions require a ClusterRole instead.

PodSecurityPolicy

Why it fails: PodSecurityPolicy is a deprecated admission controller defining pod security constraints, not an RBAC grant, and it carries no rules or bindings. It is tempting because it is cluster-scoped, but cluster-wide permission granting is performed by ClusterRole, typically bound via ClusterRoleBinding.

--disable-deprecated-apis

Why it fails: While specific versions can be disabled via runtime-config, this specific flag name does not exist.

--warn-deprecated-apis=true

Why it fails: This is not a valid API server flag.

--log-deprecated=true

Why it fails: Deprecation logging is managed through runtime configuration and standard audit rules.

--extension-ca-file

Why it fails: This is an incorrect flag name.

--etcd-ca-file

Why it fails: This is used for etcd connections, not extension API servers.

--proxy-client-cert-file

Why it fails: This specifies the client certificate the API server uses when proxying, not the CA for verification.

The etcd transaction validator.

Why it fails: Etcd relies on the API server to validate resource schemas.

The core scheduler admission plugin.

Why it fails: The scheduler does not perform API schema admission checks.

The kube-proxy filter admission module.

Why it fails: Kube-proxy does not run admission control.

Setting kubelet readOnlyPort to 8080.

Why it fails: This opens an insecure port on worker nodes, worsening security.

Enabling anonymous access.

Why it fails: Anonymous access increases exposure.

Disabling the Node authorizer.

Why it fails: Disabling the Node authorizer removes restrictions on kubelet API access.

kube-proxy

Why it fails: Kube-proxy manages network rules.

kube-scheduler

Why it fails: Scheduler runs on control plane.

Set kubelet flag --max-pod-payload.

Why it fails: This flag does not exist.

Configure kube-proxy with --max-buffer-size.

Why it fails: Kube-proxy does not handle API request body sizes.

Configure etcd with --max-request-bytes flag.

Why it fails: Etcd has request size limits, but the API server is the primary enforcement point for incoming client requests.

Automatically disables kubelet anonymous authentication.

Why it fails: Kubelet authentication is configured separately.

Accelerates network packet routing across Kubernetes Services.

Why it fails: Encryption at rest does not affect network routing performance.

Replaces the need for RBAC authorization policies.

Why it fails: RBAC is still required for API access control.

--auto-tls=true for all endpoints.

Why it fails: --auto-tls=true generates self-signed certificates automatically, which encrypts traffic but does not enforce mutual TLS: peers are not verified against a trusted CA, so any client can connect. It suits throwaway test clusters where certificate management is unwanted, not production control planes requiring authenticated peer and client identities.

--insecure-transport=false combined with HTTP proxy routing.

Why it fails: --insecure-transport=false merely disables etcd's plaintext listener; it does not itself provision certificates or demand client certificate verification. Routing through an HTTP proxy adds no cryptographic peer authentication. This flag belongs in setups where TLS termination happens elsewhere, not where etcd must enforce mTLS directly.

--cipher-suites=TLS_RSA_WITH_AES_128_CBC_SHA

Why it fails: --cipher-suites selects which TLS cipher algorithms etcd negotiates; it does not enable TLS or require client certificates. Without --cert-file, --key-file, --trusted-ca-file and --client-cert-auth, connections remain unauthenticated. Specifying cipher suites is relevant only after TLS and mTLS are already configured.

Webhook

Why it fails: Webhook delegates authorisation to an external HTTP service, so it evaluates whatever that remote endpoint decides, not Kubernetes RBAC policies. It is the right mode when integrating third-party authorisers such as Open Policy Agent, not for native RBAC enforcement.

Node

Why it fails: Node authorises requests from kubelet identities based on their node association, not RBAC policy evaluation. It is tempting because Node and RBAC are commonly enabled together, but Node is the correct mode specifically for restricting kubelet API access, not for evaluating RBAC rules.

AlwaysAllow

Why it fails: AlwaysAllow authorises every request without consulting any policy, so RBAC rules are never evaluated. It is tempting as a troubleshooting shortcut to rule out authorisation failures, and it is the correct choice only in isolated test clusters where access control is deliberately disabled.

It prevents the kubelet from communicating with the control plane nodes.

Why it fails: The insecure port serves unauthenticated plaintext HTTP requests; it does not block kubelet-to-apiserver traffic, which uses the secure port 6443 with client certificates. It is tempting because disabling the insecure port can affect legacy components, but kubelet communication is unaffected by this setting.

It restricts API access exclusively to read-only operations.

Why it fails: The insecure port grants full unauthenticated read and write access to the API, including create and delete operations, so it does not restrict anything to read-only. It is tempting because anonymous requests are unauthenticated, but authorisation is bypassed entirely rather than limited to GET verbs.

It forces all clients to downgrade their TLS encryption cipher suites to plaintext.

Why it fails: The insecure port bypasses TLS entirely rather than negotiating or downgrading cipher suites; clients reaching it simply send plaintext HTTP. It is tempting because both concern weakened transport security, but cipher-suite downgrade attacks target TLS negotiation on the secure port, not this separate unencrypted listener.

--secure-port=0

Why it fails: Setting --secure-port=0 disables the HTTPS serving port entirely, taking the API server offline rather than rejecting anonymous requests. The --anonymous-auth=false flag is what stops unauthenticated access while keeping the API available. Zeroing the secure port is tempting as a blunt lockdown, but it breaks all legitimate API clients, including kubectl and controllers.

--authorization-mode=AlwaysAllow

Why it fails: Authorization mode governs what an authenticated identity may do, not whether anonymous requests are accepted; AlwaysAllow simply grants full access once a request arrives. Disabling anonymous authentication requires the --anonymous-auth=false flag. AlwaysAllow is tempting when a lab cluster needs unrestricted access without RBAC configuration, but it never addresses authentication.

--disable-anonymous=true

Why it fails: No such flag exists; anonymous requests are controlled by --anonymous-auth, which defaults to true and must be set to false. A flag named --disable-anonymous would be tempting as an explicit switch, but Kubernetes configures this through --anonymous-auth instead.

ABAC

Why it fails: Attribute-Based Access Control is a static policy format, not the dynamic node-isolation authorizer.

AlwaysDeny

Why it fails: AlwaysDeny rejects every request, so kubelets could not modify their own Node object or bound Pods at all. It is tempting as a blanket lockdown, but it is only useful for debugging or fully static clusters where no API writes should ever succeed.

PodSecurity

Why it fails: PodSecurity is an admission controller enforcing pod security standards, not an authorisation mode, so it cannot scope kubelet writes to node-local resources. It would be the right choice for restricting privileged, hostPath or host-network pods via namespace labels.

Store the administrative kubeconfig file in a public ConfigMap.

Why it fails: A ConfigMap is readable by anyone with get permissions in that namespace, exposing cluster-admin credentials rather than authenticating the pipeline against the external identity provider. Storing kubeconfigs in ConfigMaps suits distributing non-sensitive client configuration, not bearer credentials that must remain secret.

Enable anonymous requests on the API server for the CI/CD CIDR block.

Why it fails: Anonymous requests grant unauthenticated access to anyone reaching the API server, so the pipeline is never identified against the external identity provider and no token validation occurs. It is tempting when restricting by source CIDR feels like access control, but anonymous auth suits only deliberately public, read-only endpoints.

Create a shared static password file and pass it via --basic-auth-file.

Why it fails: Static password files provide long-lived credentials and cannot integrate with an external identity provider, contradicting the requirement. It is tempting because basic authentication is a simple API server mechanism, and it would be correct only for legacy clusters using fixed local credentials.

kube-controller-manager

Why it fails: kube-controller-manager runs reconciliation loops that watch and update objects through the API server, not etcd directly. It is tempting because controllers drive cluster state toward desired state, yet persistence and retrieval of that state in etcd is exclusively the API server's role.

kube-scheduler

Why it fails: kube-scheduler watches for unscheduled pods and binds them to nodes; it reads and writes through the API server rather than touching etcd directly. It is tempting because scheduling decisions update cluster state, but only the API server holds the etcd client and performs those reads and writes.

kubelet

Why it fails: kubelet runs on each worker node, managing pod lifecycles and reporting status to the API server; it never contacts etcd. It is tempting because it reports node and pod state, but that state reaches etcd only via the API server, which owns the etcd client connection.