skyveda 0.3.0__py3-none-any.whl

skyveda/__init__.py

@@ -0,0 +1,3 @@
+"""Skyveda: read-only cloud platform health scanning."""
+
+__version__ = "0.3.0"

skyveda/__main__.py

@@ -0,0 +1,5 @@
+"""Allow ``python -m skyveda``."""
+
+from skyveda.cli import app
+
+app()

skyveda/checks/azure/AZ-ACR-001.yaml

@@ -0,0 +1,32 @@
+schema_version: 1
+id: AZ-ACR-001
+title: Container registries have the admin user disabled
+provider: azure
+area: identity
+severity: high
+source:
+  type: resource_graph
+  query: |
+    // Azure's default for adminUserEnabled is false, but a missing value is read as enabled so
+    // that unknown data FAILS.
+    resources
+    | where type =~ 'microsoft.containerregistry/registries'
+    | extend adminUserEnabled = tobool(properties.adminUserEnabled), skuName = tostring(sku.name)
+    | project id, name, resourceGroup, location, skuName, adminUserEnabled,
+              compliant = coalesce(adminUserEnabled, true) == false
+why: >-
+  The admin user is a single shared username and password with full push and pull rights. It
+  cannot be tied to a person, cannot be scoped down, and leaks easily. Entra ID identities and
+  role assignments are audited and can be limited to what each user or service needs.
+fix:
+  summary: Disable the admin user and use Entra ID identities with AcrPull and AcrPush roles.
+  steps:
+    - Find what logs in with the admin credentials today (pipelines, App Service, scripts).
+    - Give each a managed identity or service principal with the AcrPull or AcrPush role.
+    - Disable the admin user.
+  cli: az acr update -g <resource-group> -n <registry> --admin-enabled false
+  terraform: |
+    # azurerm_container_registry
+    admin_enabled = false
+references:
+  - https://learn.microsoft.com/azure/container-registry/container-registry-authentication#admin-account

skyveda/checks/azure/AZ-ACR-002.yaml

@@ -0,0 +1,34 @@
+schema_version: 1
+id: AZ-ACR-002
+title: Container registries do not allow anonymous pull
+provider: azure
+area: security
+severity: high
+tier: free
+source:
+  type: resource_graph
+  query: |
+    // properties.anonymousPullEnabled is false unless turned on (Standard and Premium only), and
+    // Basic registries cannot turn it on, so a missing value is read as false. The lab plants the
+    // fail case to prove the path.
+    resources
+    | where type =~ 'microsoft.containerregistry/registries'
+    | extend anonymousPullEnabled = coalesce(tobool(properties.anonymousPullEnabled), false),
+             sku = tostring(sku.name)
+    | project id, name, resourceGroup, location, sku, anonymousPullEnabled,
+              compliant = anonymousPullEnabled == false
+why: >-
+  With anonymous pull, anyone on the Internet can download every image in the registry without
+  signing in. Images often contain source code, internal addresses and sometimes secrets baked in
+  at build time.
+fix:
+  summary: Turn off anonymous pull and give clients that need images a role such as AcrPull.
+  steps:
+    - Find the clients that pull without signing in and give them an identity with the AcrPull role.
+    - Turn off anonymous pull on the registry.
+  cli: az acr update -n <registry> --anonymous-pull-enabled false
+  terraform: |
+    # azurerm_container_registry
+    anonymous_pull_enabled = false
+references:
+  - https://learn.microsoft.com/azure/container-registry/anonymous-pull-access

skyveda/checks/azure/AZ-ACR-003.yaml

