Hard Difficulty Questions

evt.type=sendto and fd.sip != "0.0.0.0"

Why wrong: The `sendto` syscall is primarily used for UDP and raw sockets, not for TCP connections, so it would miss outbound TCP traffic which is the common vector for data exfiltration. Moreover, `fd.sip != "0.0.0.0"` is a meaningless filter because `0.0.0.0` is rarely a destination; it would include all private and broadcast IPs, generating excessive false positives without actually isolating internet-bound traffic.

container.id != host and evt.type=accept

Why wrong: The `accept` syscall is used on a listening socket to complete an incoming connection request; it only indicates that a remote peer has connected to the container, not that the container initiated a connection outward. Therefore even with `container.id != host`, this rule captures inbound traffic, which is the opposite of the required detection. Additionally, it would be useless for detecting UDP-based outbound communications, since UDP doesn't use `accept`.

proc.name = curl and evt.type=connect

Why wrong: Restricting to `proc.name = curl` is far too narrow: outbound connections can be made by any process, from `wget`, shell builtins, language runtimes, to custom malware, so the rule would miss virtually all cases. It also lacks any destination IP filtering, meaning every `connect` by curl, including to internal load balancers or private services, would trigger an alert, flooding the security team with false positives. A robust detection should key on the connection semantics and destination, not a specific userland tool.

A ConfigMap in the etcd namespace

Why wrong: The encryption key is not stored in any Kubernetes object such as a ConfigMap. The kube-apiserver reads the key from a local file, the EncryptionConfiguration, specified via the --encryption-provider-config flag at process startup. Even if a ConfigMap existed in a namespace named 'etcd', the API server would not consume it dynamically, and etcd itself has no concept of Kubernetes namespaces. Furthermore, putting key material in a ConfigMap would expose it in etcd, which is exactly what encryption at rest is meant to protect.

A Secret in the kube-system namespace

Why wrong: A Secret in the kube-system namespace is a tempting but incorrect choice because the EncryptionConfiguration is delivered as a file, not as a Secret object. If the key were stored as a Secret, it would itself be persisted in etcd and require encryption, creating a bootstrap problem. Moreover, the API server loads the encryption configuration only once at startup; it does not watch or fetch a Secret containing the key at runtime. Secrets are also base64-encoded, not a secure way to store sensitive key material when the entire datastore is at risk.

An annotation on the etcd pod

Why wrong: An annotation on an etcd pod is not a valid storage location for encryption keys because annotations are metadata fields on Kubernetes objects and are stored in etcd themselves, meaning they would not be protected from unauthorized etcd access. More importantly, etcd pods do not perform or need the encryption key; encryption and decryption are handled by the kube-apiserver, which intercepts resource writes and reads. Annotations are also limited to 256KB, are visible via the object's metadata, and offer no intended mechanism for secret delivery to other components, making them completely unsuitable for key material.

Kyverno is not an admission controller; it only mutates resources

Why wrong: Kyverno is fundamentally an admission controller: it installs both a MutatingAdmissionWebhook and a ValidatingAdmissionWebhook into the cluster. These webhooks intercept API requests at the admission phase, allowing Kyverno to not only mutate resources (like adding default labels) but also validate them and reject noncompliant requests. The claim that it 'only mutates resources' conflates one of its capabilities with its full role; validation and generation are also core features.

The Kyverno policy requires an external registry to compare images, which is unavailable

Why wrong: Kyverno policies can enforce image rules (e.g., disallowing the 'latest' tag, requiring a specific registry prefix, or checking for an allowed image signature) using YAML pattern matching and conditional anchors directly on the Pod's image field. These rules are evaluated from the resource definition alone, requiring no external network calls. Only specific policy types like 'verifyImages' explicitly query a container registry, and your scenario does not indicate that such a policy is in use.

The Pod was created by a Deployment controller, which bypasses admission control

