« Azure AKS CoreDNS or Kube-DNS Configuration Modified Azure AKS Secret get or list with Suspicious User Agent »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.29

Azure AKS Certificate Signing Request Created or Approved

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Azure AKS Certificate Signing Request Created or Approved

edit

Detects an identity creating a client-authentication CertificateSigningRequest (signer kubernetes.io/kube-apiserver-client) or approving a CSR on AKS (Azure Kubernetes Service), excluding node bootstrap and platform controllers. Adversaries submit and self-approve a CSR against the kube-apiserver-client signer to mint a long-lived client certificate for an arbitrary subject (for example a Common Name in system:masters), giving durable authenticated access that survives token revocation. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token forging a certificate is not excluded.

Rule type: query

Rule indices:

  • logs-azure.platformlogs-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Domain: Kubernetes
  • Data Source: Azure
  • Data Source: Azure Platform Logs
  • Data Source: Kubernetes
  • Use Case: Threat Detection
  • Tactic: Credential Access
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Azure AKS Certificate Signing Request Created or Approved

AKS kube-audit events are carried under the flattened azure.platformlogs.properties.log.* subtree and share the ARM operation event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read. A CSR created against the kubernetes.io/kube-apiserver-client signer lets the requester choose the certificate’s subject (Common Name and organization/groups); once approved it mints a client certificate for an arbitrary identity that yields access not tied to a token. The default CertificateSubjectRestriction admission controller blocks requests for the system:masters group, so attackers commonly request a Common Name matching an existing privileged user (or another privileged group) instead, making the requested subject the key thing to decode. Node and kubelet certificates use the kube-apiserver-client-kubelet and kubelet-serving signers (whose subject is constrained to the node) and are out of scope; cert-manager and application CSRs use their own signers.

Possible investigation steps

  • Identify the requesting identity in azure.platformlogs.properties.log.user.username (and its groups in azure.platformlogs.properties.log.user.groups) and whether it should submit or approve CSRs. A workload service account (system:serviceaccount:<ns>:<sa>) or masterclient (the local cluster-admin cert) is the higher-concern case.
  • Confirm the signer in azure.platformlogs.properties.log.requestObject.spec.signerName and decode the base64 CSR in azure.platformlogs.properties.log.requestObject.spec.request to read the requested Common Name and organization (groups); a subject in system:masters or another privileged group is the escalation.
  • Determine whether the same or a related identity approved the CSR (verb:update/patch on the approval subresource), which indicates self-approval, and inspect azure.platformlogs.properties.log.userAgent.
  • Evaluate the source in azure.platformlogs.properties.log.sourceIPs and pivot on it for follow-on privileged API activity using the newly issued certificate.

False positive analysis

  • Node bootstrap (kube-apiserver-client-kubelet signer), kubelet-serving CSRs, and cert-manager/application CSRs (custom signers) are out of scope by design; the kube-controller-manager certificate-controller and the AKS aksService approver are excluded by identity.
  • Manual CSR approval by an administrator, or an operator that legitimately mints client certificates, may surface; baseline those identities and exclude the specific validated account rather than re-broadening to all system:*, which would blind the rule to compromised workload service accounts.

Response and remediation

  • If unauthorized, deny or delete the CSR, revoke the issued certificate, and rotate the cluster CA if a privileged certificate was minted.
  • Review the RBAC that allowed CSR creation and approval, and audit actions taken with the certificate.
  • Collect kube-audit and identity artifacts per incident response procedures.

Setup

edit

The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the azure.platformlogs data stream is required for this rule. Enable either the kube-audit or the kube-audit-admin log category (Microsoft recommends kube-audit-admin alone to reduce volume, as it only drops read-only get/list events). CSR create and approval are mutating operations recorded in both categories with the same auditID, so clusters that enable both categories may generate two alerts per event.

Rule query

edit
data_stream.dataset:azure.platformlogs and
  event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and
  azure.platformlogs.category:("kube-audit" or "kube-audit-admin") and
  azure.platformlogs.properties.log.stage:"ResponseComplete" and
  azure.platformlogs.properties.log.objectRef.resource:"certificatesigningrequests" and
  azure.platformlogs.properties.log.responseStatus.code: "200" and
  azure.platformlogs.properties.log.requestObject.status.conditions.type: "Approved" and
  (
    (
      azure.platformlogs.properties.log.verb:"create" and
      azure.platformlogs.properties.log.requestObject.spec.signerName:"kubernetes.io/kube-apiserver-client"
    ) or (
      azure.platformlogs.properties.log.verb:("update" or "patch") and
      azure.platformlogs.properties.log.objectRef.subresource:"approval"
    )
  ) and
  not azure.platformlogs.properties.log.user.username:(
    system\:node\:* or system\:bootstrap\:* or "aksService" or "hcpService" or
    "readinessChecker" or system\:serviceaccount\:kube-system\:*
  )

Framework: MITRE ATT&CKTM

« Azure AKS CoreDNS or Kube-DNS Configuration Modified Azure AKS Secret get or list with Suspicious User Agent »