@@ -0,0 +1,37 @@
+schema_version: 1
+id: AZ-ACR-003
+title: Container registries are not open to all networks
+provider: azure
+area: network
+severity: medium
+tier: free
+source:
+  type: resource_graph
+  query: |
+    // Compliant when public network access is Disabled, or the firewall default action is Deny
+    // (both need the Premium SKU). A missing publicNetworkAccess is read as Enabled and a missing
+    // defaultAction as Allow: both are the Azure defaults, so unknown data fails.
+    resources
+    | where type =~ 'microsoft.containerregistry/registries'
+    | extend sku = tostring(sku.name),
+             publicNetworkAccess = coalesce(tostring(properties.publicNetworkAccess), 'Enabled'),
+             defaultAction = coalesce(tostring(properties.networkRuleSet.defaultAction), 'Allow')
+    | project id, name, resourceGroup, location, sku, publicNetworkAccess, defaultAction,
+              compliant = publicNetworkAccess =~ 'Disabled' or defaultAction =~ 'Deny'
+why: >-
+  A registry that accepts connections from any network can be pushed to or pulled from anywhere
+  on the Internet with a leaked credential. A poisoned image pushed this way runs in every
+  cluster and app that pulls it.
+fix:
+  summary: Use private endpoints, or limit the registry firewall to known networks (Premium SKU).
+  steps:
+    - Upgrade the registry to Premium if it is Basic or Standard.
+    - Add a private endpoint, or firewall rules for the build agents and clusters that use the registry.
+    - Set public network access to Disabled, or the default action to Deny.
+  cli: az acr update -n <registry> --public-network-enabled false   # Premium registries only
+  terraform: |
+    # azurerm_container_registry (sku = "Premium")
+    public_network_access_enabled = false
+references:
+  - https://learn.microsoft.com/azure/container-registry/container-registry-access-selected-networks
+  - https://learn.microsoft.com/azure/container-registry/container-registry-private-link

skyveda/checks/azure/AZ-AI-001.yaml

@@ -0,0 +1,33 @@
+schema_version: 1
+id: AZ-AI-001
+title: Azure AI services accounts disable key-based authentication
+provider: azure
+area: identity
+severity: medium
+tier: free
+source:
+  type: resource_graph
+  query: |
+    // Covers Azure OpenAI and the other Azure AI services (type microsoft.cognitiveservices/accounts).
+    // properties.disableLocalAuth defaults to false (keys allowed). A missing value FAILS.
+    resources
+    | where type =~ 'microsoft.cognitiveservices/accounts'
+    | extend disableLocalAuth = tobool(properties.disableLocalAuth), serviceKind = tostring(kind)
+    | project id, name, resourceGroup, location, serviceKind, disableLocalAuth,
+              compliant = coalesce(disableLocalAuth, false)
+why: >-
+  An API key lets anyone who holds it call the service on your bill and, for Azure OpenAI, send
+  it your data and prompts. Keys leak through code and config files and do not say who used them.
+  Entra ID access is scoped, audited and removed when no longer needed.
+fix:
+  summary: Move applications to Entra ID authentication, then disable key-based access.
+  steps:
+    - Give the account a custom subdomain if it has none (Entra ID authentication needs one).
+    - Grant each application a role such as Cognitive Services User and switch it to its managed identity.
+    - Disable local (key-based) authentication on the account.
+  cli: az resource update --ids <account-id> --set properties.disableLocalAuth=true
+  terraform: |
+    # azurerm_cognitive_account
+    local_auth_enabled = false
+references:
+  - https://learn.microsoft.com/azure/ai-services/disable-local-auth

skyveda/checks/azure/AZ-AKS-002.yaml

