Merge pull request #559 from kubescape/deprecate-old-rules

deprecate-old-rules

controls/C-0002-execintocontainer.json

@@ -13,7 +13,6 @@
     "description": "Attackers with relevant permissions can run malicious commands in the context of legitimate containers in the cluster using \u201ckubectl exec\u201d command. This control determines which subjects have permissions to use this command.",
     "remediation": "It is recommended to prohibit \u201ckubectl exec\u201d command in production environments. It is also recommended not to use subjects with this permission for daily cluster operations.",
     "rulesNames": [
-        "exec-into-container",
         "exec-into-container-v1"
     ],
     "long_description": "Attackers who have permissions, can run malicious commands in containers in the cluster using exec command (\u201ckubectl exec\u201d). In this method, attackers can use legitimate images, such as an OS image (e.g., Ubuntu) as a backdoor container, and run their malicious code remotely by using \u201ckubectl exec\u201d.",

controls/C-0007-datadestruction.json

@@ -12,7 +12,6 @@
     "description": "Attackers may attempt to destroy data and resources in the cluster. This includes deleting deployments, configurations, storage, and compute resources. This control identifies all subjects that can delete resources.",
     "remediation": "You should follow the least privilege principle and minimize the number of subjects that can delete resources.",
     "rulesNames": [
-        "rule-excessive-delete-rights",
         "rule-excessive-delete-rights-v1"
     ],
     "long_description": "Attackers may attempt to destroy data and resources in the cluster. This includes deleting deployments, configurations, storage, and compute resources.",

controls/C-0014-accesskubernetesdashboard.json

@@ -13,7 +13,6 @@
     "description": "Attackers who gain access to the dashboard service account or have its RBAC permissions can use its network access to retrieve information about resources in the cluster or change them. This control checks if a subject that is not dashboard service account is bound to dashboard role/clusterrole, or - if anyone that is not the dashboard pod is associated with dashboard service account.",
     "remediation": "Make sure that the \u201cKubernetes Dashboard\u201d service account is only bound to the Kubernetes dashboard following the least privilege principle.",
     "rulesNames": [
-        "rule-access-dashboard",
         "rule-access-dashboard-subject-v1",
         "rule-access-dashboard-wl-v1"
     ],

controls/C-0015-listkubernetessecrets.json

@@ -13,7 +13,6 @@
     "description": "Attackers who have permissions to access secrets can access sensitive information that might include credentials to various services. This control determines which user, group or service account can list/get secrets.",
     "remediation": "Monitor and approve list of users, groups and service accounts that can access secrets. Use exception mechanism to prevent repetitive the notifications.",
     "rulesNames": [
-        "rule-can-list-get-secrets",
         "rule-can-list-get-secrets-v1"
     ],
     "long_description": "A Kubernetes secret is an object that lets users store and manage sensitive information, such as passwords and connection strings in the cluster. Secrets can be consumed by reference in the pod configuration. Attackers who have permissions to retrieve the secrets from the API server (by using the pod service account, for example) can access sensitive information that might include credentials to various services.",

controls/C-0021-exposedsensitiveinterfaces.json

@@ -12,7 +12,6 @@
     "description": "Exposing a sensitive interface to the internet poses a security risk. It might enable attackers to run malicious code or deploy containers in the cluster. This control checks if known components (e.g. Kubeflow, Argo Workflows, etc.) are deployed and exposed services externally.",
     "remediation": "Consider blocking external interfaces or protect them with appropriate security tools.",
     "rulesNames": [
-        "exposed-sensitive-interfaces",
         "exposed-sensitive-interfaces-v1"
     ],
     "long_description": "Exposing a sensitive interface to the internet poses a security risk. Some popular frameworks were not intended to be exposed to the internet, and therefore don\u2019t require authentication by default. Thus, exposing them to the internet allows unauthenticated access to a sensitive interface which might enable running code or deploying containers in the cluster by a malicious actor. Examples of such interfaces that were seen exploited include Apache NiFi, Kubeflow, Argo Workflows, Weave Scope, and the Kubernetes dashboard.",

controls/C-0031-deletekubernetesevents.json

@@ -13,7 +13,6 @@
     "description": "Attackers may delete Kubernetes events to avoid detection of their activity in the cluster. This control identifies all the subjects that can delete Kubernetes events.",
     "remediation": "You should follow the least privilege principle. Minimize the number of subjects who can delete Kubernetes events. Avoid using these subjects in the daily operations.",
     "rulesNames": [
-        "rule-can-delete-k8s-events",
         "rule-can-delete-k8s-events-v1"
     ],
     "long_description": "A Kubernetes event is a Kubernetes object that logs state changes and failures of the resources in the cluster. Example events are a container creation, an image pull, or a pod scheduling on a node. Kubernetes events can be very useful for identifying changes that occur in the cluster. Therefore, attackers may want to delete these events (e.g., by using: \u201ckubectl delete events\u2013all\u201d) in an attempt to avoid detection of their activity in the cluster.",

controls/C-0035-clusteradminbinding.json