Why wrong: Kubernetes admission controllers run for every API request, regardless of whether the requester is a human user, a Deployment controller, or any other automation. When a Deployment creates a ReplicaSet, and that ReplicaSet later creates a Pod, each of those create requests is processed by the API server's admission chain, including any dynamically configured admission webhooks. Thus a Pod created by a Deployment is not bypassing admission control; its Pod creation request still triggers Kyverno's webhook if the webhook's rules match Pod resources.

Expose the Dashboard via a NodePort service to the internet

Why wrong: A NodePort service publishes a port on every node's IP address, making the dashboard reachable from any network that can route to those nodes, potentially including the public internet. NodePort does not provide any authentication or TLS encryption, so unless the dashboard itself has strong authentication and you add firewall rules, you are exposing it to unauthenticated access. This is the opposite of a secure isolation strategy and should never be used for sensitive workloads.

Deploy the Dashboard with a hostNetwork: true configuration

Why wrong: Setting hostNetwork: true places the dashboard pod in the host's network namespace, so it binds directly to the node's IP address and port, bypassing ClusterIP, NodePort, and any Kubernetes NetworkPolicy isolation. This removes the network security boundary provided by kube-proxy and makes the dashboard accessible to any endpoint that can reach the node, including a corporate or public network. It also opens the door to port conflicts and leaks internal services, making it a high-risk configuration with no authentication benefit.

The image tag does not exist in the registry

Why wrong: The 'No signatures found' error occurs only after cosign successfully retrieves the image manifest and computes its digest, then searches for a signature artifact tagged from that digest (e.g., 'sha256-<digest>.sig'). If the image tag itself does not exist, the registry returns a 404 MANIFEST_UNKNOWN error during manifest resolution, which happens before any signature lookup is attempted. Therefore, a non-existent tag yields a completely different failure message, not the signature-absence error, making this option incorrect.

Developer B used a different private key to sign than the public key used for verification

Why wrong: When a signature exists but was created using a different private key, the registry will contain a signature artifact, so cosign's discovery step will successfully list it. Only after retrieving the signature does cosign attempt cryptographic verification against the public key provided via `--key`; that step would fail with an 'invalid signature' or 'signature verification failed' error, not with 'No signatures found'. The 'No signatures found' message indicates that zero signature artifacts were discovered in the registry, meaning the failure occurs before key-based verification can even begin.

Developer A used the public key instead of the private key

Why wrong: Using a public key instead of the private key during signing would cause `cosign sign` itself to reject the operation, because generating a signature requires the private key component; the command would exit with a key-format or cipher error. Such a failure would either leave no signature pushed or produce a signing error that the developer would immediately observe, not a verification-time 'No signatures found'. The observed error is about the absence of signature artifacts in the registry, which is independent of whether the wrong key type was attempted at signing time.

Set etcd's --peer-client-cert-auth flag to true

Why wrong: This flag enables mutual TLS authentication for the peer port (2380) where etcd nodes communicate with each other, not for the client port (2379) used by the API server. Turning it on verifies each etcd member's certificate but does not restrict what a client can read or write. It is therefore irrelevant to enforcing authorization against a client with a valid certificate, which requires etcd RBAC rules.

Set etcd's --client-cert-auth flag to false

Why wrong: Setting --client-cert-auth to false would disable client certificate authentication, meaning etcd would accept any client without requiring a valid cert. This eliminates the identity information needed to map a client to an RBAC role, breaking the entire access-control model. In a TLS-configured etcd, this flag must remain true so the API server's CN can be used for authorization; setting it to false directly reduces security.

Use a NetworkPolicy to restrict access to etcd port 2379

Why wrong: NetworkPolicies are Kubernetes resources that segment pod-to-pod traffic using labels and IP blocks, and they only apply within the cluster's CNI scope. If etcd runs as a static pod, outside the cluster, or on dedicated hosts, a NetworkPolicy cannot influence connections to it. Even when applicable, a NetworkPolicy cannot inspect X.509 certificate CNs or authorize specific clients, so it cannot replace etcd-native RBAC access control.

The Constraint is missing the 'match' field