@@ -0,0 +1,32 @@
+schema_version: 1
+id: AZ-AKS-002
+title: AKS clusters use Entra ID only, with local accounts disabled
+provider: azure
+area: kubernetes
+severity: high
+tier: free
+source:
+  type: resource_graph
+  query: |
+    resources
+    | where type =~ 'microsoft.containerservice/managedclusters'
+    | extend disableLocalAccounts = tobool(properties.disableLocalAccounts),
+             entraManaged = tobool(properties.aadProfile.managed)
+    | project id, name, resourceGroup, location, disableLocalAccounts, entraManaged,
+              compliant = coalesce(disableLocalAccounts, false) and coalesce(entraManaged, false)
+why: >-
+  Local Kubernetes accounts use static credentials that bypass Entra ID sign-in, conditional
+  access and audit. Anyone holding the admin kubeconfig keeps full control even after leaving.
+fix:
+  summary: Integrate the cluster with Entra ID and disable local accounts.
+  steps:
+    - Make sure Entra ID integration is enabled and an admin group is set.
+    - Move any automation from the admin kubeconfig to Entra-based credentials.
+    - Disable local accounts.
+  cli: az aks update -g <resource-group> -n <cluster> --enable-aad --disable-local-accounts
+  terraform: |
+    # azurerm_kubernetes_cluster
+    local_account_disabled = true
+    azure_active_directory_role_based_access_control { azure_rbac_enabled = true }
+references:
+  - https://learn.microsoft.com/azure/aks/manage-local-accounts-managed-azure-ad

skyveda/checks/azure/AZ-AKS-003.yaml

@@ -0,0 +1,29 @@
+schema_version: 1
+id: AZ-AKS-003
+title: AKS API server is private or limited to authorised IP ranges
+provider: azure
+area: kubernetes
+severity: high
+source:
+  type: resource_graph
+  query: |
+    resources
+    | where type =~ 'microsoft.containerservice/managedclusters'
+    | extend privateCluster = tobool(properties.apiServerAccessProfile.enablePrivateCluster),
+             authorizedRanges = array_length(properties.apiServerAccessProfile.authorizedIPRanges)
+    | project id, name, resourceGroup, location, privateCluster, authorizedRanges,
+              compliant = coalesce(privateCluster, false) or coalesce(authorizedRanges, 0) > 0
+why: >-
+  A Kubernetes API server open to the whole Internet can be attacked by anyone who finds it.
+  A private cluster or an allow-list of office and pipeline addresses removes that exposure.
+fix:
+  summary: Limit API server access to authorised IP ranges, or use a private cluster.
+  steps:
+    - List the addresses that need kubectl access (offices, VPN, CI runners).
+    - Add them as authorised IP ranges, or plan a move to a private cluster.
+  cli: az aks update -g <resource-group> -n <cluster> --api-server-authorized-ip-ranges <cidr1>,<cidr2>
+  terraform: |
+    # azurerm_kubernetes_cluster
+    api_server_access_profile { authorized_ip_ranges = ["<cidr>"] }
+references:
+  - https://learn.microsoft.com/azure/aks/api-server-authorized-ip-ranges

skyveda/checks/azure/AZ-AKS-004.yaml

@@ -0,0 +1,27 @@
+schema_version: 1
+id: AZ-AKS-004
+title: AKS clusters separate system and user node pools
+provider: azure
+area: kubernetes
+severity: medium
+source:
+  type: resource_graph
+  query: |
+    resources
+    | where type =~ 'microsoft.containerservice/managedclusters'
+    | mv-expand pool = properties.agentPoolProfiles
+    | summarize systemPools = countif(tostring(pool.mode) =~ 'System'),
+                userPools = countif(tostring(pool.mode) =~ 'User')
+                by id, name, resourceGroup, location
+    | extend compliant = systemPools >= 1 and userPools >= 1
+why: >-
+  When application pods share nodes with system components, a busy or faulty workload can starve
+  DNS and other critical services and take the whole cluster down.
+fix:
+  summary: Run applications on a separate user node pool and keep the system pool for system pods.
+  steps:
+    - Add a user node pool sized for your workloads.
+    - Taint the system pool with CriticalAddonsOnly=true:NoSchedule and move workloads across.
+  cli: az aks nodepool add -g <resource-group> --cluster-name <cluster> -n userpool --mode User
+references:
+  - https://learn.microsoft.com/azure/aks/use-system-pools