@@ -13,7 +13,6 @@
     "description": "Attackers who have cluster admin permissions (can perform any action on any resource), can take advantage of their privileges for malicious activities. This control determines which subjects have cluster admin permissions.",
     "remediation": "You should apply least privilege principle. Make sure cluster admin permissions are granted only when it is absolutely necessary. Don't use subjects with such high permissions for daily operations.",
     "rulesNames": [
-        "rule-list-all-cluster-admins",
         "rule-list-all-cluster-admins-v1"
     ],
     "long_description": "Role-based access control (RBAC) is a key security feature in Kubernetes. RBAC can restrict the allowed actions of the various identities in the cluster. Cluster-admin is a built-in high privileged role in Kubernetes. Attackers who have permissions to create bindings and cluster-bindings in the cluster can create a binding to the cluster-admin ClusterRole or to other high privileges roles.",

controls/C-0037-corednspoisoning.json

@@ -11,7 +11,6 @@
     "description": "If attackers have permissions to modify the coredns ConfigMap they can change the behavior of the cluster\u2019s DNS, poison it, and override the network identity of other services. This control identifies all subjects allowed to update the 'coredns' configmap.",
     "remediation": "You should follow the least privilege principle. Monitor and approve all the subjects allowed to modify the 'coredns' configmap. It is also recommended to remove this permission from the users/service accounts used in the daily operations.",
     "rulesNames": [
-        "rule-can-update-configmap",
         "rule-can-update-configmap-v1"
     ],
     "long_description": "CoreDNS is a modular Domain Name System (DNS) server written in Go, hosted by Cloud Native Computing Foundation (CNCF). CoreDNS is the main DNS service that is being used in Kubernetes. The configuration of CoreDNS can be modified by a file named corefile. In Kubernetes, this file is stored in a ConfigMap object, located at the kube-system namespace. If attackers have permissions to modify the ConfigMap, for example by using the container\u2019s service account, they can change the behavior of the cluster\u2019s DNS, poison it, and take the network identity of other services.",

controls/C-0042-sshserverrunninginsidecontainer.json

@@ -11,7 +11,6 @@
     "description": "An SSH server that is running inside a container may be used by attackers to get remote access to the container. This control checks if pods have an open SSH port (22/2222).",
     "remediation": "Remove SSH from the container image or limit the access to the SSH server using network policies.",
     "rulesNames": [
-        "rule-can-ssh-to-pod",
         "rule-can-ssh-to-pod-v1"
     ],
     "long_description": "SSH server that is running inside a container may be used by attackers. If attackers gain valid credentials to a container, whether by brute force attempts or by other methods (such as phishing), they can use it to get remote access to the container by SSH.",

controls/C-0053-accesscontainerserviceaccount.json

@@ -13,7 +13,6 @@
     "description": "Attackers who obtain access to a pod can use its SA token to communicate with KubeAPI server. All pods with SA token mounted (if such token has a Role or a ClusterRole binding) are considerred potentially dangerous.",
     "remediation": "Verify that RBAC is enabled. Follow the least privilege principle and ensure that only necessary pods have SA token mounted into them.",
     "rulesNames": [
-        "access-container-service-account",
         "access-container-service-account-v1"
     ],
     "long_description": "Service account (SA) represents an application identity in Kubernetes. By default, an SA is mounted to every created pod in the cluster. Using the SA, containers in the pod can send requests to the Kubernetes API server. Attackers who get access to a pod can access the SA token (located in /var/run/secrets/kubernetes.io/serviceaccount/token) and perform actions in the cluster, according to the SA permissions. If RBAC is not enabled, the SA has unlimited permissions in the cluster. If RBAC is enabled, its permissions are determined by the RoleBindings\\\\ClusterRoleBindings that are associated with it.",

controls/C-0063-portforwardingprivileges.json

@@ -10,7 +10,6 @@
     "description": "Attackers with relevant RBAC permission can use \u201ckubectl portforward\u201d command to establish direct communication with pods from within the cluster or even remotely. Such communication will most likely bypass existing security measures in the cluster. This control determines which subjects have permissions to use this command.",
     "remediation": "It is recommended to prohibit \u201ckubectl portforward\u201d command in production environments. It is also recommended not to use subjects with this permission for daily cluster operations.",
     "rulesNames": [
-        "rule-can-portforward",
         "rule-can-portforward-v1"
     ],
     "long_description": "Attackers who have relevant RBAC permissions, can run open a backdoor communication channel directly to the sockets inside target container using exec command \u201ckubectl portforward\u201d command. Using this method, attackers can bypass network security restrictions and communicate directly with software in the containers.",

controls/C-0065-noimpersonation.json

@@ -12,7 +12,6 @@
     "long_description": "Impersonation is an explicit RBAC permission to use other roles rather than the one assigned to a user, group or service account. This is sometimes needed for testing purposes. However, it is highly recommended not to use this capability in the production environments for daily operations. This control identifies all subjects whose roles include impersonate verb.",
     "test": "Check for RBACs giving 'impersonate' verb to users/groups/uids/serviceaccounts",
     "rulesNames": [
-        "rule-can-impersonate-users-groups",
         "rule-can-impersonate-users-groups-v1"
     ],
     "controlID": "C-0065",