Missing ServiceAccount validation and silent fallback to 'default' causes privilege risk & initialization DoS

[justmorpheus]

Silent ServiceAccount fallback and missing ServiceAccount validation in Grafana k6 Operator can lead to privilege risk and TestRun initialization DoS.

Description

The K6 operator has a security vulnerability where it automatically falls back to the default ServiceAccount in two scenarios:

• When spec.runner.serviceAccountName is omitted, the operator silently runs Pods with serviceAccountName: default.
• When an invalid or non-existent ServiceAccount is specified, the operator accepts the invalid value and creates a Pod that never progresses, leaving the TestRun stuck in the initialization phase.

The default ServiceAccount fallback vulnerability is still an issue because it breaks the security architecture, even though by default the ServiceAccount has limited permissions.

The fallback mechanism itself creates a security bypass that can be exploited, and there is no guarantee that the default ServiceAccount will always have safe permissions. Fixing the fallback behavior is required to maintain security controls and tenancy boundaries.

Endpoint / Vulnerable Component

https://github.com/grafana/k6-operator

---

Issue

• When no ServiceAccount is specified, the operator silently falls back to default.
• When a non-existent ServiceAccount is specified, the operator accepts the invalid name and creates Pods that fail at runtime due to the missing ServiceAccount.

---

What Happens

• User creates a TestRun without specifying a ServiceAccount. The operator falls back to default.
• User specifies a non-existent ServiceAccount. The operator accepts the invalid name, Pod creation fails at runtime, and the TestRun gets stuck in initialization.

---

Steps to Reproduce

Prerequisites

• Kubernetes cluster up and running
• k6 Operator deployed

Deploy k6 Operator bundle

curl https://raw.githubusercontent.com/grafana/k6-operator/main/bundle.yaml | kubectl apply -f -

Create a namespace

kubectl create ns k6-test-sa

Create custom ServiceAccount and RBAC

apiVersion: v1
kind: ServiceAccount
metadata:
  name: custom-test-sa
  namespace: k6-test-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: custom-test-role
  namespace: k6-test-sa
