LoFP LoFP / kubernetes

kubernetes rule

TitleTags
a misconfigured rbac policy, a mistake by a valid user, or a wider issue with authentication tokens can also generate these errors.
an administrator may need to exec into a pod for a legitimate reason like debugging purposes. containers built from linux and windows os images, tend to include debugging utilities. in this case, an admin may choose to run commands inside a specific container with kubectl exec ${pod_name} -c ${container_name} -- ${cmd} ${arg1} ${arg2} ... ${argn}. for example, the following command can be used to look at logs from a running cassandra pod: kubectl exec cassandra --cat /var/log/cassandra/system.log . additionally, the -i and -t arguments might be used to run a shell connected to the terminal: kubectl exec -i -t cassandra -- sh
an administrator may submit this request as an \"impersonateduser\" to determine what privileges a particular service account has been granted. however, an adversary may utilize the same technique as a means to determine the privileges of another token other than that of the compromised account.
anonymous access to the api server is a dangerous setting enabled by default. common anonymous connections (e.g., health checks) have been excluded from this rule. all other instances of authorized anonymous requests should be investigated.
approved certificate workflows (for example cert-manager, internal pki rotation, or node bootstrap) may create or update csrs from identities not in the exclusion list if they run under a custom service account. baseline automation that legitimately approves csrs and tune exclusions for those principals.
authorized administrative maintenance via kubectl
automated internal infrastructure monitoring and certificate rotation
automated processes may need to take these actions and may need to be filtered.
azure arc system components may create or update secrets and configmaps in the azure-arc and azure-arc-release namespaces during normal cluster management. filter by namespace to exclude these.
cluster administrators may legitimately update coredns configuration for forwarding, stub domains, or cluster dns troubleshooting. baseline approved operators and automation identities; tune exclusions for known change pipelines.
cluster operators and gitops automation may legitimately install or upgrade admission controllers (e.g. cert-manager, gatekeeper, kyverno, service mesh components). validate change tickets and approved controllers before tuning.
cluster operators or sres may legitimately use ephemeral containers for debugging production workloads. baseline approved admin identities and tune exclusions for known automation.
controller service accounts aren't normally assigned to running pods, this is abnormal behavior with very few legitimate use-cases and should result in very few false positives.
developers may have a legitimate use for nodeports. for frontend parts of an application you may want to expose a service onto an external ip address without using cloud specific loadbalancers. nodeport can be used to expose the service on each node's ip at a static port (the nodeport). you'll be able to contact the nodeport service from outside the cluster, by requesting <nodeip>:<nodeport>. nodeport unlike loadbalancers, allow the freedom to set up your own load balancing solution, configure environments that aren't fully supported by kubernetes, or even to expose one or more node's ips directly.
helm operations managed through arc may create release secrets (prefixed with sh.helm.release.v1). these are normal arc lifecycle operations.
in-cluster operators, csi drivers, gitops agents, and some platform controllers legitimately list or get secrets in namespaces they manage; exclude known service accounts, namespaces, or user agents after baselining.
internal automation built with generic libraries can resemble suspicious user agents; baseline known jobs and tune by service account, namespace, or stable source ip allowlists.
legitimate debugging activity. investigate the identity performing the requests and their authorization.
legitimate node group lifecycle, cluster upgrades, or infrastructure-as-code (terraform, cloudformation, eksctl) may update aws-auth during expected change windows. baseline automation identities and expand exclusions beyond eks:kms-storage-migrator if your environment uses additional known controllers.
modifying a kubernetes job or cronjob may need to be done by a system administrator.
modifying a kubernetes rolebinding may need to be done by a system administrator.
modifying the kubernetes admission controller may need to be done by a system administrator.
new automation, admission webhooks, or platform agents that legitimately call the tokenrequest api under a non-standard user string may require narrow exclusions by user.name or source ip.
operators may use ad hoc http clients, scripts, or penetration-test images during approved exercises or break-glass maintenance; validate tickets, source ip, and identity before treating as compromise.
platform installers, gitops controllers, and emergency break-glass roles sometimes ship or widen wildcard clusterroles; correlate with change records and narrow by user or service account when baselined.
rare kubelet or node maintenance tooling may touch secret apis; validate against change windows and approved node management paths.
security-approved vulnerability or secret scanning in devsecops pipelines
system components such as daemon-set-controller and kube-scheduler also create pods in the kube-system namespace
the daemonset controller creates pods with hostpath volumes within the kube-system namespace.
the kubernetes dashboard occasionally accesses the kubernetes-dashboard-key-holder secret
unknown