Skip to content

Commit dee64a3

Browse files
slashbenslashben
committed
Implementing controls for CIS 1.10 5.1.9 to 5.1.13
Signed-off-by: Ben <[email protected]>
1 parent b602329 commit dee64a3

File tree

60 files changed

+1759
-0
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

60 files changed

+1759
-0
lines changed

‎controls/C-0278-minimizeaccesstocreatepv.json

+29
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
{
2+
"name": "Minimize access to create persistent volumes",
3+
"controlID": "C-0278",
4+
"description": "The ability to create persistent volumes in a cluster can provide an opportunity for privilege escalation, via the creation of hostPath volumes. ",
5+
"long_description": "The ability to create persistent volumes in a cluster can provide an opportunity for privilege escalation, via the creation of hostPath volumes. As persistent volumes are not covered by Pod Security Admission, a user with access to create persistent volumes may be able to get access to sensitive files from the underlying host even where restrictive Pod Security Admission policies are in place.",
6+
"remediation": "Where possible, remove `create` access to `persistentvolume` objects in the cluster.",
7+
"manual_test": "Review the users who have create access to persistentvolume objects in the Kubernetes API.",
8+
"test": "Check which subjects have RBAC permissions to create persistentvolumes.",
9+
"references": [
10+
"https://workbench.cisecurity.org/sections/2633388/recommendations/4261959"
11+
],
12+
"attributes": {
13+
},
14+
"rulesNames": [
15+
"rule-can-create-pv"
16+
],
17+
"baseScore": 5,
18+
"impact_statement": "Care should be taken not to remove access to pods to system components which require this for their operation",
19+
"category": {
20+
"name" : "Access control"
21+
},
22+
"default_value": "By default in a kubeadm cluster the following list of principals have `create` privileges on `persistentvolume` objects ```CLUSTERROLEBINDING SUBJECT TYPE SA-NAMESPACEcluster-admin system:masters Group system:controller:clusterrole-aggregation-controller clusterrole-aggregation-controller ServiceAccount kube-systemsystem:controller:daemon-set-controller daemon-set-controller ServiceAccount kube-systemsystem:controller:job-controller job-controller ServiceAccount kube-systemsystem:controller:persistent-volume-binder persistent-volume-binder ServiceAccount kube-systemsystem:controller:replicaset-controller replicaset-controller ServiceAccount kube-systemsystem:controller:replication-controller replication-controller ServiceAccount kube-systemsystem:controller:statefulset-controller statefulset-controller ServiceAccount kube-system```",
23+
"scanningScope": {
24+
"matches": [
25+
"cluster",
26+
"file"
27+
]
28+
}
29+
}

‎controls/C-0279-minimizeaccesstonodeproxy.json

+29
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
{
2+
"name": "Minimize access to the proxy sub-resource of nodes",
3+
"controlID": "C-0279",
4+
"description": "Users with access to the Proxy sub-resource of Node objects automatically have permissions to use the Kubelet API, which may allow for privilege escalation or bypass cluster security controls such as audit logs.",
5+
"long_description": "Users with access to the Proxy sub-resource of Node objects automatically have permissions to use the Kubelet API, which may allow for privilege escalation or bypass cluster security controls such as audit logs. The Kubelet provides an API which includes rights to execute commands in any container running on the node. Access to this API is covered by permissions to the main Kubernetes API via the node object. The proxy sub-resource specifically allows wide ranging access to the Kubelet API. Direct access to the Kubelet API bypasses controls like audit logging (there is no audit log of Kubelet API access) and admission control.",
6+
"remediation": "Where possible, remove access to the proxy sub-resource of node objects.",
7+
"manual_test": "Review the users who have access to the proxy sub-resource of node objects in the Kubernetes API.",
8+
"test": "Check which subjects have RBAC permissions to access the proxy sub-resource of node objects.",
9+
"references": [
10+
"https://workbench.cisecurity.org/sections/2633388/recommendations/4261961"
11+
],
12+
"attributes": {
13+
},
14+
"rulesNames": [
15+
"rule-can-access-proxy-subresource"
16+
],
17+
"baseScore": 5,
18+
"impact_statement": "Users with access to the proxy sub-resource of node objects automatically have permissions to use the Kubelet API, which may allow for privilege escalation or bypass cluster security controls such as audit logs.",
19+
"category": {
20+
"name" : "Access control"
21+
},
22+
"default_value": "By default in a kubeadm cluster the following list of principals have `create` privileges on `node/proxy` objects ```CLUSTERROLEBINDING SUBJECT TYPE SA-NAMESPACEcluster-admin system:masters Group system:controller:clusterrole-aggregation-controller clusterrole-aggregation-controller ServiceAccount kube-systemsystem:controller:daemon-set-controller daemon-set-controller ServiceAccount kube-systemsystem:controller:job-controller job-controller ServiceAccount kube-systemsystem:controller:persistent-volume-binder persistent-volume-binder ServiceAccount kube-systemsystem:controller:replicaset-controller replicaset-controller ServiceAccount kube-systemsystem:controller:replication-controller replication-controller ServiceAccount kube-systemsystem:controller:statefulset-controller statefulset-controller ServiceAccount kube-system```",
23+
"scanningScope": {
24+
"matches": [
25+
"cluster",
26+
"file"
27+
]
28+
}
29+
}

