Add CIS kubernetes CIS-1.9 for k8s v1.27 - v1.29 #1617
Conversation
andypitcher
force-pushed
the
cis-1.9
branch
2 times, most recently
from
4f244d5
to
05c45a6
Compare
- policies.yaml
- 5.1.1 to 5.1.6 were adapted from Manual to Automated
- 5.1.3 got broken down into 5.1.3.1 and 5.1.3.2
- 5.1.6 got broken down into 5.1.6.1 and 5.1.6.2
- version was set to cis-1.9
- node.yaml master.yaml controlplane.yaml etcd.yaml
- version was set to cis-1.9
| Modify the configuration of each default service account to include this value | ||
| `automountServiceAccountToken: false`. | ||
| scored: true | ||
| - id: 5.1.6.1 |
There was a problem hiding this comment.
| - id: 5.1.6.1 | |
| - id: 5.1.6 |
There was a problem hiding this comment.
This is the same approach I've used for 5.1.3, since 5.1.6 was complex to satisfy with only one check so I used the Artifacts as baseline. More details in the PR description.
- 5.1.6.1 Ensure that Service Account Tokens are only mounted where necessary - ServiceAccount (Automated)
- 5.1.6.2 Ensure that Service Account Tokens are only mounted where necessary - Pods (Automated)
| remediation: | | ||
| Where possible, remove get, list and watch access to Secret objects in the cluster. | ||
| scored: true | ||
| - id: 5.1.3.1 |
There was a problem hiding this comment.
| - id: 5.1.3.1 | |
| - id: 5.1.3 |
There was a problem hiding this comment.
As mentioned in the PR description, I chose to split 5.1.3 into two other checks (5.1.3.1 and 5.1.3.2) that are the referenced artifacts in CIS Workbench. This gives more accuracy and reduce the complexity of having to test 5.1.3.1 and 5.1.3.2 within the same check.
To make sure we keep the same references, I've added a Parent: 5.1.3 in the remediation.
Here are the details:
WDYT ?
There was a problem hiding this comment.
IMHO, we should follow the CIS benchmark, don't split the remediation in this version. As you can see, both 5.1.3.1 and 5.1.3.2 are draft.
- This may break downstream.
- We may have to explain it to everyone who has questions about this.
@chen-keinan WDYT?
There was a problem hiding this comment.
I agree , CIS benchmark should be the exact guide to follow to avoid breaking changes
There was a problem hiding this comment.
Ok, I will see how I can adapt the 5.1.3 and 5.1.6 checks, and propose a new version.
- Expand 1.1.13/1.1.14 checks by adding super-admin.conf to the permission and ownership verification
- Remove 1.2.12 Ensure that the admission control plugin SecurityContextDeny is set if PodSecurityPolicy is not used (Manual)
- Adjust numbering from 1.2.12 to 1.2.29
- Check 5.2.3 to 5.2.9 Title Automated to Manual
- Create 4.3 kube-config group - Create 4.3.1 Ensure that the kube-proxy metrics service is bound to localhost (Automated)
@mozillazg Thanks for your review, I've used what was written in the CIS-1.9 PDF under ChangeLog initially. This makes me think that not every changes have been listed out, so thanks for bringing up the other places that needed some modifications. I've made some changes and comments based on your review, let me know WDYT ? One other thing: |
Parent issue:
CIS Kubernetes Benchmark CIS-1.9
CIS Workbench: https://workbench.cisecurity.org/benchmarks/16828
K8s version: v1.27 to v1.29
Changelog details in CIS Workbench:
All the checks remain the same as CIS-1.8, only these were changed:
Pull request details
created cfg/cis-1.9
policies.yaml
node.yaml master.yaml controlplane.yaml etcd.yaml
master.yaml
Added CIS-1.9 to the global configmap and docs/
Set go-linter version from
latesttov1.57.2as per 86a42b5Description of
policies.yamlchangesNote:
kubectlneeds to be added to kube-bench's Dockerfile (and other needed places).5.1.1 Ensure that the cluster-admin role is only used where required (Automated)
Test details: https://workbench.cisecurity.org/sections/2493119/recommendations/4022566
Change from previous version: Manual to Automated
Test: Retrieves all clusterrolebindings role names and subject available and look for cluster-admin role.
Condition: is_compliant is false (FAIL) if rolename is not cluster-admin and rolebinding is cluster-admin. cluster-admin role is not meant to fail since it's a default role.
FAIL
(For explanation purpose, the following check was set with one
role_name: role-test-1only)PASS
(For explanation purpose, the following check was set with one
role_name: cluster-adminonly)5.1.2 Minimize access to secrets (Automated)
Test details: https://workbench.cisecurity.org/sections/2493119/recommendations/4022567
Change from previous version: Manual to Automated
Test:
kubectl auth can-i get,list,watch secrets --all-namespaces --as=system:authenticated.Condition: PASS when flag
canGetListWatchSecretsAsSystemAuthenticatedisno.PASS
5.1.3 Minimize wildcard use in Roles and ClusterRoles (Automated)
Test details: https://workbench.cisecurity.org/sections/2493119/recommendations/4022568
Change from previous version: Manual to Automated
** Note: Broken down into 2 checks 5.1.3.1 and 5.1.3.2 to facilitate the analysis of 5.1.3 (Both are documented Artifacts in 5.1.3).
5.1.3.1 Minimize wildcard use in ClusterRoles (Automated)
Test: Retrieves all roles along with their respective rules.
Condition: is_compliant is false (FAIL) if ["*"] is found in rules (includes verbs, resources etc).
FAIL
(For explanation purpose, the following check was set with one
namespace: mynamespace-system. Default runs against --all-namespaces.)PASS
(For explanation purpose, the following check was set on
namespace: kube-system. Default runs against --all-namespaces.)5.1.3.2 Minimize wildcard use in ClusterRoles (Automated)
Test: Retrieves all clusterroles along with their respective rules.
Condition: is_compliant is false (FAIL) if ["*"] is found in rules (includes verbs, resources etc).
FAIL
(For explanation purpose, the following check was set on
clusterrole: system:kubelet-api-admin. Default runs against all clusterroles.)PASS
(For explanation purpose, the following check was set with on
clusterrole: view. Default runs against all clusterroles.)5.1.4 Minimize access to create pods (Automated)
Test details: https://workbench.cisecurity.org/sections/2493119/recommendations/4022569
Change from previous version: Manual to Automated
Test:
kubectl auth can-i create pods --all-namespaces --as=system:authenticated.Condition: PASS when flag
canCreatePodsAsSystemAuthenticatedisno.PASS
5.1.5 Ensure that default service accounts are not actively used (Automated)
Test details: https://workbench.cisecurity.org/sections/2493119/recommendations/4022570
Change from previous version: Manual to Automated
Test: Retrieves all
defaultserviceaccount and search forautomountServiceAccountTokenpresence and value.Condition: FAIL if
automountServiceAccountTokenisnotsetOR istrue. Note: To make it more comprehensiblenotsetis a substitution when the value returned isnullor<none>.FAIL
(For explanation purpose, the following check was set with one
namespace: kube-system. Default runs against --all-namespaces.)PASS
(For explanation purpose, the following check was set with one
namespace: mynamespace-system. Default runs against --all-namespaces.)5.1.6 Ensure that Service Account Tokens are only mounted where necessary (Automated)
Test details: https://workbench.cisecurity.org/sections/2493119/recommendations/4022571
Change from previous version: Manual to Automated
** Note: Broken down into 2 checks 5.1.6.1 and 5.1.6.2 to facilitate the analysis of 5.1.6 (Both are documented Artifacts in 5.1.6).
5.1.6.1 Ensure that Service Account Tokens are only mounted where necessary - ServiceAccount (Automated)
Test: Retrieves all
defaultserviceaccount and search forautomountServiceAccountTokenpresence and value.Condition: FAIL if
automountServiceAccountTokenisnotsetOR istrue. Note: To make it more comprehensiblenotsetis a substitution when the value returned isnullor<none>.FAIL
(For explanation purpose, the following the check was set with one
namespace: mynamespace-system. Default runs against --all-namespaces.)mynamespace-systemhas two serviceaccounts (default that is compliant becauseautomountServiceAccountToken: falsebut svctest is not becauseautomountServiceAccountToken:notset )PASS
(For explanation purpose, the following the check was set with one
namespace: mynamespace-system. Default runs against --all-namespaces.)mynamespace-systemhas two serviceaccounts default and svctest that are both compliant becauseautomountServiceAccountToken: false. Thesvctestwas made compliant by settingautomountServiceAccountToken: falseand applying (ref FAIL above).5.1.6.2 Ensure that Service Account Tokens are only mounted where necessary - Pods (Automated)
Note: This check has been improved by using more context, based on k8s doc
If both the ServiceAccount and the Pod's .spec specify a value for automountServiceAccountToken, the Pod spec takes precedence.Test: Retrieves all Pods and search for
automountServiceAccountTokenpresence and value. Then compare with their use of a ServiceAccount ( and if the said ServiceAccount usesautomountServiceAccountToken).Condition: Pod is_compliant to true when
- ServiceAccount is automountServiceAccountToken: false and Pod is automountServiceAccountToken: false or notset
- ServiceAccount is automountServiceAccountToken: true notset and Pod is automountServiceAccountToken: false
FAIL
(For explanation purpose, the following check was set with one
namespace: mynamespace-system. Default runs against --all-namespaces.)PASS
(For explanation purpose, the following check was set with one
namespace: mynamespace-system. Default runs against --all-namespaces.)Description of
master.yamlchanges1.1.13 Ensure that the default administrative credential file permissions are set to 600 (Automated)
Test details: https://workbench.cisecurity.org/sections/2493110/recommendations/4022542
Note: This check has been adapted since 1.9 to verify admin.conf and super-admin.conf. 1.1.13 will fail if neither of admin.conf and super-admin.conf are present.
Test: Retrieves file permissions of /etc/kubernetes/admin.conf and /etc/kubernetes/super-admin.conf, use
multiple_values: true.Condition: File permissions should be
600for both files (if super-admin.conf is present - the case in k8s 1.29+)FAIL
(In case of k8s 1.29+ where the 2 files are present)
PASS
(In case of k8s 1.29+ where the 2 files are present)
FAIL
(In case of k8s older than 1.29 where only
admin.confis present and is640)PASS
(In case of k8s older than 1.29 where only admin.conf is present and is 600)
1.1.14 Ensure that the default administrative credential file ownership is set to root:root (Automated)
Test details: https://workbench.cisecurity.org/sections/2493110/recommendations/4022546
Note:
root:roothas been replaced withownership, this works and is more clean. We could adapt all related checks with this format now.Test: Retrieves file ownerships of /etc/kubernetes/admin.conf and /etc/kubernetes/super-admin.conf, use
multiple_values: true.Condition: File ownership should be
root:rootfor both files (if super-admin.conf is present - the case in k8s 1.29+)FAIL:
(In case of k8s 1.29+ where the 2 files are present - admin.conf has been set to nobody:nobody on purpose)
PASS
(In case of k8s 1.29+ where the 2 files are present)
Description of
node.yamlchanges4.3.1 Ensure that the kube-proxy metrics service is bound to localhost (Automated)
Test details: https://workbench.cisecurity.org/sections/2535189/recommendations/4095050
Test: Retrieves kube-proxy process definition along with kubeproxyconf, to look for
--metrics-bind-addressormetricsBindAddressvalue.Condition: Metrics bind address, if present, should be bound to a localhost IP address to reduce the exposition of sensitive info. The default conf is 127.0.0.1:10249.