Why wrong: A Constraint lacking the `match` field does not silently fail to enforce; rather, Gatekeeper's schema validation typically rejects the resource because `match` is a required field in the Constraint spec. In the unlikely event it were accepted, the default behavior would match no resources, meaning zero Pods are selected for evaluation. Either way, the Constraint would either never be created (visible in the cluster) or would be inert — not a hidden cause of non-blocking while the Constraint looks active. Therefore, the missing `match` field would produce an obvious failure, not a subtle dryrun-like behavior.

The Constraint is in a different namespace than the pods

Why wrong: Gatekeeper Constraints are cluster-scoped custom resources, not namespaced objects, so their physical placement in a namespace has no effect on which resources they apply to. Namespace selection is handled by the `match` field inside the Constraint's spec, which can target specific namespaces (or exclude them) via `namespaces` or `namespaceSelector`. Placing the Constraint in a particular namespace does not limit or redirect its enforcement scope; it is visible and evaluated for all Pods in all namespaces. Therefore, a namespace mismatch cannot explain why violating Pods are being allowed, because the Constraint's namespace is irrelevant to its enforcement.

The ConstraintTemplate is missing the 'violation' rule

Why wrong: A ConstraintTemplate defines the Rego policy logic, and the mandatory entry point is a rule named `violation` (e.g., `violation[violation] { ... }`). If this rule is omitted, the template is malformed and the Gatekeeper controller will reject it, so no actual Constraints can be created from that template. The user would see a clear error in the Template's status, and the Constraint itself would not exist — thus it cannot be responsible for letting violating Pods through. Since the Constraint in question is apparently present (it is just not blocking), a missing `violation` rule would have prevented its creation altogether, making this option inconsistent with the observed symptom.

Set securityContext.runAsUser: 1000

Why wrong: Running as a non-root user (e.g., UID 1000) only changes the numeric user ID of the process; it does not modify the kernel's authorization model or disable setuid semantics. A malicious process can still execute a binary with the setuid bit set, such as /usr/bin/sudo or a program with the SUID root flag, which temporarily grants euid=0 and therefore privileges beyond the original user. Additionally, runAsUser does not restrict syscalls like ptrace or mount, nor does it prevent exploiting kernel vulnerabilities to elevate privileges. Thus, while runAsUser is a good hardening step, it does not directly block the privilege escalation channel described in the incident.

Set securityContext.readOnlyRootFilesystem: true

Why wrong: Setting readOnlyRootFilesystem: true prevents writes to the root filesystem, making tampering with binaries or configuration files harder, but it does not stop a process from executing privilege-escalating operations. The kernel still allows the process to invoke privileged syscalls (e.g., mount, chroot, or ptrace) because the filesystem restriction is orthogonal to capability checks. An attacker could also write a setuid binary to an emptyDir volume or writable path and execute it, and temporary filesystems like /dev/shm or /tmp remain writable unless explicitly remounted. Therefore, read-only root is a filesystem integrity control, not a privilege-escalation prevention mechanism.

Drop all capabilities with securityContext.capabilities.drop: ["ALL"]

Why wrong: Dropping all Linux capabilities with capabilities.drop: ["ALL"] removes the process's permitted and effective capability sets, but it does not disable the setuid mechanism that many binaries rely on. When a process executes a setuid-root binary, the kernel sets the effective UID to 0 and then grants the process the full root capabilities regardless of its previous capability state, because the privilege escalation is based on UID transition, not on existing capabilities. Thus, even a container with no capabilities can gain complete root privileges by running a setuid binary that is present in the image (e.g., /bin/su, mounted host binaries, or a compromised setuid utility). Capability dropping is valuable for reducing the attack surface, but it does not directly block the setuid path.

The kubelet is configured to always mount tokens

Why wrong: There is no kubelet configuration that forces service account token mounting for all pods; the kubelet only honors the `automountServiceAccountToken` field in the pod spec (or the effective setting from the service account). Even if such a flag existed, it would contradict Kubernetes' per-pod security model and would require a feature gate, not a simple kubelet flag. The presence or absence of the token is therefore determined entirely by pod and service account configuration, not by kubelet settings.