‎controls/C-0280-minimizeaccesstocertsigningreq.json

+29
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
{
2+
"name": "Minimize access to the approval sub-resource of certificatesigningrequests objects",
3+
"controlID": "C-0280",
4+
"description": "Users with access to the update the approval sub-resource of certificateaigningrequests objects can approve new client certificates for the Kubernetes API effectively allowing them to create new high-privileged user accounts.",
5+
"long_description": "Users with access to the update the approval sub-resource of certificateaigningrequests objects can approve new client certificates for the Kubernetes API effectively allowing them to create new high-privileged user accounts. This can allow for privilege escalation to full cluster administrator, depending on users configured in the cluster",
6+
"remediation": "Where possible, remove access to the approval sub-resource of certificatesigningrequests objects.",
7+
"manual_test": "Review the users who have access to update the approval sub-resource of certificatesigningrequests objects in the Kubernetes API.",
8+
"test": "Check which subjects have RBAC permissions to update the approval sub-resource of certificatesigningrequests objects.",
9+
"references": [
10+
"https://workbench.cisecurity.org/sections/2633388/recommendations/4261962"
11+
],
12+
"attributes": {
13+
},
14+
"rulesNames": [
15+
"rule-can-approve-certsigningreq"
16+
],
17+
"baseScore": 5,
18+
"impact_statement": "Users with access to the approval sub-resource of certificatesigningrequests objects can approve new client certificates for the Kubernetes API effectively allowing them to create new high-privileged user accounts.",
19+
"category": {
20+
"name" : "Access control"
21+
},
22+
"default_value": "By default in a kubeadm cluster the following list of principals have `update` privileges on `certificatesigningrequests/approval` objects ```CLUSTERROLEBINDING SUBJECT TYPE SA-NAMESPACEcluster-admin system:masters Group system:controller:clusterrole-aggregation-controller clusterrole-aggregation-controller ServiceAccount kube-systemsystem:controller:daemon-set-controller daemon-set-controller ServiceAccount kube-systemsystem:controller:job-controller job-controller ServiceAccount kube-systemsystem:controller:persistent-volume-binder persistent-volume-binder ServiceAccount kube-systemsystem:controller:replicaset-controller replicaset-controller ServiceAccount kube-systemsystem:controller:replication-controller replication-controller ServiceAccount kube-systemsystem:controller:statefulset-controller statefulset-controller ServiceAccount kube-system```",
23+
"scanningScope": {
24+
"matches": [
25+
"cluster",
26+
"file"
27+
]
28+
}
29+
}

‎controls/C-0281-minimizeaccesstoadmissionwebhook.json

