|
| 1 | +# Security Agent Readiness Guardrail |
| 2 | + |
| 3 | +This guide demonstrates how to use the Node Readiness Controller to prevent workloads from being scheduled on a node until a security agent (for example, [Falco](https://github.com/falcosecurity/falco)) is fully initialized and actively monitoring the node. |
| 4 | + |
| 5 | +## The Problem |
| 6 | + |
| 7 | +In many Kubernetes clusters, security agents are deployed as DaemonSets. When a new node joins the cluster, there is a race condition: |
| 8 | +1. A new node joins the cluster and is marked `Ready` by the kubelet. |
| 9 | +2. The scheduler sees the node as `Ready` and considers the node eligible for workloads. |
| 10 | +3. However, the security agent on that node may still be starting or initializing. |
| 11 | + |
| 12 | +**Result**: Application workloads may start running before node is security compliant, creating a blind spot where runtime threats, policy violations, or anomalous behavior may go undetected. |
| 13 | + |
| 14 | +## The Solution |
| 15 | + |
| 16 | +We can use the Node Readiness Controller to enforce a security readiness guardrail: |
| 17 | +1. **Taint** the node with a [startup taint](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) `readiness.k8s.io/falco.org/security-agent-ready=pending:NoSchedule` as soon as it joins the cluster. |
| 18 | +2. **Monitor** the security agent’s readiness using a sidecar and expose it as a Node Condition. |
| 19 | +3. **Untaint** the node only after the security agent reports that it is ready. |
| 20 | + |
| 21 | +## Step-by-Step Guide (Falco Example) |
| 22 | + |
| 23 | +This example uses **Falco** as a representative security agent, but the same pattern applies to any node-level security or monitoring agent. |
| 24 | + |
| 25 | +> **Note**: All manifests referenced in this guide are available in the [`examples/security-agent-readiness`](https://github.com/kubernetes-sigs/node-readiness-controller/tree/main/examples/security-agent-readiness) directory. |
| 26 | +
|
| 27 | + |
| 28 | + |
| 29 | +### 1. Deploy the Readiness Condition Reporter |
| 30 | + |
| 31 | +To bridge the security agent’s internal health signal to Kubernetes, we deploy a readiness reporter that updates a Node Condition. In this example, the reporter is deployed as a sidecar container in the Falco DaemonSet. Components that natively update Node conditions would not require this additional container. |
| 32 | + |
| 33 | +This sidecar periodically checks Falco's local health endpoint (`http://localhost:8765/healthz`) and updates a Node Condition `falco.org/FalcoReady`. |
| 34 | + |
| 35 | +**Patch your Falco DaemonSet:** |
| 36 | + |
| 37 | +```yaml |
| 38 | +# security-agent-reporter-sidecar.yaml |
| 39 | +- name: security-status-patcher |
| 40 | + image: registry.k8s.io/node-readiness-controller/node-readiness-reporter:v0.1.1 |
| 41 | + imagePullPolicy: IfNotPresent |
| 42 | + env: |
| 43 | + - name: NODE_NAME |
| 44 | + valueFrom: |
| 45 | + fieldRef: |
| 46 | + fieldPath: spec.nodeName |
| 47 | + - name: CHECK_ENDPOINT |
| 48 | + value: "http://localhost:8765/healthz" # Update the right security agent endpoint |
| 49 | + - name: CONDITION_TYPE |
| 50 | + value: "falco.org/FalcoReady" # Update the right condition |
| 51 | + - name: CHECK_INTERVAL |
| 52 | + value: "5s" |
| 53 | + resources: |
| 54 | + limits: |
| 55 | + cpu: "10m" |
| 56 | + memory: "32Mi" |
| 57 | + requests: |
| 58 | + cpu: "10m" |
| 59 | + memory: "32Mi" |
| 60 | +``` |
| 61 | +
|
| 62 | +> Note: In this example, the security agent’s health is monitored by a side-car, so the reporter’s lifecycle is the same as the pod lifecycle. If the Falco pod is crashlooping, the sidecar will not run and cannot report readiness. For robust `continuous` readiness reporting, the reporter should be deployed independently of the security agent pod. For example, a separate DaemonSet (similar to Node Problem Detector) can monitor the agent and update Node conditions even if the agent pod crashes. |
| 63 | + |
| 64 | +### 2. Grant Permissions (RBAC) |
| 65 | + |
| 66 | +The readiness reporter sidecar needs permission to update the Node object's status to publish readiness information. |
| 67 | + |
| 68 | +```yaml |
| 69 | +# security-agent-node-status-rbac.yaml |
| 70 | +apiVersion: rbac.authorization.k8s.io/v1 |
| 71 | +kind: ClusterRole |
| 72 | +metadata: |
| 73 | + name: node-status-patch-role |
| 74 | +rules: |
| 75 | +- apiGroups: [""] |
| 76 | + resources: ["nodes"] |
| 77 | + verbs: ["get"] |
| 78 | +- apiGroups: [""] |
| 79 | + resources: ["nodes/status"] |
| 80 | + verbs: ["patch", "update"] |
| 81 | +--- |
| 82 | +apiVersion: rbac.authorization.k8s.io/v1 |
| 83 | +kind: ClusterRoleBinding |
| 84 | +metadata: |
| 85 | + name: security-agent-node-status-patch-binding |
| 86 | +roleRef: |
| 87 | + apiGroup: rbac.authorization.k8s.io |
| 88 | + kind: ClusterRole |
| 89 | + name: node-status-patch-role |
| 90 | +subjects: |
| 91 | +# Bind to security agent's ServiceAccount |
| 92 | +- kind: ServiceAccount |
| 93 | + name: falco |
| 94 | + namespace: kube-system |
| 95 | +``` |
| 96 | + |
| 97 | +### 3. Create the Node Readiness Rule |
| 98 | + |
| 99 | +Next, define a NodeReadinessRule that enforces the security readiness requirement. This rule instructs the controller: *"Keep the `readiness.k8s.io/falco.org/security-agent-ready` taint on the node until the `falco.org/FalcoReady` condition becomes True."* |
| 100 | + |
| 101 | +```yaml |
| 102 | +# security-agent-readiness-rule.yaml |
| 103 | +apiVersion: readiness.node.x-k8s.io/v1alpha1 |
| 104 | +kind: NodeReadinessRule |
| 105 | +metadata: |
| 106 | + name: security-agent-readiness-rule |
| 107 | +spec: |
| 108 | + # Conditions that must be satisfied before the taint is removed |
| 109 | + conditions: |
| 110 | + - type: "falco.org/FalcoReady" |
| 111 | + requiredStatus: "True" |
| 112 | +
|
| 113 | + # Taint managed by this rule |
| 114 | + taint: |
| 115 | + key: "readiness.k8s.io/falco.org/security-agent-ready" |
| 116 | + effect: "NoSchedule" |
| 117 | + value: "pending" |
| 118 | +
|
| 119 | + # "bootstrap-only" means: once the security agent is ready, we stop enforcing. |
| 120 | + # Use "continuous" mode if you want to taint the node if security agent crashes later. |
| 121 | + enforcementMode: "bootstrap-only" |
| 122 | +
|
| 123 | + # Update to target only the nodes that need to be protected by this guardrail |
| 124 | + nodeSelector: |
| 125 | + matchLabels: |
| 126 | + node-role.kubernetes.io/worker: "" |
| 127 | +``` |
| 128 | + |
| 129 | +## How to Apply |
| 130 | + |
| 131 | +1. **Create the Node Readiness Rule**: |
| 132 | +```sh |
| 133 | + cd examples/security-agent-readiness |
| 134 | + kubectl apply -f security-agent-readiness-rule.yaml |
| 135 | + ``` |
| 136 | + |
| 137 | +2. **Install Falco and Apply the RBAC**: |
| 138 | +```sh |
| 139 | +chmod +x apply-falco.sh |
| 140 | +sh apply-falco.sh |
| 141 | +``` |
| 142 | + |
| 143 | +## Verification |
| 144 | + |
| 145 | +To verify that the guardrail is working, add a new node to the cluster. |
| 146 | + |
| 147 | +1. **Check the Node Taints**: |
| 148 | +Immediately after the node joins, it should have the taint: |
| 149 | +`readiness.k8s.io/falco.org/security-agent-ready=pending:NoSchedule`. |
| 150 | + |
| 151 | +2. **Check Node Conditions**: |
| 152 | +Observe the node’s conditions. You will initially see `falco.org/FalcoReady` as `False` or missing. Once Falco initializes, the sidecar reporter updates the condition to `True`. |
| 153 | + |
| 154 | +3. **Check Taint Removal**: |
| 155 | +As soon as the condition becomes `True`, the Node Readiness Controller removes the taint, allowing workloads to be scheduled on the node. |
0 commit comments