The namespace has a default automountServiceAccountToken: true

Why wrong: Kubernetes does not have a namespace-level `automountServiceAccountToken` default; that field exists only on `PodSpec` and `ServiceAccount`. The pod's own setting takes precedence over any inherited or default value, so if the pod spec explicitly set `automountServiceAccountToken: false`, the token would not be mounted regardless of any hypothetical namespace default. Because no such namespace mechanism exists, this cannot explain why the token is present.

The pod is using a custom service account with automountServiceAccountToken: true

Why wrong: When both the pod spec and the service account specify `automountServiceAccountToken`, the pod-level value wins; a service account's `true` cannot override a pod's `false`. The kubelet reads the effective `PodSpec` field after merging service account settings, so a custom service account with `automountServiceAccountToken: true` would only matter if the pod did not explicitly set the field. This option would imply a precedence that Kubernetes does not implement, making it an incorrect explanation for the observed token mount.

clientConfig: url: https://webhook.svc.cluster.local:443/validate

Why wrong: While a raw `url` is accepted in a ValidatingWebhookConfiguration, this particular URL is incorrect for two reasons. First, the hostname `webhook.svc.cluster.local` would resolve to a Service named `webhook` in the `svc` namespace, inverting the actual service name and namespace of the deployed webhook (`svc` in `webhook`). Second, hardcoding the cluster domain makes the manifest environment-specific and fragile; the Service reference approach avoids this and is the standard. Therefore this option fails to target the running webhook.

clientConfig: service: namespace: webhook name: webhook path: /validate

Why wrong: This option selects the correct namespace, `webhook`, but specifies a Service name of `webhook` instead of the actual Service name `svc`. The Service backing the validation webhook is explicitly named `svc` in the deployment; a mismatch here means the API server will attempt to connect to a Service that does not exist, causing the webhook call to fail with a connection error. The Service name must exactly match the `metadata.name` of the Service object in that namespace.

clientConfig: service: namespace: default name: svc path: /validate

Why wrong: Here the Service name `svc` and path `/validate` are correct, but the namespace is set to `default`. The webhook's Service is deployed in the `webhook` namespace, so this configuration will cause the API server to look for a Service named `svc` in `default`, which is not the intended endpoint. As a result, admission requests that trigger this webhook will be unable to reach it, and depending on the failurePolicy, they may be denied or forced to bypass validation. The namespace field must match the Service's actual namespace.

Expose the dashboard as a NodePort service for easy access

Why wrong: Exposing the dashboard as a NodePort service binds port 30000–32767 on every node's primary interface, making the UI reachable from any network that can reach the nodes. This bypasses the internal ClusterIP isolation and ignores Ingress/NetworkPolicy controls, turning every node into a potential attack point. A NodePort also does not automatically apply TLS or strong authentication, so an attacker who finds the node IP and port can directly interact with the dashboard's login page (or even the API if the dashboard has broad RBAC). This is a classic anti-pattern for admin UIs because it unnecessarily enlarges the cluster's attack surface.

Configure firewall rules to restrict access to the dashboard's ClusterIP

Why wrong: A ClusterIP is only routable from inside the cluster; firewall rules applied to node external interfaces or host-level iptables do not govern its reachability. The dashboard's real public exposure occurs when it is backed by a LoadBalancer, NodePort, or Ingress object — none of which are controlled by firewall rules on the ClusterIP itself. Even if you added network policies to restrict traffic to the ClusterIP, that only limits inter-pod traffic, not external access that arrives via an ingress or LB. The fundamental issue is the dashboard service's type, not its ClusterIP, so firewall rules offer a false sense of security and do not address the root cause.

Enable authentication on the dashboard

Why wrong: Enabling authentication (e.g., a kubeconfig token or a login form) adds a barrier, but it does not neutralize the danger of exposing a highly privileged admin panel to the internet. The Kubernetes dashboard can grant access to secrets, pods, and other cluster resources; if it is publicly reachable, a vulnerability in the dashboard's login flow, a credential leak, or a CSRF/SSRF flaw could lead to cluster compromise. Moreover, the dashboard is often misconfigured with 'skip-login' enabled, which lets anyone access it without authentication. Authentication is necessary but not sufficient: the dashboard should never be exposed publicly, regardless of the auth mechanism.