+29
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
{
2+
"name": "Minimize access to webhook configuration objects",
3+
"controlID": "C-0281",
4+
"description": "Users with rights to create/modify/delete validatingwebhookconfigurations or mutatingwebhookconfigurations can control webhooks that can read any object admitted to the cluster, and in the case of mutating webhooks, also mutate admitted objects. This could allow for privilege escalation or disruption of the operation of the cluster.",
5+
"long_description": "Users with rights to create/modify/delete validatingwebhookconfigurations or mutatingwebhookconfigurations can control webhooks that can read any object admitted to the cluster, and in the case of mutating webhooks, also mutate admitted objects. This could allow for privilege escalation or disruption of the operation of the cluster.",
6+
"remediation": "Where possible, remove access to the validatingwebhookconfigurations or mutatingwebhookconfigurations objects",
7+
"manual_test": "Review the users who have access to validatingwebhookconfigurations or mutatingwebhookconfigurations objects in the Kubernetes API.",
8+
"test": "Check which subjects have RBAC permissions to create/modify/delete validatingwebhookconfigurations or mutatingwebhookconfigurations objects.",
9+
"references": [
10+
"https://workbench.cisecurity.org/sections/2633388/recommendations/4261963"
11+
],
12+
"attributes": {
13+
},
14+
"rulesNames": [
15+
"rule-can-modify-admission-webhooks"
16+
],
17+
"baseScore": 5,
18+
"impact_statement": "Users with rights to create/modify/delete validatingwebhookconfigurations or mutatingwebhookconfigurations can control webhooks that can read any object admitted to the cluster, and in the case of mutating webhooks, also mutate admitted objects. This could allow for privilege escalation or disruption of the operation of the cluster.",
19+
"category": {
20+
"name" : "Access control"
21+
},
22+
"default_value": "By default in a kubeadm cluster the following list of principals have `create/modify/delete` privileges on `validatingwebhookconfigurations/mutatingwebhookconfigurations` objects ```CLUSTERROLEBINDING SUBJECT TYPE SA-NAMESPACEcluster-admin system:masters Group system:controller:clusterrole-aggregation-controller clusterrole-aggregation-controller ServiceAccount kube-systemsystem:controller:daemon-set-controller daemon-set-controller ServiceAccount kube-systemsystem:controller:job-controller job-controller ServiceAccount kube-systemsystem:controller:persistent-volume-binder persistent-volume-binder ServiceAccount kube-systemsystem:controller:replicaset-controller replicaset-controller ServiceAccount kube-systemsystem:controller:replication-controller replication-controller ServiceAccount kube-systemsystem:controller:statefulset-controller statefulset-controller ServiceAccount kube-system```",
23+
"scanningScope": {
24+
"matches": [
25+
"cluster",
26+
"file"
27+
]
28+
}
29+
}

‎controls/C-0282-minimizeaccesstoserviceaccountcreate.json

+29
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
{
2+
"name": "Minimize access to the service account token creation",
3+
"controlID": "C-0282",
4+
"description": "Users with rights to create new service account tokens at a cluster level, can create long-lived privileged credentials in the cluster. This could allow for privilege escalation and persistent access to the cluster, even if the users account has been revoked.",
5+
"long_description": "Users with rights to create new service account tokens at a cluster level, can create long-lived privileged credentials in the cluster. This could allow for privilege escalation and persistent access to the cluster, even if the users account has been revoked.",
6+
"remediation": "Where possible, remove access to the token sub-resource of serviceaccount objects.",
7+
"manual_test": "Review the users who have access to create the token sub-resource of serviceaccount objects in the Kubernetes API.",
8+
"test": "Check which subjects have RBAC permissions to create the token sub-resource of serviceaccount objects.",
9+
"references": [
10+
"https://workbench.cisecurity.org/sections/2633388/recommendations/4261965"
11+
],
12+
"attributes": {
13+
},
14+
"rulesNames": [
15+
"rule-can-create-service-account-token"
16+
],
17+
"baseScore": 5,
18+
"impact_statement": "Users with rights to create new service account tokens at a cluster level, can create long-lived privileged credentials in the cluster. This could allow for privilege escalation and persistent access to the cluster, even if the users account has been revoked.",
19+
"category": {
20+
"name" : "Access control"
21+
},
22+
"default_value": "By default in a kubeadm cluster the following list of principals have `create` privileges on `serviceaccount/token` objects ```CLUSTERROLEBINDING SUBJECT TYPE SA-NAMESPACEcluster-admin system:masters Group system:controller:clusterrole-aggregation-controller clusterrole-aggregation-controller ServiceAccount kube-systemsystem:controller:daemon-set-controller daemon-set-controller ServiceAccount kube-systemsystem:controller:job-controller job-controller ServiceAccount kube-systemsystem:controller:persistent-volume-binder persistent-volume-binder ServiceAccount kube-systemsystem:controller:replicaset-controller replicaset-controller ServiceAccount kube-systemsystem:controller:replication-controller replication-controller ServiceAccount kube-systemsystem:controller:statefulset-controller statefulset-controller ServiceAccount kube-system```",
23+
"scanningScope": {
24+
"matches": [
25+
"cluster",
26+
"file"
27+
]
28+
}
29+
}

‎rules/rule-can-access-proxy-subresource/raw.rego