skyveda/checks/azure/AZ-AKS-005.yaml

@@ -0,0 +1,27 @@
+schema_version: 1
+id: AZ-AKS-005
+title: AKS node pools are spread across availability zones
+provider: azure
+area: reliability
+severity: medium
+source:
+  type: resource_graph
+  query: |
+    resources
+    | where type =~ 'microsoft.containerservice/managedclusters'
+    | mv-expand pool = properties.agentPoolProfiles
+    | summarize pools = count(),
+                poolsWithoutZones = countif(coalesce(array_length(pool.availabilityZones), 0) < 2)
+                by id, name, resourceGroup, location
+    | extend compliant = poolsWithoutZones == 0
+why: >-
+  A node pool in a single zone goes down with that zone. Spreading nodes across zones keeps
+  workloads running through a datacentre outage.
+fix:
+  summary: Create node pools across at least two availability zones (zones are set at creation).
+  steps:
+    - Check the region supports availability zones.
+    - Create a replacement pool with zones 1, 2 and 3, move workloads, then remove the old pool.
+  cli: az aks nodepool add -g <resource-group> --cluster-name <cluster> -n pool2 --zones 1 2 3
+references:
+  - https://learn.microsoft.com/azure/aks/availability-zones

skyveda/checks/azure/AZ-AKS-006.yaml

@@ -0,0 +1,31 @@
+schema_version: 1
+id: AZ-AKS-006
+title: AKS clusters have the Azure Policy add-on enabled
+provider: azure
+area: security
+severity: medium
+tier: free
+source:
+  type: resource_graph
+  query: |
+    resources
+    | where type =~ 'microsoft.containerservice/managedclusters'
+    | extend azurePolicyEnabled = tobool(properties.addonProfiles.azurepolicy.enabled)
+    // coalesce: a missing add-on profile or unknown value counts as not enabled, so it fails.
+    | project id, name, resourceGroup, location, azurePolicyEnabled,
+              compliant = coalesce(azurePolicyEnabled, false)
+why: >-
+  Without the Azure Policy add-on, nothing stops a pod from running as root, mounting the host or
+  pulling from an untrusted registry. The add-on enforces guardrails when workloads are admitted.
+fix:
+  summary: Enable the Azure Policy add-on, then assign the built-in Kubernetes policy initiative.
+  steps:
+    - Enable the add-on on the cluster.
+    - Assign the "Kubernetes cluster pod security baseline standards" initiative, in audit mode first.
+    - Move the policies to deny once the audit results are clean.
+  cli: az aks enable-addons -g <resource-group> -n <cluster> --addons azure-policy
+  terraform: |
+    # azurerm_kubernetes_cluster
+    azure_policy_enabled = true
+references:
+  - https://learn.microsoft.com/azure/aks/use-azure-policy

skyveda/checks/azure/AZ-AKS-007.yaml

@@ -0,0 +1,30 @@
+schema_version: 1
+id: AZ-AKS-007
+title: AKS clusters have an automatic upgrade channel set
+provider: azure
+area: reliability
+severity: medium
+tier: free
+source:
+  type: resource_graph
+  query: |
+    resources
+    | where type =~ 'microsoft.containerservice/managedclusters'
+    | extend upgradeChannel = tolower(tostring(properties.autoUpgradeProfile.upgradeChannel))
+    // A missing channel becomes '' and fails, exactly like 'none'.
+    | project id, name, resourceGroup, location, upgradeChannel,
+              compliant = upgradeChannel in ('patch', 'stable', 'rapid', 'node-image')
+why: >-
+  A cluster with no upgrade channel stays on its Kubernetes version until someone remembers to
+  upgrade it. Old versions fall out of support and miss security patches.
+fix:
+  summary: Set an automatic upgrade channel, for example patch or stable.
+  steps:
+    - Pick a channel. "patch" applies only security and bug-fix releases and is the safest start.
+    - Set a planned maintenance window so upgrades happen at a quiet time.
+  cli: az aks update -g <resource-group> -n <cluster> --auto-upgrade-channel patch
+  terraform: |
+    # azurerm_kubernetes_cluster
+    automatic_upgrade_channel = "patch"
+references:
+  - https://learn.microsoft.com/azure/aks/auto-upgrade-cluster