Add a PodSecurityPolicy that drops CAP_SYS_ADMIN

Why wrong: PodSecurityPolicy (PSP) is deprecated in Kubernetes 1.21 and removed in 1.25, so it cannot provide a current cluster-wide control on supported clusters. Even when the pod-security-policy admission controller was still enabled, a PSP only applied to a workload after being explicitly bound to a ServiceAccount or user, so it did not automatically drop CAP_SYS_ADMIN from every pod everywhere.

Modify the kubelet to disallow CAP_SYS_ADMIN

Why wrong: The kubelet launches containers through the container runtime (typically containerd via CRI) and has no flag or configuration that selectively removes a named capability such as CAP_SYS_ADMIN from a Pod's securityContext. Kubelet-level tuning concerns node services and runtime parameters, not per-container Linux capabilities; altering capability sets must be done at admission time by rewriting the Pod spec, not by changing the node agent.

Configure each namespace with 'pod-security.kubernetes.io/enforce: restricted'

Why wrong: Setting the namespace label pod-security.kubernetes.io/enforce: restricted does trigger the Pod Security Admission controller, and the restricted policy requires all Linux capabilities to be dropped, so CAP_SYS_ADMIN cannot be added. However, this enforcement is per-namespace: you must label every existing and future namespace individually, and any namespace without the label remains unrestricted. Thus it is not a single cluster-wide automatic control and is prone to administrative gaps as new namespaces are created.

The pod must run as privileged to use AppArmor

Why wrong: AppArmor does not require privileged containers; in fact, privileged containers typically bypass Linux security module (LSM) restrictions. A container is confined by having the AppArmor profile loaded on the host and referencing it via the Kubernetes annotation, regardless of privilege level. Running privileged would disable AppArmor confinement, making the workload less secure. Thus, the pod does not need to be privileged; the issue lies elsewhere.

The annotation is missing the 'localhost/' prefix

Why wrong: The annotation value already includes the required 'localhost/' prefix, which indicates a custom profile loaded on the node. Without this prefix, Kubernetes would interpret the profile as one of the runtime's built-in profiles and could fail to apply the intended policy. Because the prefix is present and the annotation is correctly formatted, a formatting mistake cannot explain the lack of enforcement. The real problem is that the profile is loaded in complain mode, not enforce mode.

The profile is not loaded on the node

Why wrong: The scenario explicitly states that the node has the AppArmor profile loaded, so the kernel already has the profile's rule set available. If the profile were absent, the container runtime would either reject pod creation or fail to start with a 'profile not found' error. Since the profile is loaded, the container's lack of restriction cannot be due to a missing profile. The failure to enforce restrictions points directly to the profile being in complain mode rather than its absence.

Use 'kubectl auth can-i --list' to check the service account's permissions.

Why wrong: This command is diagnostic and will enumerate the effective permissions of the service account, but it does not alter any RBAC objects. While it can confirm the scope of the excessive cluster-admin grant, it provides no remediation. You must create a custom Role and binding to actually reduce privileges.

Delete the ClusterRoleBinding immediately.

Why wrong: Removing the ClusterRoleBinding outright is a blunt, irreversible action that would instantly revoke all administrative capabilities from the service account. Without first analyzing which API resources and verbs the workload genuinely requires, you risk causing widespread outages or losing the ability to manage the cluster entirely. A safer approach is to inspect the binding, identify the subject, and then create a scoped Role that preserves necessary operations.

Run 'kubectl get clusterrolebindings' to list all bindings.

Why wrong: Listing cluster role bindings only surfaces metadata such as the binding name, subjects, and referenced ClusterRole; it does not reveal the detailed permission rules or help you determine which permissions are excessive. To evaluate least privilege you need to inspect the ClusterRole definition (e.g., kubectl get clusterrole cluster-admin -o yaml) and cross-reference it with the service account's actual usage. Simply listing bindings is a discovery step, not a remediation strategy.

