SEC-1721: add config for aks v1.6.0 (#390)

cmd/linter/kubebench/kubebench-rules/aks-1.6.0/config.yaml

@@ -0,0 +1,2 @@
+---
+## Version-specific settings that override the values in cfg/config.yaml

cmd/linter/kubebench/kubebench-rules/aks-1.6.0/controlplane.yaml

@@ -0,0 +1,23 @@
+controls: ""
+version: aks-1.6.0
+id: 2
+text: Master (Control Plane) Configuration
+type: controlplane
+groups:
+    - id: "2.1"
+      text: Logging
+      checks:
+        - id: 2.1.1
+          text: Enable audit Logs
+          type: manual
+          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

cmd/linter/kubebench/kubebench-rules/aks-1.6.0/managedservices.yaml

@@ -0,0 +1,112 @@
+controls: ""
+version: aks-1.6.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 using Azure Defender image scanning or a third party provider
+          type: automated
+          remediation: |-
+            Enable Azure Defender for Container Registries: If you find that Azure Defender for container registries is not enabled and you wish to enable it, you can do so using the following command:
+
+            `az security pricing create --name ContainerRegistry --tier Standard`
+
+            Please note, enabling Azure Defender for container registries incurs additional costs, so be sure to review the pricing details on the official Azure documentation before enabling it.
+          scored: false
+        - id: 5.1.2
+          text: Minimize user access to Azure Container Registry (ACR)
+          type: manual
+          remediation: |-
+            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 Azure Container Registry (ACR)
+          type: manual
+          scored: false
+        - id: 5.1.4
+          text: Minimize Container Registries to only those approved
+          type: manual
+          remediation: |-
+            If you are using Azure Container Registry you have this option:
+            https://docs.microsoft.com/en-us/azure/container-registry/container-registry-firewall-access-rules
+
+            For other non-AKS repos using admission controllers or Azure Policy will also work.
+
+            Limiting or locking down egress traffic is also recommended:
+            https://docs.microsoft.com/en-us/azure/aks/limit-egress-traffic
+          scored: false
+    - id: "5.2"
+      text: Access and identity options for Azure Kubernetes Service (AKS)
+      checks:
+        - id: 5.2.1
+          text: Prefer using dedicated AKS Service Accounts
+          type: manual
+          remediation: |-
+            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: Key Management Service (KMS)
+      checks:
+        - id: 5.3.1
+          text: Ensure Kubernetes Secrets are encrypted
+          type: manual
+          scored: false
+    - id: "5.4"
+      text: Cluster Networking
+      checks:
+        - id: 5.4.1
+          text: Restrict Access to the Control Plane Endpoint
+          type: automated
+          remediation: |-
+            By enabling private endpoint access to the Kubernetes API server, all communication between your nodes and the API server stays within your VPC. You can also limit the IP addresses that can access your API server from the internet, or completely disable internet access to the API server.
+
+            With this in mind, you can update your cluster accordingly using the AKS CLI to ensure that Private Endpoint Access is enabled.
+
+            If you choose to also enable Public Endpoint Access then you should also configure a list of allowable CIDR blocks, resulting in restricted access from the internet. If you specify no CIDR blocks, then the public API server endpoint is able to receive and process requests from all IP addresses by defaulting to ['0.0.0.0/0'].
+
+            For example, the following command would enable private access to the Kubernetes API as well as limited public access over the internet from a single IP address (noting the /32 CIDR suffix):
+          scored: false
+        - id: 5.4.2
+          text: Ensure clusters are Private Cluster enabled and Public Access Disabled
+          type: automated
+          remediation: To use a private endpoint, create a new private endpoint in your virtual network then create a link between your virtual network and a new private DNS zone
+          scored: false
+        - id: 5.4.3
+          text: Ensure clusters are created with Private Nodes
+          type: automated
+          remediation: "```\naz aks create \\\n--resource-group <private-cluster-resource-group> \\\n--name <private-cluster-name> \\\n--load-balancer-sku standard \\\n--enable-private-cluster \\\n--network-plugin azure \\\n--vnet-subnet-id <subnet-id> \\\n--docker-bridge-address \\\n--dns-service-ip \\\n--service-cidr \n```\n\nWhere `--enable-private-cluster` is a mandatory flag for a private cluster."
+          scored: false
+        - id: 5.4.4
+          text: Ensure Network Policy is Enabled and set as appropriate
+          type: automated
+          remediation: Utilize Calico or other network policy engine to segment and isolate your traffic.
+          scored: false
+        - id: 5.4.5
+          text: Encrypt traffic to HTTPS load balancers with TLS certificates
+          type: manual
+          scored: false
+    - id: "5.5"
+      text: Authentication and Authorization
+      checks:
+        - id: 5.5.1
+          text: Manage Kubernetes RBAC users with Azure AD
+          type: manual
+          scored: false
+        - id: 5.5.2
+          text: Use Azure RBAC for Kubernetes Authorization
+          type: manual
+          scored: false

cmd/linter/kubebench/kubebench-rules/aks-1.6.0/master.yaml

@@ -0,0 +1,5 @@
+controls: ""
+version: aks-1.6.0
+id: 1
+text: Master (Control Plane) Components
+type: master