[Yandex Cloud documentation](../../index.md) > [Yandex Security Deck](../index.md) > [Rule reference](index.md) > KSPM ## KSPM — Kubernetes® Security Posture Management Rules for checking Kubernetes cluster configuration. ### Restrictive permissions for Kubelet service file are set {#host-security.kubelet-service-file-perm-600} #| || **kind** | **severity** | **ID** || || HostSecurity | Medium | host-security.kubelet-service-file-perm-600 || |# #### Description The kubelet service file controls various parameters that set the behavior of the kubelet service in the worker node. You should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system. #### Recommendations **To perform the audit manually:** Run the below command (based on the file location on your system) on the each worker node. For example: ``` stat -c %a /etc/systemd/system/kubelet.service.d/kubeadm.conf ``` Verify that the permissions are set as `600` or more restrictive. **Remediation:** Run the below command (based on the file location on your system) on the each worker node. For example: ``` chmod 600 /etc/systemd/system/kubelet.service.d/kubeadm.conf ``` ### Kubelet service file ownership is set to root:root {#host-security.kubelet-service-file-owner-root} #| || **kind** | **severity** | **ID** || || HostSecurity | Medium | host-security.kubelet-service-file-owner-root || |# #### Description The kubelet service file controls various parameters that set the behavior of the kubelet service in the worker node. You should set its file ownership to maintain the integrity of the file. The file should be owned by `root:root`. #### Recommendations **To perform the audit manually:** Run the below command (based on the file location on your system) on the each worker node. For example: ``` stat -c %U:%G /etc/systemd/system/kubelet.service.d/kubeadm.conf ``` Verify that the ownership is set to `root:root`. **Remediation:** Run the below command (based on the file location on your system) on the each worker node. For example: ``` chown root:root /etc/systemd/system/kubelet.service.d/kubeadm.conf ``` ### Restrictive permissions for kubeconfig configuration file are set {#host-security.kubelet-conf-600} #| || **kind** | **severity** | **ID** || || HostSecurity | Medium | host-security.kubelet-conf-600 || |# #### Description The `kubelet.conf` file is the kubeconfig file for the node. It controls various parameters that set the behavior and identity of the worker node. You should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system. #### Recommendations **To perform the audit manually:** Run the below command (based on the file location on your system) on the each worker node. For example: ``` stat -c %a /etc/kubernetes/kubelet.conf ``` Verify that the permissions are `600` or more restrictive. **Remediation:** Run the below command (based on the file location on your system) on the each worker node. For example: ``` chmod 600 /etc/kubernetes/kubelet.conf ``` ### The owner of kubeconfig configuration file is set to root:root {#host-security.kubelet-conf-owner-root} #| || **kind** | **severity** | **ID** || || HostSecurity | Medium | host-security.kubelet-conf-owner-root || |# #### Description The `kubelet.conf` file is the kubeconfig file for the node. It controls various parameters that set the behavior and identity of the worker node. You should set its file ownership to maintain the integrity of the file. The file should be owned by `root:root`. #### Recommendations **To perform the audit manually:** Run the below command (based on the file location on your system) on the each worker node. For example: ``` stat -c %U:%G /etc/kubernetes/kubelet.conf ``` Verify that the ownership is set to `root:root`. **Remediation:** Run the below command (based on the file location on your system) on the each worker node. For example: ``` chown root:root /etc/kubernetes/kubelet.conf ``` ### Restrictive permissions for Kubelet configuration file are set {#host-security.kubelet-config-permissions-600} #| || **kind** | **severity** | **ID** || || HostSecurity | Medium | host-security.kubelet-config-permissions-600 || |# #### Description Ensure that if the kubelet refers to a configuration file with the `--config` argument, that file has permissions of `600` or more restrictive. The kubelet reads various parameters, including security settings, from a config file specified by the `--config` argument. If this file is specified, you should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system. #### Recommendations **To perform the audit manually:** Run the below command (based on the file location on your system) on the each worker node. For example: ``` stat -c %a /var/lib/kubelet/config.yaml ``` Verify that the permissions are set as `600` or more restrictive. **Remediation:** Run the following command (using the config file location identified in the Audit step): ``` chmod 600 /var/lib/kubelet/config.yaml ``` ### The owner of Kubelet configuration file is set to root:root {#host-security.kubelet-config-owner-root} #| || **kind** | **severity** | **ID** || || HostSecurity | Medium | host-security.kubelet-config-owner-root || |# #### Description Ensure that if the kubelet refers to a configuration file with the `--config` argument, that file is owned by `root:root`. The kubelet reads various parameters, including security settings, from a config file specified by the `--config` argument. If this file is specified, you should restrict its file permissions to maintain the integrity of the file. The file should be owned by `root:root`. #### Recommendations **To perform the audit manually:** Run the below command (based on the file location on your system) on the each worker node. For example: ``` stat -c %U:%G /var/lib/kubelet/config.yaml ``` Verify that the ownership is set to `root:root`. **Remediation:** Run the following command (using the config file location identied in the Audit step): ``` chown root:root /etc/kubernetes/kubelet.conf ``` ### Requests from anonymous users to Kubelet server are disabled {#host-security.anonymous-auth-false} #| || **kind** | **severity** | **ID** || || HostSecurity | Medium | host-security.anonymous-auth-false || |# #### Description Disable anonymous requests to the Kubelet server. When enabled, requests that are not rejected by other configured authentication methods are treated as anonymous requests. These requests are then served by the Kubelet server. You should rely on authentication to authorize access and disallow anonymous requests. #### Recommendations **To perform the audit manually:** If using a Kubelet configuration file, check that there is an entry for `authentication: anonymous: enabled` set to *false*. Run the following command on each node: ``` ps -ef | grep kubelet ``` Verify that the `--anonymous-auth` argument is set to *false*. This executable argument may be omitted, provided there is a corresponding entry set to *false* in the Kubelet config file. **Remediation:** If using a Kubelet config file, edit the file to set `authentication: anonymous: enabled` to *false*. If using executable arguments, edit the kubelet service file `/etc/kubernetes/kubelet.conf` on each worker node and set the below parameter in `KUBELET_SYSTEM_PODS_ARGS` variable: `--anonymous-auth=false` Based on your system, restart the kubelet service. For example: ``` systemctl daemon-reload systemctl restart kubelet.service ``` ### Only explicitly authorized requests to Kubelet server are allowed {#host-security.auth-mode-not-always-allow} #| || **kind** | **severity** | **ID** || || HostSecurity | Medium | host-security.auth-mode-not-always-allow || |# #### Description Do not allow all requests. Enable explicit authorization. Kubelets, by default, allow all authenticated requests (even anonymous ones) without needing explicit authorization checks from the apiserver. You should restrict this behavior and only allow explicitly authorized requests. #### Recommendations **To perform the audit manually:** Run the following command on each node: ``` ps -ef | grep kubelet ``` If the `--authorization-mode` argument is present, check that it is not set to *AlwaysAllow*. If it is not present, check that there is a Kubelet config file specified by `--config`, and that file sets `authorization: mode` to something other than *AlwaysAllow*. It is also possible to review the running configuration of a Kubelet via the `/configz` endpoint on the Kubelet API port (typically `10250/TCP`). Accessing these with appropriate credentials will provide details of the Kubelet's configuration. **Remediation:** If using a Kubelet config file, edit the file to set `authorization: mode` to *Webhook*. If using executable arguments, edit the kubelet service file `/etc/kubernetes/kubelet.conf` on each worker node and set the below parameter in `KUBELET_AUTHZ_ARGS` variable: `--authorization-mode=Webhook` Based on your system, restart the kubelet service. For example: ``` systemctl daemon-reload systemctl restart kubelet.service ``` ### Kubelet authentication via certificates is enabled {#host-security.client-ca-file-set} #| || **kind** | **severity** | **ID** || || HostSecurity | Medium | host-security.client-ca-file-set || |# #### Description Enable Kubelet authentication using certificates. The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet's port-forwarding functionality. These connections terminate at the kubelet's HTTPS endpoint. By default, the apiserver does not verify the kubelet's serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks. Enabling Kubelet certificate authentication ensures that the apiserver could authenticate the Kubelet before submitting any requests. #### Recommendations **To perform the audit manually:** Run the following command on each node: ``` ps -ef | grep kubelet ``` Verify that the `--client-ca-file` argument exists and is set to the location of the client certificate authority file. If the `--client-ca-file` argument is not present, check that there is a Kubelet config file specified by `--config`, and that the file sets `authentication: x509: clientCAFile` to the location of the client certificate authority file. **Remediation:** If using a Kubelet config file, edit the file to set `authentication: x509: clientCAFile` to the location of the client CA file. If using command line arguments, edit the kubelet service file `/etc/kubernetes/kubelet.conf` on each worker node and set the below parameter in `KUBELET_AUTHZ_ARGS` variable: `--client-ca-file=` Based on your system, restart the kubelet service. For example: ``` systemctl daemon-reload systemctl restart kubelet.service ``` ### Kubelet is allowed to manage iptables {#host-security.make-iptables-util-chains-true} #| || **kind** | **severity** | **ID** || || HostSecurity | Medium | host-security.make-iptables-util-chains-true || |# #### Description Allow Kubelet to manage iptables. Kubelets can automatically manage the required changes to iptables based on how you choose your networking options for the pods. It is recommended to let kubelets manage the changes to iptables. This ensures that the iptables configuration remains in sync with pods networking configuration. Manually configuring iptables with dynamic pod network configuration changes might hamper the communication between pods/containers and to the outside world. You might have iptables rules too restrictive or too open. #### Recommendations **To perform the audit manually:** Run the following command on each node: ``` ps -ef | grep kubelet ``` Verify that if the `--make-iptables-util-chains` argument exists, then it is set to true. If the `--make-iptables-util-chains` argument does not exist, and there is a Kubelet config file specified by `--config`, verify that the file does not `set makeIPTablesUtilChains` to *false*. **Remediation:** If using a Kubelet config file, edit the file to set `makeIPTablesUtilChains: true`. If using command line arguments, edit the kubelet service file `/etc/kubernetes/kubelet.conf` on each worker node and remove the `--make-iptables-util-chains` argument from the `KUBELET_SYSTEM_PODS_ARGS` variable. Based on your system, restart the kubelet service. For example: ``` systemctl daemon-reload systemctl restart kubelet.service ``` ### Kubelet client certificate rotation is enabled {#host-security.rotate-certs-not-false} #| || **kind** | **severity** | **ID** || || HostSecurity | Medium | host-security.rotate-certs-not-false || |# #### Description Enable kubelet client certificate rotation. The `--rotate-certificates` setting causes the kubelet to rotate its client certificates by creating new CSRs as its existing credentials expire. This automated periodic rotation ensures that there is no downtime due to expired certificates and thus addressing availability in the CIA security triad. **Note:** This recommendation only applies if you let kubelets get their certificates from the API server. In case your kubelet certificates come from an outside authority/tool (e.g. Vault) then you need to take care of rotation yourself. **Note:** This feature also requires the `RotateKubeletClientCertificate` feature gate to be enabled (which is the default since Kubernetes v1.7) #### Recommendations **To perform the audit manually:** Run the following command on each node: ``` ps -ef | grep kubelet ``` Verify that the `RotateKubeletServerCertificate` argument is not present, or is set to true. If the `RotateKubeletServerCertificate` argument is not present, verify that if there is a Kubelet config file specified by `--config`, that file does not contain `RotateKubeletServerCertificate: false`. **Remediation:** If using a Kubelet config file, edit the file to add the line `rotateCertificates: true` or remove it altogether to use the default value. If using command line arguments, edit the kubelet service file `/etc/kubernetes/kubelet.conf` on each worker node and remove `--rotate-certificates=false` argument from the `KUBELET_CERTIFICATE_ARGS` variable or set `--rotate-certificates=true`. Based on your system, restart the kubelet service. For example: ``` systemctl daemon-reload systemctl restart kubelet.service ```