Introduction

Running Fluentd as a DaemonSet is a common Kubernetes logging pattern, but collecting logs and enriching them with Kubernetes metadata are separate concerns. Fluentd can read files from the node without API access, yet metadata filters often need RBAC permissions to read pods, namespaces, and sometimes nodes.

Know When RBAC Is Actually Required

Fluentd can tail files under paths such as /var/log/containers using host mounts alone. RBAC becomes necessary when the configuration asks Fluentd to query the Kubernetes API for metadata such as:

• pod name and namespace
• labels and annotations
• container identity
• node-related information

That distinction helps during debugging. If raw log lines are arriving but fields such as namespace or labels are missing, the problem is often RBAC or metadata-plugin configuration rather than the output sink.

Create a Dedicated Service Account

Start by creating a dedicated service account for the log collector instead of using the namespace default account.

1apiVersion: v1
2kind: Namespace
3metadata:
4  name: logging
5---
6apiVersion: v1
7kind: ServiceAccount
8metadata:
9  name: fluentd
10  namespace: logging

This makes access review easier and avoids giving broad permissions to unrelated workloads.

Grant Read-Only RBAC Permissions

For the common Kubernetes metadata filter, read-only API access is usually enough.

1apiVersion: rbac.authorization.k8s.io/v1
2kind: ClusterRole
3metadata:
4  name: fluentd-metadata-reader
5rules:
6  - apiGroups: [""]
7    resources: ["pods", "namespaces"]
8    verbs: ["get", "list", "watch"]
9  - apiGroups: [""]
10    resources: ["nodes"]
11    verbs: ["get", "list", "watch"]
12---
13apiVersion: rbac.authorization.k8s.io/v1
14kind: ClusterRoleBinding
15metadata:
16  name: fluentd-metadata-reader-binding
17roleRef:
18  apiGroup: rbac.authorization.k8s.io
19  kind: ClusterRole
20  name: fluentd-metadata-reader
21subjects:
22  - kind: ServiceAccount
23    name: fluentd
24    namespace: logging

Not every deployment needs node access, but many metadata enrichers include node information. Keep the role as small as the plugin actually requires.

Attach the Service Account to the DaemonSet

The RBAC objects are useless unless the DaemonSet runs as that service account.

1apiVersion: apps/v1
2kind: DaemonSet
3metadata:
4  name: fluentd
5  namespace: logging
6spec:
7  selector:
8    matchLabels:
9      app: fluentd
10  template:
11    metadata:
12      labels:
13        app: fluentd
14    spec:
15      serviceAccountName: fluentd
16      containers:
17        - name: fluentd
18          image: fluent/fluentd-kubernetes-daemonset:latest
19          volumeMounts:
20            - name: varlog
21              mountPath: /var/log
22            - name: containers
23              mountPath: /var/log/containers
24              readOnly: true
25      volumes:
26        - name: varlog
27          hostPath:
28            path: /var/log
29        - name: containers
30          hostPath:
31            path: /var/log/containers

If serviceAccountName is missing, Kubernetes uses the default service account and the expected permissions never apply.

Enable the Kubernetes Metadata Filter

RBAC is only half of the setup. Fluentd must also be configured to query Kubernetes metadata.

1<filter kubernetes.**>
2  @type kubernetes_metadata
3  watch true
4  cache_size 1000
5</filter>

If the metadata filter plugin is not enabled, adding RBAC will not change the output because Fluentd is not even attempting API lookups.

Verify Permissions Before Chasing Other Problems

Use kubectl auth can-i to check the service account directly.

kubectl auth can-i list pods --as=system:serviceaccount:logging:fluentd
kubectl auth can-i watch namespaces --as=system:serviceaccount:logging:fluentd
kubectl auth can-i get nodes --as=system:serviceaccount:logging:fluentd

Then inspect the workload itself:

kubectl -n logging get pods -l app=fluentd
kubectl -n logging logs daemonset/fluentd --tail=200

This order matters. It is faster to prove or disprove RBAC first than to debug Elasticsearch, OpenSearch, or another sink while the collector is still missing upstream metadata.

Common Pitfalls

The biggest mistake is solving missing metadata by granting cluster-admin. That may make the symptom disappear, but it creates far more access than a log collector needs.

Another common issue is creating the service account and binding correctly but forgetting serviceAccountName in the DaemonSet. Developers also sometimes assume RBAC is wrong when the real problem is that the metadata filter plugin was never enabled in Fluentd.

Summary

• Fluentd needs RBAC for Kubernetes metadata enrichment, not merely for reading node log files.
• Use a dedicated service account and minimal read-only permissions.
• Make the DaemonSet run under that service account explicitly.
• Enable the metadata filter so Fluentd actually queries the Kubernetes API.
• Verify permissions with kubectl auth can-i before debugging downstream log sinks.