The seccomp profile must be set via an admission controller, not OPA.

Why wrong: OPA/Gatekeeper is an admission controller that can absolutely be used to enforce seccomp profiles by validating the `securityContext` of incoming resources. The explanation is not that a different admission controller is required; rather, the constraint's logic is looking at the pod-level field while the Deployment actually sets the seccomp profile inside each container's `securityContext`. This tooling is fully capable of the enforcement, but the scope of the check is the root cause of the bypass.

OPA/Gatekeeper is not properly installed or the constraint is not active.

Why wrong: If OPA/Gatekeeper were not properly installed, or if the constraint template had not been instantiated as a Constraint with a `match` scope covering this Deployment, the system would probably reject all checks or apply no constraint at all. Since the constraint is still enforcing other checks (like privileged containers), the admission controller is active and functioning. The defect is not in the deployment or activation of Gatekeeper, but in the specific JSON path used inside the violation rule.

The cluster's nodes do not support seccomp, so the profile is ignored.

Why wrong: Seccomp is a Linux kernel feature, and modern Kubernetes nodes—especially those running containerd 1.6 or newer—enable it by default through the default profile. Even if a profile were ignored due to node limitations, the failure would manifest as a warning or error from the kubelet during pod creation, not as a silent pass in the policy check. The cluster's nodes are capable, so the reason the Deployment passes must be the constraint's field‑level logic.

Set up a NetworkPolicy to block traffic from other registries

Why wrong: NetworkPolicy works at the network layer (L3/L4) and governs traffic between pods and to external IPs/CIDRs using selectors and ports. It does not understand or evaluate the image reference used by a pod, and image pulls are performed by the kubelet from the node, not from inside the pod's network namespace. Therefore, a NetworkPolicy cannot prevent a pod from running an image from an unapproved registry; it only restricts connectivity, not workload admission.

Configure an ImagePolicyWebhook

Why wrong: ImagePolicyWebhook is an admission controller that calls an external HTTP service to make image-related admission decisions, and it is commonly deployed to verify image signatures or check for known vulnerabilities, not to simply allowlist a registry. While you could theoretically write a custom backend that rejects non-approved registries, that is building a custom policy engine from scratch. The standard, declarative way to enforce registry allowlisting is a policy engine like OPA/Gatekeeper, not a signature-verification hook.

Modify the kubelet configuration to only pull from a specific registry

Why wrong: The kubelet is the node agent responsible for pulling images and running containers, but it has no configuration option to restrict which registries may be used; it simply pulls whatever image reference is sent in the Pod spec. Editing kubelet config per node would be inconsistent, non-centralized, and still bypassable because the kubelet will accept any valid image if it can be pulled. Registry allowlisting must be implemented at the admission stage, before the Pod spec is persisted or dispatched to nodes.

Set high CPU requests to ensure performance

Why wrong: CPU requests are a scheduling and resource QoS mechanism, not a security boundary. They only indicate to the Kubernetes scheduler how much node capacity the pod requires, affecting placement and eviction; they do nothing to restrict syscalls, filesystem access, or network behavior. Setting high CPU requests may actually worsen security by exhausting node resources and enabling denial-of-service against co-located workloads, while real hardening requires seccomp, AppArmor, and securityContext fields.

Expose secrets as environment variables for convenience

Why wrong: Putting secrets in environment variables is a serious anti-pattern because environment variables are inherited by all child processes, visible in /proc/1/environ, and often get logged by applications or debugging tools. The secret data is only base64-encoded, not encrypted, so it can be easily decoded by anyone who can read the pod definition or process environment. Kubernetes mounted Secrets are safer because they are exposed as files with permissions, use tmpfs, and allow rotation through file updates rather than container recreation.

The encryption provider is set to 'identity' which does not encrypt