+66
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,66 @@
1+
package armo_builtins
2+
3+
import future.keywords.in
4+
5+
# fails if user has access to proxy subresources
6+
deny[msga] {
7+
subjectVector := input[_]
8+
role := subjectVector.relatedObjects[i]
9+
rolebinding := subjectVector.relatedObjects[j]
10+
endswith(role.kind, "Role")
11+
endswith(rolebinding.kind, "Binding")
12+
13+
rule := role.rules[p]
14+
15+
subject := rolebinding.subjects[k]
16+
is_same_subjects(subjectVector, subject)
17+
18+
is_same_subjects(subjectVector, subject)
19+
rule_path := sprintf("relatedObjects[%d].rules[%d]", [i, p])
20+
21+
verbs := ["get", "create", "connect","*"]
22+
verb_path := [sprintf("%s.verbs[%d]", [rule_path, l]) | verb = rule.verbs[l]; verb in verbs]
23+
count(verb_path) > 0
24+
25+
api_groups := ["", "*"]
26+
api_groups_path := [sprintf("%s.apiGroups[%d]", [rule_path, a]) | apiGroup = rule.apiGroups[a]; apiGroup in api_groups]
27+
count(api_groups_path) > 0
28+
29+
resources := ["nodes/proxy", "*"]
30+
resources_path := [sprintf("%s.resources[%d]", [rule_path, l]) | resource = rule.resources[l]; resource in resources]
31+
count(resources_path) > 0
32+
33+
path := array.concat(resources_path, verb_path)
34+
path2 := array.concat(path, api_groups_path)
35+
finalpath := array.concat(path2, [
36+
sprintf("relatedObjects[%d].subjects[%d]", [j, k]),
37+
sprintf("relatedObjects[%d].roleRef.name", [j]),
38+
])
39+
40+
msga := {
41+
"alertMessage": sprintf("Subject: %s-%s can access proxy subresources", [subjectVector.kind, subjectVector.name]),
42+
"alertScore": 3,
43+
"reviewPaths": finalpath,
44+
"failedPaths": finalpath,
45+
"fixPaths": [],
46+
"packagename": "armo_builtins",
47+
"alertObject": {
48+
"k8sApiObjects": [],
49+
"externalObjects": subjectVector,
50+
},
51+
}
52+
}
53+
54+
# for service accounts
55+
is_same_subjects(subjectVector, subject) {
56+
subjectVector.kind == subject.kind
57+
subjectVector.name == subject.name
58+
subjectVector.namespace == subject.namespace
59+
}
60+
61+
# for users/ groups
62+
is_same_subjects(subjectVector, subject) {
63+
subjectVector.kind == subject.kind
64+
subjectVector.name == subject.name
65+
subjectVector.apiGroup == subject.apiGroup
66+
}

‎rules/rule-can-access-proxy-subresource/rule.metadata.json

+28
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,28 @@
1+
{
2+
"name": "rule-can-access-proxy-subresource",
3+
"attributes": {
4+
"resourcesAggregator": "subject-role-rolebinding",
5+
"useFromKubescapeVersion": "v1.0.133"
6+
},
7+
"ruleLanguage": "Rego",
8+
"match": [
9+
{
10+
"apiGroups": [
11+
"rbac.authorization.k8s.io"
12+
],
13+
"apiVersions": [
14+
"v1"
15+
],
16+
"resources": [
17+
"Role",
18+
"ClusterRole",
19+
"ClusterRoleBinding",
20+
"RoleBinding"
21+
]
22+
}
23+
],
24+
"ruleDependencies": [],
25+
"description": "determines which users can access proxy subresources",
26+
"remediation": "",
27+
"ruleQuery": "armo_builtins"
28+
}

‎rules/rule-can-access-proxy-subresource/test/clusterrole-clusterrolebinding/expected.json

+1
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
[]

‎rules/rule-can-access-proxy-subresource/test/clusterrole-clusterrolebinding/input/clusterrole.yaml

+8
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
apiVersion: rbac.authorization.k8s.io/v1
2+
kind: ClusterRole
3+
metadata:
4+
name: test
5+
rules:
6+
- apiGroups: ["rbac.authorization.k8s.io"]
7+
resources: ["pods", "rolebindings"]
8+
verbs: ["create", "watch", "list"]

‎rules/rule-can-access-proxy-subresource/test/clusterrole-clusterrolebinding/input/clusterrolebinding.yaml

+15
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,15 @@
1+
apiVersion: rbac.authorization.k8s.io/v1
2+
kind: ClusterRoleBinding
3+
metadata:
4+
name: read-secrets-global
5+
subjects:
6+
- kind: Group
7+
name: manager
8+
apiGroup: rbac.authorization.k8s.io
9+
- kind: Group
10+
name: dev
11+
apiGroup: rbac.authorization.k8s.io
12+
roleRef:
13+
kind: ClusterRole
14+
name: test
15+
apiGroup: rbac.authorization.k8s.io

0 commit comments

Comments
 (0)