Agent Kubernetes Access and Network Policy
Agents run untrusted, model-driven workloads, so by default they get no Kubernetes API access at all: the ServiceAccount token is not mounted and no RBAC bindings exist. When an agent needs to inspect or manage cluster resources, grant it exactly the access it needs from Settings → Security on the agent detail page.
Kubernetes access
Section titled “Kubernetes access”Edka provisions a dedicated ServiceAccount for the agent and binds it according to the selected preset. The agent’s pods run as that identity; the token is only mounted when a preset other than None is active.
| Preset | What the agent can do |
|---|---|
| None | Nothing. Token automount is disabled and no RBAC bindings exist. This is the default. |
| Read-only | Read resources through the built-in view role, cluster-wide or in selected namespaces. |
| Write | Edit resources through the built-in edit role in selected namespaces only, with cluster-wide read. |
| Custom | Exactly the rules you define in the policy table, applied namespaced or cluster-wide. |
The Read-only and Write presets bind Kubernetes’ built-in aggregated
view and edit cluster roles, so they automatically cover new resource
types as the cluster evolves. Namespace confinement comes from the binding: a
namespaced grant creates a RoleBinding per selected namespace, so the same
role definition applies only where you granted it. Namespaces that do not
exist yet are created on apply.
The cluster-wide read from view deliberately excludes Secrets; edit can
read Secrets only inside its granted namespaces. Neither role allows changing
RBAC.
Custom rules
Section titled “Custom rules”The Custom preset creates an Edka-managed Role (namespaced) or ClusterRole (cluster scope) from the policy table. Each rule sets:
| Field | Example |
|---|---|
| API groups | apps, batch |
| Resources | pods, deployments |
| Verbs | get, list, watch |
| Resource names | optional |
Cluster-scoped custom rules are the widest grant Edka supports, so saving one requires step-up verification. Re-saving other settings later does not ask again; only granting or changing the cluster-scoped rules does.
Restricted namespaces
Section titled “Restricted namespaces”Grants can never target kube-system, kube-public, kube-node-lease, or
edka-system. Write access there would escalate beyond the grant — edit
allows running pods as any ServiceAccount in the namespace — so Edka rejects
these namespaces at validation and hides them from the namespace picker.
What Edka creates
Section titled “What Edka creates”All provisioned objects are named after the agent’s instance slug so they are
recognizable in kubectl output, and labeled edka.io/agent-security=true
plus the app id for machine identification:
| Object | Name |
|---|---|
| ServiceAccount | edka-<instance-slug> |
| Read bindings | edka-<instance-slug>-view |
| Write bindings | edka-<instance-slug>-edit |
| Custom role and binding | edka-<instance-slug>-custom |
| API-server egress policy | edka-<instance-slug>-apiserver-egress |
The Security tab lists the resources provisioned by the last apply, so you can see the effective state without leaving Edka.
Network policy
Section titled “Network policy”The Network Policy section controls the NetworkPolicies Edka manages for the agent’s pods:
- a base isolation policy from the agent’s catalog definition
- an API-server egress allowance, created automatically when Kubernetes access is enabled so the agent can reach the API server and nothing gains wider egress than that
- optional guided ingress and egress rules you define with CIDRs, namespace labels, pod labels, and ports
The API-server endpoints are discovered from the cluster at apply time and re-converged every few minutes, so control-plane changes do not cut the agent off from the API.
Turning the toggle off removes every NetworkPolicy for the agent — its pods then have unrestricted network access, and the Security tab says so prominently. RBAC still applies either way.
NetworkPolicy enforcement depends on the cluster’s CNI. Edka clusters use Cilium, which enforces these policies; the tab warns if the cluster’s CNI is not known to enforce them.
Lifecycle and auditing
Section titled “Lifecycle and auditing”- Access changes apply on the next agent update and take effect without restarting the agent’s pods; only switching between None and an active preset rolls the pod once to change token mounting.
- Settings persist across updates. Leaving the Security tab untouched while editing other configuration never changes the granted access; revoking requires explicitly selecting None.
- Uninstalling the agent removes every provisioned RBAC object and NetworkPolicy, including any left behind by earlier configurations.
- Every grant, change, and revoke is recorded in the audit log with the previous and new access, the actor, and the affected namespaces.