1
0
mirror of https://github.com/aquasecurity/kube-bench.git synced 2024-11-24 08:58:11 +00:00

Update aks-1.0 to match official CIS Azure Kubernetes Service (AKS) Benchmark v1.0.0 (#1042)

* Update aks-1.0 to match official CIS Azure Kubernetes Service (AKS) Benchmark v1.0.0

* fix typo

* fix empty remediation

Co-authored-by: Yoav Rotem <yoavrotems97@gmail.com>
This commit is contained in:
Huang Huang 2021-11-14 21:37:54 +08:00 committed by GitHub
parent 900d248650
commit f8e0171c09
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
5 changed files with 191 additions and 474 deletions

View File

@ -6,26 +6,26 @@ text: "Control Plane Configuration"
type: "controlplane"
groups:
- id: 2.1
text: "Authentication and Authorization"
checks:
- id: 2.1.1
text: "Enable Azure Active Directory Integration"
type: "manual"
remediation: |
Use of OIDC should be implemented in place of client certificates. Cluster administrators can configure Kubernetes role-based access control (RBAC) based on a user's identity or directory group membership. Azure AD authentication is provided to AKS clusters with OpenID Connect. See https://docs.microsoft.com/en-us/azure/aks/managed-aad.
scored: false
- id: 2.1.2
text: "Limit access to cluster configuration file"
type: "manual"
remediation: |
Use Azure role-based access control to define access to the Kubernetes configuration file in Azure Kubernetes Service (AKS). See https://docs.microsoft.com/en-us/azure/aks/control-kubeconfig-access
scored: false
- id: 2.2
text: "Logging"
checks:
- id: 2.2.1
text: "Enable logging for the Kubernetes master components"
- id: 2.1.1
text: "Enable audit Logs"
type: "manual"
remediation: "Enable log collection for the Kubernetes master components in the AKS cluster using Diagnostic settings."
remediation: |
Azure audit logs are enabled and managed in the Azure portal. To enable log collection for
the Kubernetes master components in your AKS cluster, open the Azure portal in a web
browser and complete the following steps:
1. Select the resource group for your AKS cluster, such as myResourceGroup. Don't
select the resource group that contains your individual AKS cluster resources, such
as MC_myResourceGroup_myAKSCluster_eastus.
2. On the left-hand side, choose Diagnostic settings.
3. Select your AKS cluster, such as myAKSCluster, then choose to Add diagnostic setting.
4. Enter a name, such as myAKSClusterLogs, then select the option to Send to Log Analytics.
5. Select an existing workspace or create a new one. If you create a workspace, provide
a workspace name, a resource group, and a location.
6. In the list of available logs, select the logs you wish to enable. For this example,
enable the kube-audit and kube-audit-admin logs. Common logs include the kube-
apiserver, kube-controller-manager, and kube-scheduler. You can return and change
the collected logs once Log Analytics workspaces are enabled.
7. When ready, select Save to enable collection of the selected logs.
scored: false

View File

@ -9,247 +9,136 @@ groups:
text: "Image Registry and Image Scanning"
checks:
- id: 5.1.1
text: "Ensure Image Vulnerability Scanning"
text: "Ensure Image Vulnerability Scanning using Azure Defender image scanning or a third party provider (Manual)"
type: "manual"
remediation: |
Scan your container images for vulnerabilities, and only deploy images that have passed validation. Regularly update the base images and application runtime, then redeploy workloads in the AKS cluster. Deployment workflow should include a process to scan container images using tools such as Twistlock or Aqua, and then only allow verified images to be deployed.
remediation: "No remediation"
scored: false
- id: 5.1.2
text: "Minimize user access to ACR"
text: "Minimize user access to Azure Container Registry (ACR) (Manual)"
type: "manual"
remediation: |
Use Azure AD and RBAC to minimize user access to ACR. For each Azure container registry, track whether the built-in admin account is enabled or disabled. Disable the account when not in use. See https://docs.microsoft.com/en-us/azure/container-registry/security-baseline#identity-and-access-control.
Azure Container Registry
If you use Azure Container Registry (ACR) as your container image store, you need to grant
permissions to the service principal for your AKS cluster to read and pull images. Currently,
the recommended configuration is to use the az aks create or az aks update command to
integrate with a registry and assign the appropriate role for the service principal. For
detailed steps, see Authenticate with Azure Container Registry from Azure Kubernetes
Service.
To avoid needing an Owner or Azure account administrator role, you can configure a
service principal manually or use an existing service principal to authenticate ACR from
AKS. For more information, see ACR authentication with service principals or Authenticate
from Kubernetes with a pull secret.
scored: false
- id: 5.1.3
text: "Minimize cluster access to read-only for ACR"
text: "Minimize cluster access to read-only for Azure Container Registry (ACR) (Manual)"
type: "manual"
remediation: |
Ensure identity assigned to AKS uses read-only role for accessing ACR.
remediation: "No remediation"
scored: false
- id: 5.1.4
text: "Protect ACR using NSGs or Azure Firewall on your Virtual Network"
text: "Minimize Container Registries to only those approved (Manual)"
type: "manual"
remediation: |
Restrict access to an Azure container registry using an Azure virtual network or firewall rules. Configure rules to access an Azure container registry behind a firewall. See https://docs.microsoft.com/en-us/azure/container-registry/security-baseline#11-protect-resources-using-network-security-groups-or-azure-firewall-on-your-virtual-network
scored: false
- id: 5.1.5
text: "Record network packets and flow logs for ACR"
type: "manual"
remediation: |
Enable network security group (NSG) flow logs for the NSG attached to the subnet being used to protect your Azure container registry. See https://docs.microsoft.com/en-us/azure/container-registry/security-baseline#15-record-network-packets-and-flow-logs
scored: false
- id: 5.1.6
text: "Minimize complexity and administrative overhead of network security rules for ACR"
type: "manual"
remediation: |
For resources that need access to your container registry, use virtual network service tags (instead of specific IP addresses) for the Azure Container Registry service (service tag name "AzureContainerRegistry") to define network access controls on Network Security Groups or Azure Firewall. See https://docs.microsoft.com/en-us/azure/container-registry/security-baseline#18-minimize-complexity-and-administrative-overhead-of-network-security-rules
scored: false
- id: 5.1.7
text: "Configure central security log management for ACR"
type: "manual"
remediation: |
Ingest logs via Azure Monitor to aggregate security data generated by an Azure container registry. https://docs.microsoft.com/en-us/azure/container-registry/security-baseline#22-configure-central-security-log-management
scored: false
- id: 5.1.8
text: "Enable audit logging for ACR"
type: "manual"
remediation: |
Collect and consume this data to audit registry authentication events and provide a complete activity trail on registry artifacts such as pull and push events so you can diagnose security issues with your registry. See https://docs.microsoft.com/en-us/azure/container-registry/security-baseline#23-enable-audit-logging-for-azure-resources
scored: false
- id: 5.1.9
text: "Change default passwords for ACR where applicable"
type: "manual"
remediation: |
If the default admin account of an Azure container registry is enabled, complex passwords are automatically created and should be rotated. Disable the account when not in use. See https://docs.microsoft.com/en-us/azure/container-registry/security-baseline#32-change-default-passwords-where-applicable
scored: false
- id: 5.1.10
text: "Use dedicated administrative accounts"
type: "manual"
remediation: |
Create standard operating procedures around the use of dedicated administrative accounts. Use Azure Security Center Identity and Access Management to monitor the number of administrative accounts. See https://docs.microsoft.com/en-us/azure/container-registry/security-baseline#33-use-dedicated-administrative-accounts
scored: false
- id: 5.1.11
text: "Use single sign-on (SSO) with Azure Active Directory"
type: "manual"
remediation: |
Wherever possible, use Azure Active Directory SSO instead of configuring individual stand-alone credentials per-service. See https://docs.microsoft.com/en-us/azure/container-registry/security-baseline#34-use-single-sign-on-sso-with-azure-active-directory
scored: false
- id: 5.1.12
text: "Maintain an inventory of sensitive Information"
type: "manual"
remediation: |
Use resource tags to assist in tracking Azure container registries that store or process sensitive information. See https://docs.microsoft.com/en-us/azure/container-registry/security-baseline#41-maintain-an-inventory-of-sensitive-information
scored: false
- id: 5.1.13
text: "Isolate systems storing or processing sensitive information"
type: "manual"
remediation: |
Implement separate container registries, subscriptions, and/or management groups for development, test, and production. Resources storing or processing sensitive data should be sufficiently isolated. See https://docs.microsoft.com/en-us/azure/container-registry/security-baseline#42-isolate-systems-storing-or-processing-sensitive-information
scored: false
- id: 5.1.14
text: "Encrypt all sensitive information in transit to ACR"
type: "manual"
remediation: |
Ensure that any clients connecting to your Azure Container Registry are able to negotiate TLS 1.2 or greater. See https://docs.microsoft.com/en-us/azure/container-registry/security-baseline#44-encrypt-all-sensitive-information-in-transit
scored: false
- id: 5.1.15
text: "Use Azure RBAC to control access to resources in ACR"
type: "manual"
remediation: |
Use Azure role-based access control (Azure RBAC) to control access to data and resources in an Azure container registry. See https://docs.microsoft.com/en-us/azure/container-registry/security-baseline#46-use-azure-rbac-to-control-access-to-resources
scored: false
- id: 5.1.16
text: "Encrypt sensitive information at rest in ACR"
type: "manual"
remediation: |
Use encryption at rest on all Azure resources. By default, all data in an Azure container registry is encrypted at rest using Microsoft-managed keys. See https://docs.microsoft.com/en-us/azure/container-registry/security-baseline#48-encrypt-sensitive-information-at-rest
scored: false
- id: 5.1.17
text: "Ensure regular automated back ups for ACR"
type: "manual"
remediation: |
he data in your Microsoft Azure container registry is always automatically replicated to ensure durability and high availability. Optionally geo-replicate a container registry to maintain registry replicas in multiple Azure regions. See https://docs.microsoft.com/en-us/azure/container-registry/security-baseline#91-ensure-regular-automated-back-ups
remediation: "No remediation"
scored: false
- id: 5.2
text: "Identity and Access Management (IAM)"
text: "Access and identity options for Azure Kubernetes Service (AKS)"
checks:
- id: 5.2.1
text: "Use managed identities in Azure Kubernetes Service"
text: "Prefer using dedicated AKS Service Accounts (Manual)"
type: "manual"
remediation: |
Use SystemAssigned managed identity for AKS cluster. See https://docs.microsoft.com/en-us/azure/aks/use-managed-identity
scored: false
- id: 5.2.2
text: "Prefer using AAD Pod Identity"
type: "manual"
remediation: |
AAD Pod Identity enables Kubernetes applications to access cloud resources securely with Azure Active Directory (AAD). See https://github.com/Azure/aad-pod-identity
Azure Active Directory integration
The security of AKS clusters can be enhanced with the integration of Azure Active Directory
(AD). Built on decades of enterprise identity management, Azure AD is a multi-tenant,
cloud-based directory, and identity management service that combines core directory
services, application access management, and identity protection. With Azure AD, you can
integrate on-premises identities into AKS clusters to provide a single source for account
management and security.
Azure Active Directory integration with AKS clusters
With Azure AD-integrated AKS clusters, you can grant users or groups access to Kubernetes
resources within a namespace or across the cluster. To obtain a kubectl configuration
context, a user can run the az aks get-credentials command. When a user then interacts
with the AKS cluster with kubectl, they're prompted to sign in with their Azure AD
credentials. This approach provides a single source for user account management and
password credentials. The user can only access the resources as defined by the cluster
administrator.
Azure AD authentication is provided to AKS clusters with OpenID Connect. OpenID Connect
is an identity layer built on top of the OAuth 2.0 protocol. For more information on OpenID
Connect, see the Open ID connect documentation. From inside of the Kubernetes cluster,
Webhook Token Authentication is used to verify authentication tokens. Webhook token
authentication is configured and managed as part of the AKS cluster.
scored: false
- id: 5.3
text: "Cloud Key Management Service"
text: "Key Management Service (KMS)"
checks:
- id: 5.3.1
text: "Ensure Kubernetes Secrets are stored and retrieved from Azure Key Vault."
text: "Ensure Kubernetes Secrets are encrypted (Manual)"
type: "manual"
remediation: |
Use the Azure Key Vault with Secrets Store CSI Driver to retrieve secrets from Azure Key Vault and load it in the pod. See https://github.com/Azure/secrets-store-csi-driver-provider-azure.
remediation: "No remediation"
scored: false
- id: 5.4
text: "Cluster Networking"
checks:
- id: 5.4.1
text: "Enable NSG Flow Logs for AKS subnets."
text: "Restrict Access to the Control Plane Endpoint (Manual)"
type: "manual"
remediation: |
Enable network security group (NSG) flow logs for the NSG attached to the subnet being used for AKS cluster nodes.
remediation: "No remediation"
scored: false
- id: 5.4.2
text: "Ensure clusters are created with Private Endpoint Enabled and Public Access Disabled (Scored)"
text: "Ensure clusters are created with Private Endpoint Enabled and Public Access Disabled (Manual)"
type: "manual"
remediation: |
In a private cluster, the control plane or API server has internal IP address. See: https://docs.microsoft.com/en-us/azure/aks/private-clusters
remediation: "No remediation"
scored: false
- id: 5.4.3
text: "Configure NSG on AKS worker node subnet"
text: "Ensure clusters are created with Private Nodes (Manual)"
type: "manual"
remediation: |
Configure NSG rules on AKS worker node subnet to allow only required network traffic.
remediation: "No remediation"
scored: false
- id: 5.4.4
text: "Ensure Network Policy is Enabled and set as appropriate (Not Scored)"
text: "Ensure Network Policy is Enabled and set as appropriate (Manual)"
type: "manual"
remediation: |
Enable Azure Network Policy or Calico Network policy on the AKS cluster. See https://docs.microsoft.com/en-us/azure/aks/use-network-policies.
remediation: "No remediation"
scored: false
- id: 5.4.5
text: "Encrypt traffic to HTTPS load balancers with TLS certificates (Manual)"
type: "manual"
remediation: "No remediation"
scored: false
- id: 5.5
text: "Logging"
text: "Authentication and Authorization"
checks:
- id: 5.5.1
text: "Enable Azure Monitor for container for kubelet logs"
text: "Manage Kubernetes RBAC users with Azure AD (Manual)"
type: "manual"
remediation: |
Enable Azure Monitor for containers via AKS diagnostics settings for collecting node and kubelet logs. See https://docs.microsoft.com/en-us/azure/azure-monitor/insights/container-insights-overview
remediation: "No remediation"
scored: false
- id: 5.5.2
text: "Use Azure RBAC for Kubernetes Authorization (Manual)"
type: "manual"
remediation: "No remediation"
scored: false
- id: 5.6
text: "Authentication and Authorization"
checks:
- id: 5.6.1
text: "Use Azure RBAC for Kubernetes Authorization"
type: "manual"
remediation: |
Enabling Azure RBAC for Kubernetes Authorization will use a Kubernetes Authorization webhook server to enable you to manage permissions and assignments of Azure AD-integrated K8s cluster resources using Azure role definition and role assignments. See https://docs.microsoft.com/en-us/azure/aks/manage-azure-rbac
scored: false
- id: 5.6.2
text: "Use Kubernetes RBAC with Azure AD integration"
type: "manual"
remediation: |
Don't use fixed credentials within pods or container images, as they are at risk of exposure or abuse. Instead, use pod identities to automatically request access to other Azure resources using a central Azure AD identity solution. See https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity#use-pod-identities
scored: false
- id: 5.6.3
text: "Use pod identities"
type: "manual"
remediation: |
Control access to cluster resources using role-based access control and Azure Active Directory identities in Azure Kubernetes Service. See https://docs.microsoft.com/en-us/azure/aks/azure-ad-rbac
scored: false
- id: 5.7
text: "Storage"
checks:
- id: 5.7.1
text: "Enable host-based encryption"
type: "manual"
remediation: |
Enable host-based encryption on Azure Kubernetes Service (AKS). With host-based encryption, the data stored on the VM host of your AKS agent nodes' VMs is encrypted at rest and flows encrypted to the Storage service. This means the temp disks are encrypted at rest with platform-managed keys. The cache of OS and data disks is encrypted at rest with either platform-managed keys or customer-managed keys depending on the encryption type set on those disks. See https://docs.microsoft.com/en-us/azure/aks/enable-host-encryption.
scored: false
- id: 5.7.2
text: "Bring your own keys (BYOK) with Azure disks in Azure Kubernetes Service (AKS)"
type: "manual"
remediation: |
Azure Storage encrypts all data in a storage account at rest. By default, data is encrypted with Microsoft-managed keys. For additional control over encryption keys, you can supply customer-managed keys to use for encryption at rest for both the OS and data disks for your AKS clusters. See https://docs.microsoft.com/en-us/azure/aks/azure-disk-customer-managed-keys.
scored: false
- id: 5.8
text: "Other Cluster Configurations"
checks:
- id: 5.8.1
text: "Ensure Kubernetes Web UI is Disabled (Scored)"
- id: 5.6.1
text: "Restrict untrusted workloads (Manual)"
type: "manual"
remediation: |
The dashboard add-on is disabled by default for all new clusters created on Kubernetes 1.18 or greater. To disable dashboard on existing cluster use command line:
az aks disable-addons -g myRG -n myAKScluster -a kube-dashboard
remediation: "No remediation"
scored: false
- id: 5.8.2
text: "Secure pods with Azure Policy as appropriate"
- id: 5.6.2
text: "Hostile multi-tenant workloads (Manual)"
type: "manual"
remediation: |
Enable Azure Policy Add-on for AKS to control what functions pods are granted. See https://docs.microsoft.com/en-us/azure/aks/use-pod-security-on-azure-policy.
remediation: "No remediation"
scored: false

View File

@ -9,60 +9,7 @@ groups:
text: "Worker Node Configuration Files"
checks:
- id: 3.1.1
text: "Ensure that the kubelet service file permissions are set to 644 or more restrictive (Automated)"
audit: '/bin/sh -c ''if test -e $kubeletsvc; then stat -c permissions=%a $kubeletsvc; fi'' '
tests:
test_items:
- flag: "permissions"
compare:
op: bitmask
value: "644"
remediation: |
Run the below command (based on the file location on your system) on the each worker node.
For example,
chmod 644 $kubeletsvc
scored: true
- id: 3.1.2
text: "Ensure that the kubelet service file ownership is set to root:root (Automated)"
audit: '/bin/sh -c ''if test -e $kubeletsvc; then stat -c %U:%G $kubeletsvc; fi'' '
tests:
test_items:
- flag: 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 $kubeletsvc
scored: true
- id: 3.1.3
text: "If proxy kubeconfig file exists ensure permissions are set to 644 or more restrictive (Manual)"
audit: '/bin/sh -c ''if test -e $proxykubeconfig; then stat -c permissions=%a $proxykubeconfig; fi'' '
tests:
test_items:
- flag: "permissions"
compare:
op: bitmask
value: "644"
remediation: |
Run the below command (based on the file location on your system) on the each worker node.
For example,
chmod 644 $proxykubeconfig
scored: false
- id: 3.1.4
text: "Ensure that the proxy kubeconfig file ownership is set to root:root (Manual)"
audit: '/bin/sh -c ''if test -e $proxykubeconfig; then stat -c %U:%G $proxykubeconfig; fi'' '
tests:
test_items:
- flag: 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 $proxykubeconfig
scored: false
- id: 3.1.5
text: "Ensure that the --kubeconfig kubelet.conf file permissions are set to 644 or more restrictive (Automated)"
text: "Ensure that the kubeconfig file permissions are set to 644 or more restrictive (Manual)"
audit: '/bin/sh -c ''if test -e $kubeletkubeconfig; then stat -c permissions=%a $kubeletkubeconfig; fi'' '
tests:
test_items:
@ -74,10 +21,10 @@ groups:
Run the below command (based on the file location on your system) on the each worker node.
For example,
chmod 644 $kubeletkubeconfig
scored: true
scored: false
- id: 3.1.6
text: "Ensure that the --kubeconfig kubelet.conf file ownership is set to root:root (Manual)"
- id: 3.1.2
text: "Ensure that the kubelet kubeconfig file ownership is set to root:root (Manual)"
audit: '/bin/sh -c ''if test -e $kubeletkubeconfig; then stat -c %U:%G $kubeletkubeconfig; fi'' '
tests:
test_items:
@ -88,42 +35,8 @@ groups:
chown root:root $kubeletkubeconfig
scored: false
- id: 3.1.7
text: "Ensure that the certificate authorities file permissions are set to 644 or more restrictive (Manual)"
audit: |
CAFILE=$(ps -ef | grep kubelet | grep -v apiserver | grep -- --client-ca-file= | awk -F '--client-ca-file=' '{print $2}' | awk '{print $1}')
if test -z $CAFILE; then CAFILE=$kubeletcafile; fi
if test -e $CAFILE; then stat -c permissions=%a $CAFILE; fi
tests:
test_items:
- flag: "permissions"
compare:
op: bitmask
value: "644"
remediation: |
Run the following command to modify the file permissions of the
--client-ca-file chmod 644 <filename>
scored: false
- id: 3.1.8
text: "Ensure that the client certificate authorities file ownership is set to root:root (Manual)"
audit: |
CAFILE=$(ps -ef | grep kubelet | grep -v apiserver | grep -- --client-ca-file= | awk -F '--client-ca-file=' '{print $2}' | awk '{print $1}')
if test -z $CAFILE; then CAFILE=$kubeletcafile; fi
if test -e $CAFILE; then stat -c %U:%G $CAFILE; fi
tests:
test_items:
- flag: root:root
compare:
op: eq
value: root:root
remediation: |
Run the following command to modify the ownership of the --client-ca-file.
chown root:root <filename>
scored: false
- id: 3.1.9
text: "Ensure that the kubelet --config configuration file has permissions set to 644 or more restrictive (Automated)"
- id: 3.1.3
text: "Ensure that the kubelet configuration file has permissions set to 644 or more restrictive (Manual)"
audit: '/bin/sh -c ''if test -e $kubeletconf; then stat -c permissions=%a $kubeletconf; fi'' '
tests:
test_items:
@ -134,10 +47,10 @@ groups:
remediation: |
Run the following command (using the config file location identified in the Audit step)
chmod 644 $kubeletconf
scored: true
scored: false
- id: 3.1.10
text: "Ensure that the kubelet --config configuration file ownership is set to root:root (Automated)"
- id: 3.1.4
text: "Ensure that the kubelet configuration file ownership is set to root:root (Manual)"
audit: '/bin/sh -c ''if test -e $kubeletconf; then stat -c %U:%G $kubeletconf; fi'' '
tests:
test_items:
@ -145,13 +58,13 @@ groups:
remediation: |
Run the following command (using the config file location identified in the Audit step)
chown root:root $kubeletconf
scored: true
scored: false
- id: 3.2
text: "Kubelet"
checks:
- id: 3.2.1
text: "Ensure that the anonymous-auth argument is set to false (Automated)"
text: "Ensure that the --anonymous-auth argument is set to false (Manual)"
audit: "/bin/ps -fC $kubeletbin"
audit_config: "/bin/cat $kubeletconf"
tests:
@ -171,10 +84,10 @@ groups:
Based on your system, restart the kubelet service. For example:
systemctl daemon-reload
systemctl restart kubelet.service
scored: true
scored: false
- id: 3.2.2
text: "Ensure that the --authorization-mode argument is not set to AlwaysAllow (Automated)"
text: "Ensure that the --authorization-mode argument is not set to AlwaysAllow (Manual)"
audit: "/bin/ps -fC $kubeletbin"
audit_config: "/bin/cat $kubeletconf"
tests:
@ -193,16 +106,17 @@ groups:
Based on your system, restart the kubelet service. For example:
systemctl daemon-reload
systemctl restart kubelet.service
scored: true
scored: false
- id: 3.2.3
text: "Ensure that the --client-ca-file argument is set as appropriate (Automated)"
text: "Ensure that the --client-ca-file argument is set as appropriate (Manual)"
audit: "/bin/ps -fC $kubeletbin"
audit_config: "/bin/cat $kubeletconf"
tests:
test_items:
- flag: --client-ca-file
path: '{.authentication.x509.clientCAFile}'
set: true
remediation: |
If using a Kubelet config file, edit the file to set authentication: x509: clientCAFile to
the location of the client CA file.
@ -213,23 +127,20 @@ groups:
Based on your system, restart the kubelet service. For example:
systemctl daemon-reload
systemctl restart kubelet.service
scored: true
scored: false
- id: 3.2.4
text: "Ensure that the --read-only-port argument is set to 0 (Manual)"
audit: "/bin/ps -fC $kubeletbin"
audit_config: "/bin/cat $kubeletconf"
tests:
bin_op: or
test_items:
- flag: "--read-only-port"
path: '{.readOnlyPort}'
set: true
compare:
op: eq
value: 0
- flag: "--read-only-port"
path: '{.readOnlyPort}'
set: false
remediation: |
If using a Kubelet config file, edit the file to set readOnlyPort to 0.
If using command line arguments, edit the kubelet service file
@ -249,6 +160,7 @@ groups:
test_items:
- flag: --streaming-connection-idle-timeout
path: '{.streamingConnectionIdleTimeout}'
set: true
compare:
op: noteq
value: 0
@ -269,13 +181,14 @@ groups:
scored: false
- id: 3.2.6
text: "Ensure that the --protect-kernel-defaults argument is set to true (Automated)"
text: "Ensure that the --protect-kernel-defaults argument is set to true (Manual)"
audit: "/bin/ps -fC $kubeletbin"
audit_config: "/bin/cat $kubeletconf"
tests:
test_items:
- flag: --protect-kernel-defaults
path: '{.protectKernelDefaults}'
set: true
compare:
op: eq
value: true
@ -288,16 +201,17 @@ groups:
Based on your system, restart the kubelet service. For example:
systemctl daemon-reload
systemctl restart kubelet.service
scored: true
scored: false
- id: 3.2.7
text: "Ensure that the --make-iptables-util-chains argument is set to true (Automated)"
text: "Ensure that the --make-iptables-util-chains argument is set to true (Manual) "
audit: "/bin/ps -fC $kubeletbin"
audit_config: "/bin/cat $kubeletconf"
tests:
test_items:
- flag: --make-iptables-util-chains
path: '{.makeIPTablesUtilChains}'
set: true
compare:
op: eq
value: true
@ -314,7 +228,7 @@ groups:
Based on your system, restart the kubelet service. For example:
systemctl daemon-reload
systemctl restart kubelet.service
scored: true
scored: false
- id: 3.2.8
text: "Ensure that the --hostname-override argument is not set (Manual)"
@ -343,6 +257,7 @@ groups:
test_items:
- flag: --event-qps
path: '{.eventRecordQPS}'
set: true
compare:
op: eq
value: 0
@ -357,30 +272,6 @@ groups:
scored: false
- id: 3.2.10
text: "Ensure that the --tls-cert-file and --tls-private-key-file arguments are set as appropriate (Manual)"
audit: "/bin/ps -fC $kubeletbin"
audit_config: "/bin/cat $kubeletconf"
tests:
test_items:
- flag: --tls-cert-file
path: '{.tlsCertFile}'
- flag: --tls-private-key-file
path: '{.tlsPrivateKeyFile}'
remediation: |
If using a Kubelet config file, edit the file to set tlsCertFile to the location
of the certificate file to use to identify this Kubelet, and tlsPrivateKeyFile
to the location of the corresponding private key file.
If using command line arguments, edit the kubelet service file
$kubeletsvc on each worker node and
set the below parameters in KUBELET_CERTIFICATE_ARGS variable.
--tls-cert-file=<path/to/tls-certificate-file>
--tls-private-key-file=<path/to/tls-key-file>
Based on your system, restart the kubelet service. For example:
systemctl daemon-reload
systemctl restart kubelet.service
scored: false
- id: 3.2.11
text: "Ensure that the --rotate-certificates argument is not set to false (Manual)"
audit: "/bin/ps -fC $kubeletbin"
audit_config: "/bin/cat $kubeletconf"
@ -388,6 +279,7 @@ groups:
test_items:
- flag: --rotate-certificates
path: '{.rotateCertificates}'
set: true
compare:
op: eq
value: true
@ -407,14 +299,15 @@ groups:
systemctl restart kubelet.service
scored: false
- id: 3.2.12
text: "Verify that the RotateKubeletServerCertificate argument is set to true (Manual)"
- id: 3.2.11
text: "Ensure that the RotateKubeletServerCertificate argument is set to true (Manual)"
audit: "/bin/ps -fC $kubeletbin"
audit_config: "/bin/cat $kubeletconf"
tests:
test_items:
- flag: RotateKubeletServerCertificate
path: '{.featureGates.RotateKubeletServerCertificate}'
set: true
compare:
op: eq
value: true
@ -426,27 +319,3 @@ groups:
systemctl daemon-reload
systemctl restart kubelet.service
scored: false
- id: 3.2.13
text: "Ensure that the Kubelet only makes use of Strong Cryptographic Ciphers (Manual)"
audit: "/bin/ps -fC $kubeletbin"
audit_config: "/bin/cat $kubeletconf"
tests:
test_items:
- flag: --tls-cipher-suites
path: '{range .tlsCipherSuites[:]}{}{'',''}{end}'
compare:
op: valid_elements
value: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
remediation: |
If using a Kubelet config file, edit the file to set TLSCipherSuites: to
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
or to a subset of these values.
If using executable arguments, edit the kubelet service file
$kubeletsvc on each worker node and
set the --tls-cipher-suites parameter as follows, or to a subset of these values.
--tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
Based on your system, restart the kubelet service. For example:
systemctl daemon-reload
systemctl restart kubelet.service
scored: false

View File

@ -2,14 +2,14 @@
controls:
version: "aks-1.0"
id: 4
text: "Kubernetes Policies"
text: "Policies"
type: "policies"
groups:
- id: 4.1
text: "RBAC and Service Accounts"
checks:
- id: 4.1.1
text: "Ensure that the cluster-admin role is only used where required (Not Scored)"
text: "Ensure that the cluster-admin role is only used where required (Manual)"
type: "manual"
remediation: |
Identify all clusterrolebindings to the cluster-admin role. Check if they are used and
@ -20,14 +20,14 @@ groups:
scored: false
- id: 4.1.2
text: "Minimize access to secrets (Not Scored)"
text: "Minimize access to secrets (Manual)"
type: "manual"
remediation: |
Where possible, remove get, list and watch access to secret objects in the cluster.
scored: false
- id: 4.1.3
text: "Minimize wildcard use in Roles and ClusterRoles (Not Scored)"
text: "Minimize wildcard use in Roles and ClusterRoles (Manual)"
type: "manual"
remediation: |
Where possible replace any use of wildcards in clusterroles and roles with specific
@ -35,24 +35,24 @@ groups:
scored: false
- id: 4.1.4
text: "Minimize access to create pods (Not Scored)"
text: "Minimize access to create pods (Manual)"
type: "manual"
Remediation: |
Where possible, remove create access to pod objects in the cluster.
scored: false
- id: 4.1.5
text: "Ensure that default service accounts are not actively used. (Scored)"
text: "Ensure that default service accounts are not actively used. (Manual)"
type: "manual"
remediation: |
Create explicit service accounts wherever a Kubernetes workload requires specific access
to the Kubernetes API server.
Modify the configuration of each default service account to include this value
automountServiceAccountToken: false
scored: true
scored: false
- id: 4.1.6
text: "Ensure that Service Account Tokens are only mounted where necessary (Not Scored)"
text: "Ensure that Service Account Tokens are only mounted where necessary (Manual)"
type: "manual"
remediation: |
Modify the definition of pods and service accounts which do not need to mount service
@ -63,159 +63,141 @@ groups:
text: "Pod Security Policies"
checks:
- id: 4.2.1
text: "Minimize the admission of privileged containers (Not Scored)"
text: "Minimize the admission of privileged containers (Automated)"
type: "manual"
remediation: |
Implement Azure Policy to disallow running of privileged containers. See https://docs.microsoft.com/en-us/azure/aks/use-pod-security-on-azure-policy#built-in-policy-initiatives
Create a PSP as described in the Kubernetes documentation, ensuring that
the .spec.privileged field is omitted or set to false.
scored: false
- id: 4.2.2
text: "Disallow shared usage of host namespaces."
text: "Minimize the admission of containers wishing to share the host process ID namespace (Automated)"
type: "manual"
remediation: |
Implement Azure Policy to disallow shared usage of host namespaces. See https://docs.microsoft.com/en-us/azure/aks/use-pod-security-on-azure-policy#built-in-policy-initiatives
Create a PSP as described in the Kubernetes documentation, ensuring that the
.spec.hostPID field is omitted or set to false.
scored: false
- id: 4.2.3
text: "Restrict all usage of host networking and ports"
text: "Minimize the admission of containers wishing to share the host IPC namespace (Automated)"
type: "manual"
remediation: |
Implement Azure Policy to restrict all usage of host networking and ports. See https://docs.microsoft.com/en-us/azure/aks/use-pod-security-on-azure-policy#built-in-policy-initiatives
Create a PSP as described in the Kubernetes documentation, ensuring that the
.spec.hostIPC field is omitted or set to false.
scored: false
- id: 4.2.4
text: "Restrict any usage of the host filesystem."
text: "Minimize the admission of containers wishing to share the host network namespace (Automated)"
type: "manual"
remediation: |
Implement Azure Policy to restrict all usage of host networking and ports. See https://docs.microsoft.com/en-us/azure/aks/use-pod-security-on-azure-policy#built-in-policy-initiatives
Create a PSP as described in the Kubernetes documentation, ensuring that the
.spec.hostNetwork field is omitted or set to false.
scored: false
- id: 4.2.5
text: "Restrict Linux capabilities to the default set."
text: "Minimize the admission of containers with allowPrivilegeEscalation (Automated)"
type: "manual"
remediation: |
Implement Azure Policy to restrict Linux capabilities to the default set. See https://docs.microsoft.com/en-us/azure/aks/use-pod-security-on-azure-policy#built-in-policy-initiatives
Create a PSP as described in the Kubernetes documentation, ensuring that the
.spec.allowPrivilegeEscalation field is omitted or set to false.
scored: false
- id: 4.2.6
text: "Restrict usage of defined volume types"
text: "Minimize the admission of root containers (Automated)"
type: "manual"
remediation: |
Implement Azure Policy to restrict usage of defined volume types. See https://docs.microsoft.com/en-us/azure/aks/use-pod-security-on-azure-policy#built-in-policy-initiatives
Create a PSP as described in the Kubernetes documentation, ensuring that the
.spec.runAsUser.rule is set to either MustRunAsNonRoot or MustRunAs with the range of
UIDs not including 0.
scored: false
- id: 4.2.7
text: "Restrict the user and group IDs of the container"
text: "Minimize the admission of containers with the NET_RAW capability (Automated)"
type: "manual"
remediation: |
Implement Azure Policy to restrict the user and group IDs of the container. See https://docs.microsoft.com/en-us/azure/aks/use-pod-security-on-azure-policy#built-in-policy-initiatives
Create a PSP as described in the Kubernetes documentation, ensuring that the
.spec.requiredDropCapabilities is set to include either NET_RAW or ALL.
scored: false
- id: 4.2.8
text: "Restrict allocating an FSGroup that owns the pod's volumes"
text: "Minimize the admission of containers with added capabilities (Automated)"
type: "manual"
remediation: |
Implement Azure Policy to restrict allocating an FSGroup that owns the pod's volumes. See https://docs.microsoft.com/en-us/azure/aks/use-pod-security-on-azure-policy#built-in-policy-initiatives
Ensure that allowedCapabilities is not present in PSPs for the cluster unless
it is set to an empty array.
scored: false
- id: 4.2.9
text: "Requires seccomp profile"
text: "Minimize the admission of containers with capabilities assigned (Manual)"
type: "manual"
remediation: |
Implement Azure Policy to requires seccomp profile. See https://docs.microsoft.com/en-us/azure/aks/use-pod-security-on-azure-policy#built-in-policy-initiatives.
scored: false
- id: 4.2.10
text: "Define the AppArmor profile used by containers"
type: "manual"
remediation: |
Implement Azure Policy to define the AppArmor profile used by containers. See https://docs.microsoft.com/en-us/azure/aks/use-pod-security-on-azure-policy#additional-optional-policies.
Review the use of capabilities in applications running on your cluster. Where a namespace
contains applications which do not require any Linux capabities to operate consider adding
a PSP which forbids the admission of containers which do not drop all capabilities.
scored: false
- id: 4.3
text: "Network Policies and CNI"
text: "Azure Policy / OPA"
checks: []
- id: 4.4
text: "CNI Plugin"
checks:
- id: 4.3.1
text: "Ensure that the CNI in use supports Network Policies (Not Scored)"
- id: 4.4.1
text: "Ensure that the latest CNI version is used (Manual)"
type: "manual"
remediation: |
To use a CNI plugin with Network Policy, enable Network Policy in AKS. See Recommendation 6.4.4.
Review the documentation of AWS CNI plugin, and ensure latest CNI version is used.
scored: false
- id: 4.3.2
text: "Ensure that all Namespaces have Network Policies defined (Scored)"
- id: 4.4.2
text: "Ensure that all Namespaces have Network Policies defined (Manual)"
type: "manual"
remediation: |
Follow the documentation and create NetworkPolicy objects as you need them.
scored: false
- id: 4.4
- id: 4.5
text: "Secrets Management"
checks:
- id: 4.4.1
text: "Prefer using secrets as files over secrets as environment variables (Not Scored)"
- id: 4.5.1
text: "Prefer using secrets as files over secrets as environment variables (Manual)"
type: "manual"
remediation: |
If possible, rewrite application code to read secrets from mounted secret files, rather than
from environment variables.
scored: false
- id: 4.4.2
text: "Consider external secret storage (Not Scored)"
- id: 4.5.2
text: "Consider external secret storage (Manual)"
type: "manual"
remediation: |
Use the Azure Key Vault with Secrets Store CSI Driver to retrieve secrets from Azure Key Vault and load it in the pod. See https://github.com/Azure/secrets-store-csi-driver-provider-azure.
scored: false
- id: 4.5
text: "Extensible Admission Control"
checks:
- id: 4.5.1
text: "Configure Image Provenance using ImagePolicyWebhook admission controller (Not Scored)"
type: "manual"
remediation: |
Follow the Kubernetes documentation and setup image provenance.
Refer to the secrets management options offered by your cloud provider or a third-party
secrets management solution.
scored: false
- id: 4.6
text: "General Policies"
text: "Extensible Admission Control"
checks:
- id: 4.6.1
text: "Create administrative boundaries between resources using namespaces (Not Scored)"
text: "Verify that admission controllers are working as expected (Manual)"
type: "manual"
remediation: "No remediation"
scored: false
- id: 4.7
text: "General Policies"
checks:
- id: 4.7.1
text: "Create administrative boundaries between resources using namespaces (Manual)"
type: "manual"
remediation: |
Follow the documentation and create namespaces for objects in your deployment as you need
them.
scored: false
- id: 4.6.2
text: "Ensure that the seccomp profile is set to docker/default in your pod definitions (Not Scored)"
type: "manual"
remediation: |
Seccomp is an alpha feature currently. By default, all alpha features are disabled. So, you
would need to enable alpha features in the apiserver by passing "--feature-
gates=AllAlpha=true" argument.
Edit the /etc/kubernetes/apiserver file on the master node and set the KUBE_API_ARGS
parameter to "--feature-gates=AllAlpha=true"
KUBE_API_ARGS="--feature-gates=AllAlpha=true"
Based on your system, restart the kube-apiserver service. For example:
systemctl restart kube-apiserver.service
Use annotations to enable the docker/default seccomp profile in your pod definitions. An
example is as below:
apiVersion: v1
kind: Pod
metadata:
name: trustworthy-pod
annotations:
seccomp.security.alpha.kubernetes.io/pod: docker/default
spec:
containers:
- name: trustworthy-container
image: sotrustworthy:latest
scored: false
- id: 4.6.3
text: "Apply Security Context to Your Pods and Containers (Not Scored)"
- id: 4.7.2
text: "Apply Security Context to Your Pods and Containers (Manual)"
type: "manual"
remediation: |
Follow the Kubernetes documentation and apply security contexts to your pods. For a
@ -223,34 +205,10 @@ groups:
Containers.
scored: false
- id: 4.6.4
text: "The default namespace should not be used (Scored)"
- id: 4.7.3
text: "The default namespace should not be used (Manual)"
type: "manual"
remediation: |
Ensure that namespaces are created to allow for appropriate segregation of Kubernetes
resources and that all new resources are created in a specific namespace.
scored: false
- id: 4.7
text: "Azure Policy Controls for ACR"
checks:
- id: 4.7.1
text: "Container Registry should use a virtual network service endpoint"
type: "manual"
remediation: |
Implement Azure Policy for Container Registry should use a virtual network service endpoint. See https://docs.microsoft.com/en-us/azure/container-registry/security-controls-policy#azure-security-benchmark
scored: false
- id: 4.7.2
text: "Container registries should not allow unrestricted network access"
type: "manual"
remediation: |
Implement Azure Policy for Container registries should not allow unrestricted network access. See https://docs.microsoft.com/en-us/azure/container-registry/container-registry-azure-policy#built-in-policy-definitions
scored: false
- id: 4.7.3
text: "Container registries should use private links"
type: "manual"
remediation: |
Implement Azure Policy for Container registries should use private links. See https://docs.microsoft.com/en-us/azure/container-registry/container-registry-azure-policy#built-in-policy-definitions
scored: false

View File

@ -13,5 +13,6 @@ Some defined by other hardenening guides.
| CIS | [GKE 1.0.0](https://workbench.cisecurity.org/benchmarks/4536) | gke-1.0 | GKE |
| CIS | [EKS 1.0.0](https://workbench.cisecurity.org/benchmarks/5190) | eks-1.0 | EKS |
| CIS | [ACK 1.0.0](https://workbench.cisecurity.org/benchmarks/6467) | ack-1.0 | ACK |
| CIS | [AKS 1.0.0](https://workbench.cisecurity.org/benchmarks/6347) | aks-1.0 | AKS |
| RHEL | RedHat OpenShift hardening guide | rh-0.7 | OCP 3.10-3.11 |
| CIS | [OCP4 1.1.0](https://workbench.cisecurity.org/benchmarks/6778) | rh-1.0 | OCP 4.1- |