Checks

Azure Cosmos DB accounts are evaluated for continuous backup policy. Continuous backup provides point-in-time restore (PITR) enabling recovery to any point within the retention window, unlike periodic backup which only supports full restores at fixed intervals.

Azure Cosmos DB accounts limit connectivity to selected networks using virtual network rules and/or IP allowlists rather than permitting access from all networks.

The evaluation determines whether the account's network firewall enforces this restriction.

Azure Cosmos DB accounts are evaluated for minimum TLS version. TLS 1.0 and 1.1 are deprecated and contain known weaknesses. Enforcing TLS 1.2 ensures all client connections negotiate modern, secure encryption protocols.

Azure Cosmos DB accounts are evaluated for public network access. Disabling public network access ensures the account is only reachable through private endpoints or VNet service endpoints, reducing the attack surface and preventing direct exposure of the data plane to the internet.

Azure Cosmos DB accounts configured to use Microsoft Entra ID with Azure RBAC by disabling key-based credentials (disableLocalAuth=true). Clients authenticate with identities rather than account keys.

Azure Cosmos DB accounts are assessed for private endpoint connections that keep data-plane traffic on private IPs within authorized virtual networks.

CloudMonitor agent provides visibility into system metrics for Kubernetes Engine clusters, including CPU, disk, network, and IO. Without it, operators lack observability into node and pod health. Enabling CloudMonitor creates a controller that collects metrics from each node's Pods and containers for analysis and alerting.

Alibaba Cloud Kubernetes Engine provides a cluster health check that validates node health and cluster configuration, including kubelet, docker daemon, kernel, and iptables settings. Running checks regularly ensures VPC/VSwitch, SLB, and ECS nodes function correctly. Consecutive failures generate diagnostic reports for corrective action.

Alibaba Cloud Kubernetes Engine provides a cluster health check that validates node health and cluster configuration, including kubelet, docker daemon, kernel, and iptables settings. Weekly checks ensure VPC/VSwitch, SLB, and ECS nodes function correctly. Consecutive failures generate diagnostic reports for corrective action.

Alibaba Cloud Kubernetes Engine clusters should not have the Kubernetes Dashboard (web UI) enabled. The Dashboard uses a highly privileged Service Account that can perform administrative operations across the cluster. Use the ACK Console instead, which provides fine-grained access control through RAM policies and RBAC integration.

With ENI multiple IP mode provided by the Terway network plugin, Kubernetes Engine clusters allocate pod IPs from the VPC CIDR block, enabling better scalability and native integration with Alibaba Cloud services. This mode allows pods to have their own security group associations, providing granular network-level access control independently from host nodes.

Alibaba Cloud Log Service supports collection, search, storage, and analysis for container and audit logs in Kubernetes Engine clusters. When enabled, it automatically collects kube-apiserver audit logs, ingress logs, and stdout/stderr from containers. These logs are stored persistently and are essential for operational visibility, security monitoring, and compliance auditing.

Alibaba Cloud Kubernetes Engine clusters should enable Network Policy via the Terway plugin. A NetworkPolicy defines how pods communicate using label-based rules. By default, pods accept traffic from any source; NetworkPolicy restricts traffic to explicitly allowed connections, enforcing least privilege at the network level.

Alibaba Cloud Kubernetes Engine clusters should be configured as private clusters so the API server endpoint is not publicly accessible. In a private cluster, nodes lack public IPs and all node-to-master communication occurs through VPC peering. This reduces the attack surface by eliminating direct internet exposure of the control plane and worker nodes.

Alibaba Cloud Kubernetes Engine clusters should have RBAC enabled for fine-grained authorization. RBAC lets administrators define roles with specific permissions at cluster and namespace level, ensuring users and service accounts access only needed resources. Legacy ABAC grants broad, static permissions and should be disabled in favor of RBAC.

Ensure that Cloud Trace Service (CTS) tracker is enabled to record all API calls and operations performed in the Huawei Cloud account.

OCI Autonomous Database (shared) network exposure is evaluated: instances are treated as restricted when using a VCN private endpoint or when ACLs allow only specified IPs/VCNs. It identifies configurations with no ACL and no VCN, or ACLs permitting 0.0.0.0/0.

E2E Networks database clusters should have automated backups enabled so data can be restored after failures, corruption, or accidental deletion. Automated backups capture point-in-time copies of the cluster on a recurring schedule.

E2E Networks database clusters should be configured with a custom administrative username instead of the well-known default, reducing the predictability of privileged credentials.

E2E Networks database clusters that expose a public IP should restrict connectivity through an IP whitelist instead of accepting connections from any address (0.0.0.0/0).

The master node of each E2E Networks database cluster should be reachable only over private networking and must not have a public IP address assigned.

E2E Networks database clusters should be in the RUNNING state, confirming they are operational rather than stopped, failed, or stuck in a transitional status.

E2E Networks database clusters should require SSL/TLS on the master node so that client connections and credentials are encrypted in transit.

E2E Networks database read replicas should be reachable only over private networking and must not have a public IP address assigned.