skyveda/checks/azure/AZ-AKS-008.yaml

@@ -0,0 +1,33 @@
+schema_version: 1
+id: AZ-AKS-008
+title: AKS clusters enforce a network policy
+provider: azure
+area: network
+severity: medium
+tier: free
+source:
+  type: resource_graph
+  query: |
+    resources
+    | where type =~ 'microsoft.containerservice/managedclusters'
+    | extend networkPolicy = tolower(tostring(properties.networkProfile.networkPolicy))
+    // A missing value becomes '' and fails, exactly like 'none'.
+    | project id, name, resourceGroup, location, networkPolicy,
+              compliant = networkPolicy in ('azure', 'calico', 'cilium')
+why: >-
+  With no network policy every pod can talk to every other pod. One compromised workload can then
+  reach databases and internal services across the cluster.
+fix:
+  summary: Use a network policy engine (Azure, Calico or Cilium) and write policies per namespace.
+  steps:
+    - The network policy is chosen at cluster creation, so most clusters need a replacement cluster.
+    - Start with a default-deny policy in each namespace, then allow the traffic that is needed.
+  cli: az aks create -g <resource-group> -n <cluster> --network-plugin azure --network-policy azure
+  terraform: |
+    # azurerm_kubernetes_cluster
+    network_profile {
+      network_plugin = "azure"
+      network_policy = "azure"
+    }
+references:
+  - https://learn.microsoft.com/azure/aks/use-network-policies

skyveda/checks/azure/AZ-AKS-009.yaml

@@ -0,0 +1,31 @@
+schema_version: 1
+id: AZ-AKS-009
+title: AKS clusters have Kubernetes RBAC enabled
+provider: azure
+area: kubernetes
+severity: high
+tier: free
+source:
+  type: resource_graph
+  query: |
+    // properties.enableRBAC: clusters created without it cannot turn it on later. A missing value FAILS.
+    resources
+    | where type =~ 'microsoft.containerservice/managedclusters'
+    | extend enableRBAC = tobool(properties.enableRBAC)
+    | project id, name, resourceGroup, location, enableRBAC,
+              compliant = coalesce(enableRBAC, false)
+why: >-
+  Without Kubernetes RBAC, anyone who can reach the API server with valid credentials can do
+  anything in the cluster: read every secret, run any workload and change every setting. Roles
+  are the only way to give a team or a pod less than full control.
+fix:
+  summary: Recreate the cluster with Kubernetes RBAC enabled (it cannot be turned on in place).
+  steps:
+    - Create a new cluster with RBAC and, ideally, Entra ID integration.
+    - Define roles and role bindings for each team and service account.
+    - Move workloads to the new cluster, then delete the old one.
+  terraform: |
+    # azurerm_kubernetes_cluster
+    role_based_access_control_enabled = true
+references:
+  - https://learn.microsoft.com/azure/aks/concepts-identity#kubernetes-rbac

skyveda/checks/azure/AZ-AKS-010.yaml

