## TL;DR
trivy k8s needs a working Kubernetes identity with cluster-wide read access, and the error means it has none: either the kubeconfig is missing or the in-cluster ServiceAccount has no RBAC grant. Create a dedicated ServiceAccount, give it a read-only ClusterRole and ClusterRoleBinding, and point trivy at it. Verify with kubectl auth can-i before the next scan.

## The query

```text
trivy k8s scan: "failed to create kubernetes client: the server has asked for the client to provide credentials" - missing in-cluster RBAC
```

## Use this when

- trivy k8s fails immediately with the credentials error
- The scan runs from a pod, a CI job, or an agent with no user kubeconfig
- kubectl works for you personally but the scan identity is different

## Not for

- "forbidden" errors mid-scan (credentials exist but RBAC is too narrow)
- Image pull "unauthorized" errors (registry auth, not cluster auth)
- trivy k8s hanging on large clusters (a performance problem, not auth)

## Steps

### 1. Check what identity the scan is using

```bash
kubectl config current-context && kubectl auth can-i list pods --all-namespaces
```

Expected output: you see which context is active and whether listing pods cluster-wide is allowed. If there is no context at all, the scan has no kubeconfig.

### 2. Create a dedicated ServiceAccount

```bash
kubectl create serviceaccount trivy-scanner -n trivy-operator
```

Expected output: the ServiceAccount exists. A dedicated identity keeps the scanner's permissions auditable instead of borrowing a human's.

### 3. Grant read-only cluster access

Create a ClusterRole with get, list, and watch on the resources trivy inventories (pods, deployments, nodes, and related workload types), then bind it:

```bash
kubectl create clusterrolebinding trivy-scanner-read --clusterrole=trivy-read --serviceaccount=trivy-operator:trivy-scanner
```

Expected output: the binding is created without errors.

### 4. Verify the grant before scanning

```bash
kubectl auth can-i list pods --all-namespaces --as=system:serviceaccount:trivy-operator:trivy-scanner
```

Expected output: yes. If it says no, the role is missing a resource and the scan will fail the same way.

### 5. Run the scan as that identity

Run trivy k8s with the kubeconfig or in-cluster config that resolves to the new ServiceAccount. Verify: the scan starts inventorying workloads instead of failing on client creation.

## Variant phrasings

### trivy k8s failed to create kubernetes client
The short form of this failure, same fix.

### trivy kubernetes scan the server has asked for the client to provide credentials
The full server message, for exact-match searchers.

Compatibility: trivy with the k8s command (0.3x and later). RBAC verbs shown work on Kubernetes 1.24 and later.

## Why it happens
trivy k8s builds a standard Kubernetes client, which needs credentials the same way kubectl does: a kubeconfig file or an in-cluster ServiceAccount token. CI jobs and agent harnesses usually have neither, so client creation fails before any scanning starts. The RBAC grant is the second half: even with an identity, the API server denies cluster-wide reads without an explicit ClusterRoleBinding.

## Edge cases / pitfalls

- A namespace-scoped RoleBinding is not enough. trivy inventories cluster-scoped resources like nodes, so it needs a ClusterRoleBinding.
- If your cluster disables the legacy ServiceAccount token automount, generate a token explicitly and mount it for the scan job.
- Do not grant cluster-admin to the scanner. Read-only on workload resources is sufficient and keeps a compromised scan job from becoming a cluster takeover.
- Managed clusters sometimes restrict ClusterRole creation to admins. The grant may need a platform-team ticket, which is normal.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_9AaxdLmF31jVnIC7r_JMhg