rules:
- apiGroups: [""]
  resources: ["pods", "services", "configmaps"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: custom-test-rolebinding
  namespace: k6-test-sa
subjects:
- kind: ServiceAccount
  name: custom-test-sa
  namespace: k6-test-sa
roleRef:
  kind: Role
  name: custom-test-role
  apiGroup: rbac.authorization.k8s.io

Create test script ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: k6-test-script
  namespace: k6-test-sa
data:
  test.js: |
    export const options = {
      stages: [
        { duration: '30s', target: 5 },
        { duration: '1m', target: 5 },
        { duration: '30s', target: 0 },
      ],
    };
    
    export default function() {
      console.log('Test running with custom ServiceAccount');
    }

---

Validation

Test Case 1: Without ServiceAccount (Fallback Case)

Deploy TestRun without specifying ServiceAccount

apiVersion: k6.io/v1alpha1
kind: TestRun
metadata:
  name: test-without-sa
  namespace: k6-test-sa
spec:
  parallelism: 1
  script:
    configMap:
      name: k6-test-script
      file: test.js
  runner:
    # NO ServiceAccount specified - will fallback to "default"
    resources:
      limits:
        cpu: "100m"
        memory: "128Mi"
      requests:
        cpu: "50m"
        memory: "64Mi"

Check ServiceAccount for TestRun without ServiceAccount

kubectl get pods -n k6-test-sa | grep test-without-sa
kubectl describe pod -n k6-test-sa <runner-pod-name> | grep -i "Service Account"

Observed Result

• Operator accepts the request with no validation and falls back to the default ServiceAccount.

---

Test Case 2: With Non-Existent ServiceAccount

Deploy TestRun with a non-existent ServiceAccount

apiVersion: k6.io/v1alpha1
kind: TestRun
metadata:
  name: test-with-nonexistent-sa
  namespace: k6-test-sa
spec:
  parallelism: 1
  script:
    configMap:
      name: k6-test-script
      file: test.js
  runner:
    serviceAccountName: non-existent-sa
    resources:
      limits:
        cpu: "100m"
        memory: "128Mi"
      requests:
        cpu: "50m"
        memory: "64Mi"

Check status

kubectl get pods -n k6-test-sa -w
kubectl get testrun -n k6-test-sa

Observed Result

• Pod creation fails due to missing ServiceAccount.
• TestRun remains stuck in initialization indefinitely.
• Operator performs no dependency validation.

---

Vulnerable Code Snippet

File: cc-k6-operator/pkg/resources/jobs/runner.go

func NewRunnerJob(k6 *v1alpha1.TestRun) (*batchv1.Job, error) {
    // CRITICAL SECURITY FLAW 1: Silent fallback to "default"
    serviceAccountName := "default"
    
    if k6.GetSpec().Runner.ServiceAccountName != "" {
        serviceAccountName = k6.GetSpec().Runner.ServiceAccountName
    }
    
    // CRITICAL SECURITY FLAW 2: No validation that ServiceAccount exists
    podSpec := corev1.PodSpec{
        ServiceAccountName: serviceAccountName,
    }
}

---

Impact

• Bypass of security controls through predictable fallback behavior.
• Potential privilege escalation when the default ServiceAccount is overly permissive.
• Broken multi-tenancy boundaries.
• Stuck TestRuns consume quota and human time.
• CI pipelines may block indefinitely due to initialization hangs.

---

Recommended Solution

Fix

Remove default ServiceAccount fallback and enforce validation.

func NewRunnerJob(k6 *v1alpha1.TestRun) (*batchv1.Job, error) {
    if k6.GetSpec().Runner.ServiceAccountName == "" {
        return nil, fmt.Errorf("spec.runner.serviceAccountName is required for security")
    }

    if err := validateServiceAccountNamespace(ctx, client, k6.Namespace, k6.GetSpec().Runner.ServiceAccountName); err != nil {
        return nil, fmt.Errorf("invalid ServiceAccount: %v", err)
    }
}

Add ServiceAccount validation

func validateServiceAccountNamespace(ctx context.Context, client client.Client, namespace, serviceAccountName string) error {
    sa := &corev1.ServiceAccount{}
    err := client.Get(ctx, types.NamespacedName{
        Namespace: namespace,
        Name: serviceAccountName,
    }, sa)
    if err != nil {
        return fmt.Errorf("ServiceAccount %s not found in namespace %s: %v", serviceAccountName, namespace, err)
    }
    return nil
}

[justmorpheus]

Hi @yorugac

I noticed you are one of the maintainers and wanted to check in.

I opened this issue regarding ServiceAccount handling, which appeared to me as a potential security and reliability concern. I wanted to ask whether there is a preferred way to raise or tag issues of this nature. I used a general issue template as I was unsure which option best applied.

If this should be reported via a different template or label, or security process, please let me know and I will update it accordingly.

Thanks you

[yorugac]

Hi @justmorpheus,
Apologies for the delay.

This is a breaking change proposal, and I'm not clear what exactly it is supposed to solve at the moment.

Users of k6-operator are not forced to rely on default service account. There are options in TestRun to use a custom service account, as well as automountServiceAccountToken flag.

Introducing this breaking change will raise bar for entry-level users, without really bringing benefit to experienced users.

Additionally, k6-operator was never meant to be a substitute for security policies: it is up to a user to configure their deployments as they prefer to, as well as it's their responsibility. For that matter, neither is Kubernetes itself such a substitute. The fallback to default service account is the behaviour of Kubernetes.

[justmorpheus]

Hi @yorugac, thanks for the clarification.

While I understand Kubernetes handles defaulting, looking at pkg/resources/jobs/runner.go (and similar files), the controller explicitly sets serviceAccountName := "default" in the code before the pod spec is even built.
This makes the fallback an active design choice within the operator logic rather than just a passive choice of the API server.

Also something similar was implemented with the security logic in issue #25, where the project explicitly moved the operator off the default service account to a dedicated one (k6-operator-account) to avoid the risks associated with the default identity.
At minimum, can we update the docs to explicitly state that runner pods will default to the default namespace SA if unspecified?

For the Test Case 2: With Non-Existent ServiceAccount , stuck state can lead to 1000 of pods getting stuck leading to DDoS within the cluster. When a serviceAccountName is explicitly provided by the user, could the operator validate it exists? This would prevent the "silent stuck" state where a typo leads to a permanent pending state which might lead to Denial of Service.

However, I just wanted to highlight the explicit code path I found while reviewing k6s which kind of seems to touch on the Kubernetes trust boundaries. I’ll leave the final decision to you, so please feel free to close this if you prefer the current behavior.

[yorugac]

the controller explicitly sets serviceAccountName := "default" in the code before the pod spec is even built.
This makes the fallback an active design choice within the operator logic rather than just a passive choice of the API server.

When the fallback is exactly the same, there is no difference in the outcome. There could be a difference only in one case: if Kubernetes was to change its default behaviour. I haven't heard of such plans from Kubernetes; have you?

🤔 Are you using some tooling that's triggering alarms for this code? What's the name of that tooling? I'm still not clear where this issue came from originally.

I don't have time to experiment with this right now, but if there's something triggering alarms for this code, I suppose we could remove that line too and leave it empty.

For the Test Case 2: With Non-Existent ServiceAccount , stuck state can lead to 1000 of pods getting stuck leading to DDoS within the cluster. When a serviceAccountName is explicitly provided by the user, could the operator validate it exists?

IIRC, there were similar requests for a couple other fields, not this one. But it all comes down to enhancing k6-operator with a new role of validator. Again, Kubernetes does not try to take on that role either. A user is fully responsible for their configuration.
At this point of time, I don't see this happening. And esp. not for the sake of the case you describe: we definitely do not recommend starting 1000 pods without trying 1 pod scenario first. This is true both for k6 standalone (start with 1 VU, not 1000 VUs) and for k6-operator.