@@ -0,0 +1,35 @@
+schema_version: 1
+id: AZ-AKS-010
+title: AKS clusters have workload identity enabled
+provider: azure
+area: kubernetes
+severity: low
+tier: free
+source:
+  type: resource_graph
+  query: |
+    // properties.securityProfile.workloadIdentity.enabled; it needs the OIDC issuer, shown as
+    // evidence. A missing value means not enabled and FAILS.
+    resources
+    | where type =~ 'microsoft.containerservice/managedclusters'
+    | extend workloadIdentity = tobool(properties.securityProfile.workloadIdentity.enabled),
+             oidcIssuer = tobool(properties.oidcIssuerProfile.enabled)
+    | project id, name, resourceGroup, location, workloadIdentity, oidcIssuer,
+              compliant = coalesce(workloadIdentity, false)
+why: >-
+  Without workload identity, pods that call Azure usually carry a client secret or connection
+  string, stored as a Kubernetes secret, that can leak and is rarely rotated. Workload identity
+  lets each pod use an Entra ID identity instead, with no secret to steal.
+fix:
+  summary: Enable the OIDC issuer and workload identity, then move pods off stored secrets.
+  steps:
+    - Enable the OIDC issuer and workload identity on the cluster.
+    - For each app, create a managed identity with a federated credential for its service account.
+    - Replace the app's stored secrets with the identity, then delete the secrets.
+  cli: az aks update -g <resource-group> -n <cluster> --enable-oidc-issuer --enable-workload-identity
+  terraform: |
+    # azurerm_kubernetes_cluster
+    oidc_issuer_enabled       = true
+    workload_identity_enabled = true
+references:
+  - https://learn.microsoft.com/azure/aks/workload-identity-overview

skyveda/checks/azure/AZ-COSMOS-001.yaml

@@ -0,0 +1,32 @@
+schema_version: 1
+id: AZ-COSMOS-001
+title: Cosmos DB accounts disable key-based authentication
+provider: azure
+area: identity
+severity: medium
+tier: free
+source:
+  type: resource_graph
+  query: |
+    // properties.disableLocalAuth defaults to false (keys allowed). A missing value FAILS.
+    resources
+    | where type =~ 'microsoft.documentdb/databaseaccounts'
+    | extend disableLocalAuth = tobool(properties.disableLocalAuth), apiKind = tostring(kind)
+    | project id, name, resourceGroup, location, apiKind, disableLocalAuth,
+              compliant = coalesce(disableLocalAuth, false)
+why: >-
+  An account key gives full read and write access to every database in the account, never expires
+  on its own, and does not say who used it. Keys end up in config files and scripts and are hard
+  to rotate. Entra ID roles are scoped, audited and removed when a person leaves.
+fix:
+  summary: Move applications to Entra ID role-based access, then disable key-based authentication.
+  steps:
+    - Grant each application a Cosmos DB data-plane role (for example Cosmos DB Built-in Data Contributor).
+    - Change the applications to authenticate with their managed identity instead of a key.
+    - Disable local (key-based) authentication on the account.
+  cli: az cosmosdb update -g <resource-group> -n <account> --disable-local-auth true
+  terraform: |
+    # azurerm_cosmosdb_account
+    local_authentication_enabled = false
+references:
+  - https://learn.microsoft.com/azure/cosmos-db/how-to-setup-rbac#disable-local-auth

skyveda/checks/azure/AZ-COSMOS-002.yaml

@@ -0,0 +1,35 @@
+schema_version: 1
+id: AZ-COSMOS-002
+title: Cosmos DB accounts are not open to all networks
+provider: azure
+area: network
+severity: high
+tier: free
+source:
+  type: resource_graph
+  query: |
+    // Compliant when public network access is Disabled, or when an IP or virtual network filter
+    // limits it. A missing publicNetworkAccess is read as Enabled (the Azure default) and FAILS.
+    // Any IP rule counts as a limit, even a broad one; the rule count is shown as evidence.
+    resources
+    | where type =~ 'microsoft.documentdb/databaseaccounts'
+    | extend publicNetworkAccess = coalesce(tostring(properties.publicNetworkAccess), 'Enabled'),
+             ipRules = coalesce(array_length(properties.ipRules), 0),
+             vnetFilter = coalesce(tobool(properties.isVirtualNetworkFilterEnabled), false)
+    | project id, name, resourceGroup, location, publicNetworkAccess, ipRules, vnetFilter,
+              compliant = publicNetworkAccess =~ 'Disabled' or ipRules > 0 or vnetFilter
+why: >-
+  An account that accepts connections from any network relies on its keys alone. A leaked key can
+  then be used from anywhere on the Internet to read or change every database in the account.
+fix:
+  summary: Use private endpoints and disable public access, or limit public access to known networks.
+  steps:
+    - List the networks and addresses that must reach the account.
+    - Add a private endpoint, or add IP and virtual network rules in the account's Networking settings.
+    - Set public network access to Disabled, or to selected networks only.
+  cli: az cosmosdb update -g <resource-group> -n <account> --public-network-access Disabled
+  terraform: |
+    # azurerm_cosmosdb_account
+    public_network_access_enabled = false
+references:
+  - https://learn.microsoft.com/azure/cosmos-db/how-to-configure-firewall

