mirror of
https://github.com/aquasecurity/kube-bench.git
synced 2024-12-19 05:08:07 +00:00
256 lines
14 KiB
YAML
256 lines
14 KiB
YAML
|
---
|
||
|
controls:
|
||
|
version: "aks-1.0"
|
||
|
id: 5
|
||
|
text: "Managed Services"
|
||
|
type: "managedservices"
|
||
|
groups:
|
||
|
- id: 5.1
|
||
|
text: "Image Registry and Image Scanning"
|
||
|
checks:
|
||
|
- id: 5.1.1
|
||
|
text: "Ensure Image Vulnerability Scanning"
|
||
|
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.
|
||
|
scored: false
|
||
|
|
||
|
- id: 5.1.2
|
||
|
text: "Minimize user access to ACR"
|
||
|
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.
|
||
|
scored: false
|
||
|
|
||
|
- id: 5.1.3
|
||
|
text: "Minimize cluster access to read-only for ACR"
|
||
|
type: "manual"
|
||
|
remediation: |
|
||
|
Ensure identity assigned to AKS uses read-only role for accessing ACR.
|
||
|
scored: false
|
||
|
|
||
|
- id: 5.1.4
|
||
|
text: "Protect ACR using NSGs or Azure Firewall on your Virtual Network"
|
||
|
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
|
||
|
scored: false
|
||
|
|
||
|
- id: 5.2
|
||
|
text: "Identity and Access Management (IAM)"
|
||
|
checks:
|
||
|
- id: 5.2.1
|
||
|
text: "Use managed identities in Azure Kubernetes Service"
|
||
|
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
|
||
|
scored: false
|
||
|
|
||
|
- id: 5.3
|
||
|
text: "Cloud Key Management Service"
|
||
|
checks:
|
||
|
- id: 5.3.1
|
||
|
text: "Ensure Kubernetes Secrets are stored and retrieved from Azure Key Vault."
|
||
|
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: 5.4
|
||
|
text: "Cluster Networking"
|
||
|
checks:
|
||
|
- id: 5.4.1
|
||
|
text: "Enable NSG Flow Logs for AKS subnets."
|
||
|
type: "manual"
|
||
|
remediation: |
|
||
|
Enable network security group (NSG) flow logs for the NSG attached to the subnet being used for AKS cluster nodes.
|
||
|
scored: false
|
||
|
|
||
|
- id: 5.4.2
|
||
|
text: "Ensure clusters are created with Private Endpoint Enabled and Public Access Disabled (Scored)"
|
||
|
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
|
||
|
scored: false
|
||
|
|
||
|
- id: 5.4.3
|
||
|
text: "Configure NSG on AKS worker node subnet"
|
||
|
type: "manual"
|
||
|
remediation: |
|
||
|
Configure NSG rules on AKS worker node subnet to allow only required network traffic.
|
||
|
scored: false
|
||
|
|
||
|
- id: 5.4.4
|
||
|
text: "Ensure Network Policy is Enabled and set as appropriate (Not Scored)"
|
||
|
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.
|
||
|
scored: false
|
||
|
|
||
|
- id: 5.5
|
||
|
text: "Logging"
|
||
|
checks:
|
||
|
- id: 5.5.1
|
||
|
text: "Enable Azure Monitor for container for kubelet logs"
|
||
|
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
|
||
|
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)"
|
||
|
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
|
||
|
scored: false
|
||
|
|
||
|
- id: 5.8.2
|
||
|
text: "Secure pods with Azure Policy as appropriate"
|
||
|
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.
|
||
|
scored: false
|