Why wrong: This option assumes the configured provider is 'identity', but that is unlikely because the admin explicitly created an EncryptionConfiguration. The identity provider is the default when no configuration exists, and it stores secrets as plaintext in etcd. If the admin had intended encryption, they would have configured a real encryption provider such as 'aescbc' or 'aesgcm', so this explanation does not match the scenario described.

The kube-apiserver was not restarted after applying the configuration

Why wrong: The admin explicitly stated that the kube-apiserver was restarted after applying the configuration, so this cannot be the cause. The EncryptionConfiguration is loaded once at API server startup, and a restart is indeed required for changes to take effect. Since the restart already happened, the lack of encryption must be due to something else, not a missed restart.

The EncryptionConfiguration has a syntax error that caused it to be ignored

Why wrong: A syntax error in the EncryptionConfiguration would not cause the API server to silently ignore the file; instead, the API server would fail to start or would log fatal errors during startup, because the configuration is parsed and validated at initialization. Since the admin reports the API server is running normally and applying the configuration did not break it, a syntax error is not a plausible explanation. Thus, this option is incorrect.

etcdctl --endpoints=https://10.0.0.1:2379 --cert=/etc/etcd/etcd-client.crt endpoint health

Why wrong: This command is missing two essential TLS elements: the --cacert flag to verify the server's certificate chain and the --key flag to accompany the client certificate. Without --cacert, the etcdctl client cannot validate that the server at 10.0.0.1:2379 is genuinely the etcd endpoint, leaving it vulnerable to man-in-the-middle attacks during the TLS handshake. Additionally, because etcd is configured for mutual TLS, the server requires the client to present both a certificate (--cert) and its private key (--key); omitting the key means the client certificate cannot be used for authentication, so the server will reject the connection.

etcdctl --endpoints=https://10.0.0.1:2379 --cacert=/etc/etcd/ca.crt endpoint health

Why wrong: This command includes the CA certificate (--cacert), which allows the client to verify the server's identity, but it omits the client certificate (--cert) and client key (--key). Since the etcd cluster uses TLS for client communication and is configured to require mutual TLS, the server will demand a valid client certificate during the handshake. Without presenting any client certificate, the client fails the server's authentication step, so the endpoint health request is rejected before any status check can occur—even though the server itself passed verification.

etcdctl --endpoints=http://10.0.0.1:2379 endpoint health

Why wrong: This command uses an http:// URL instead of https://, so it attempts a plaintext connection to a TLS-enabled etcd endpoint. The etcd server is configured to accept only TLS-encrypted client communication, so it will refuse or drop the non-TLS connection, and the health check will fail. Even if the server were misconfigured to accept HTTP, this command would be insecure because it sends no CA, client certificate, or key, meaning there is no server authentication and no client authentication—violating the mutual TLS requirement entirely.

Use kubectl encrypt secrets command.

Why wrong: kubectl does not have an 'encrypt' subcommand in any supported version. The kubectl CLI is a client for the Kubernetes API and only handles request/response operations; it never directly writes to etcd or transforms stored data. Secret encryption is performed transparently by the kube-apiserver before the resource is persisted, so a user-facing CLI command cannot trigger or configure it.

Modify the etcd configuration to enable encryption.

Why wrong: Kubernetes does not encrypt data by modifying etcd's own configuration; etcd simply stores the bytes it receives from the kube-apiserver. Encryption must be applied at the API server layer because it is the only component that understands the resource structure and has the keys. Putting an encryption setting in etcd's startup flags or config file would either be unsupported or would encrypt the entire etcd database, not individual Secret objects, and would not integrate with Kubernetes identity/authorization. The only supported path is the apiserver's --encryption-provider-config flag.

Set the environment variable ENCRYPT_SECRETS=true on all nodes.

Why wrong: No environment variable named ENCRYPT_SECRETS exists in Kubernetes. The control plane components are configured primarily through command-line flags and configuration files, not through generic environment variables that would be present on all nodes. Even if you set such a variable on every node, the kube-apiserver would ignore it, and the etcd data would remain plaintext. Encryption at rest is enabled exclusively by the --encryption-provider-config flag on the kube-apiserver, which points to a YAML resource containing the provider and key settings.