skyveda/checks/azure/AZ-COST-001.yaml

@@ -0,0 +1,32 @@
+schema_version: 1
+id: AZ-COST-001
+title: No unattached managed disks
+provider: azure
+area: cost
+severity: medium
+tier: pro
+source:
+  type: resource_graph
+  query: |
+    // Approximate list prices in INR per GB-month (assumption; replaced by billed cost at MVP):
+    // Premium 13, Standard SSD 7, Standard HDD 4. Inlined: Resource Graph rejects `let`.
+    resources
+    | where type =~ 'microsoft.compute/disks'
+    | extend diskState = tostring(properties.diskState), sizeGb = toint(properties.diskSizeGB), sku = tostring(sku.name)
+    | extend compliant = diskState !~ 'Unattached'
+    | extend estMonthlyWasteInr = iff(compliant, 0.0, todouble(sizeGb) *
+        case(sku startswith 'Premium', 13.0, sku startswith 'StandardSSD', 7.0, 4.0))
+    | project id, name, resourceGroup, location, diskState, sizeGb, sku, compliant, estMonthlyWasteInr
+cost:
+  field: estMonthlyWasteInr
+why: >-
+  An unattached disk is billed every month for its full size but serves no workload. They are
+  usually left behind when virtual machines are deleted.
+fix:
+  summary: Snapshot the disk if its data may be needed, then delete it.
+  steps:
+    - Confirm with the owner that the data is not needed, or take a snapshot first.
+    - Delete the disk.
+  cli: az disk delete -g <resource-group> -n <disk>
+references:
+  - https://learn.microsoft.com/azure/virtual-machines/disks-find-unattached-portal

skyveda/checks/azure/AZ-COST-002.yaml

@@ -0,0 +1,29 @@
+schema_version: 1
+id: AZ-COST-002
+title: No unused public IP addresses
+provider: azure
+area: cost
+severity: low
+tier: pro
+source:
+  type: resource_graph
+  query: |
+    // Approximate list price of a Standard static public IP: INR 320 per month (assumption).
+    // Inlined: Resource Graph rejects `let`.
+    resources
+    | where type =~ 'microsoft.network/publicipaddresses'
+    | extend attachedTo = coalesce(tostring(properties.ipConfiguration.id), tostring(properties.natGateway.id)),
+             sku = tostring(sku.name), allocation = tostring(properties.publicIPAllocationMethod)
+    | extend compliant = isnotempty(attachedTo)
+    | extend estMonthlyWasteInr = iff(compliant, 0.0, 320.0)
+    | project id, name, resourceGroup, location, sku, allocation, compliant, estMonthlyWasteInr
+cost:
+  field: estMonthlyWasteInr
+why: >-
+  A static public IP that is not attached to anything is still billed, and an unused public
+  address is easy to forget and later attach to the wrong resource.
+fix:
+  summary: Delete public IPs that are not attached to a network interface, load balancer or NAT gateway.
+  cli: az network public-ip delete -g <resource-group> -n <public-ip>
+references:
+  - https://learn.microsoft.com/azure/virtual-network/ip-services/public-ip-addresses

skyveda/checks/azure/AZ-COST-003.yaml

@@ -0,0 +1,28 @@
+schema_version: 1
+id: AZ-COST-003
+title: Stopped virtual machines are deallocated
+provider: azure
+area: cost
+severity: medium
+tier: pro
+source:
+  type: resource_graph
+  query: |
+    resources
+    | where type =~ 'microsoft.compute/virtualmachines'
+    | extend powerState = tostring(properties.extended.instanceView.powerState.code),
+             vmSize = tostring(properties.hardwareProfile.vmSize)
+    | project id, name, resourceGroup, location, vmSize, powerState,
+              compliant = powerState != 'PowerState/stopped'
+cost:
+  # No list price: VM sizes and licences vary too much. The VM's billed cost is its compute.
+  field: null
+  basis: billed cost only
+why: >-
+  A VM shut down from inside the operating system is "stopped" but still allocated, so its compute
+  is billed in full. Only a deallocated VM stops compute charges.
+fix:
+  summary: Deallocate the VM from Azure (Stop in the portal), or delete it if no longer needed.
+  cli: az vm deallocate -g <resource-group> -n <vm>
+references:
+  - https://learn.microsoft.com/azure/virtual-machines/states-billing

skyveda/checks/azure/AZ-COST-004.yaml

@@ -0,0 +1,29 @@
+schema_version: 1
+id: AZ-COST-004
+title: No disk snapshots older than 90 days
+provider: azure
+area: cost
+severity: low
+tier: pro
+source:
+  type: resource_graph
+  query: |
+    // Snapshots older than 90 days; approximate list price INR 4.4 per GB-month (assumption).
+    // Inlined: Resource Graph rejects `let`.
+    resources
+    | where type =~ 'microsoft.compute/snapshots'
+    | extend created = todatetime(properties.timeCreated), sizeGb = toint(properties.diskSizeGB)
+    | extend ageDays = datetime_diff('day', now(), created)
+    | extend compliant = ageDays <= 90
+    | extend estMonthlyWasteInr = iff(compliant, 0.0, todouble(sizeGb) * 4.4)
+    | project id, name, resourceGroup, location, sizeGb, ageDays, compliant, estMonthlyWasteInr
+cost:
+  field: estMonthlyWasteInr
+why: >-
+  Snapshots are often taken before a change and then forgotten. Old snapshots keep billing every
+  month long after anyone could need them.
+fix:
+  summary: Delete snapshots that are no longer needed, and use Azure Backup policies for retention.
+  cli: az snapshot delete -g <resource-group> -n <snapshot>
+references:
+  - https://learn.microsoft.com/azure/virtual-machines/snapshot-copy-managed-disk

skyveda/checks/azure/AZ-COST-005.yaml

@@ -0,0 +1,28 @@
+schema_version: 1
+id: AZ-COST-005
+title: No paid App Service plans without apps
+provider: azure
+area: cost
+severity: medium
+tier: pro
+source:
+  type: resource_graph
+  query: |
+    resources
+    | where type =~ 'microsoft.web/serverfarms'
+    | extend tier = tostring(sku.tier), skuName = tostring(sku.name), sites = toint(properties.numberOfSites)
+    | where tier !in~ ('Free', 'Shared')
+    | project id, name, resourceGroup, location, tier, skuName, sites,
+              compliant = coalesce(sites, 0) > 0
+cost:
+  # No list price: plan tiers and instance counts vary too much. The plan's bill is the waste.
+  field: null
+  basis: billed cost only
+why: >-
+  A paid App Service plan is billed whether or not any app runs on it. Empty plans are usually
+  left over after apps are moved or deleted.
+fix:
+  summary: Delete empty plans, or move apps from other plans onto them.
+  cli: az appservice plan delete -g <resource-group> -n <plan>
+references:
+  - https://learn.microsoft.com/azure/app-service/overview-hosting-plans