Securing namespaces using restrict authorization feature in Chaos Mesh

In my previous blog, I discussed about securing tenant services while using chaos mesh using OPA. Since the release of Chaos Mesh 1.1.3, chaos mesh has fixed this security issue. So in this blog, I am going to discuss the same.

Let’s recall the problem we had before Chaos Mesh 1.1.3 release with an example. Suppose you have the following chaos YAML file.

apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-kill
  namespace: chaos-testing
spec:
  action: pod-kill
  mode: one
  selector:
    namespaces:
      - tidb-cluster-demo
    labelSelectors:
      'app.kubernetes.io/component': 'tikv'
  scheduler:
    cron: '@every 1m'

Suppose the user has required rights to chaos-testing namespace but not to tidb-cluster-demo. The user has created the above chaos mesh resource in chaos-testing namespace. As we can see in the selector section user has specified some other namespace (tidb-cluster-demo), which means the pods which will be selected for chaos operation will be from this namespace i.e. tidb-cluster-demo, and not from the one for which the user has access i.e. chaos-testing. So this was the problem, even if user was not having rights to tidb-cluster-demo namespace, (s)he was able to inject chaos in this namespace. PROBLEM!!!

Since the release of Chaos Mesh 1.1.3, this security issue has been fixed and now if user tries to apply the above YAML file, the system will show the error similar to:

Error when creating "pod/pod-kill.yaml": admission webhook "vauth.kb.io" denied the request: ... is forbidden on namespace tidb-cluster-demo

Problem solved!

If user has chaos mesh related rights to tidb-cluster-demo namespace, there will be no error.

Conclusion:

Since the release of Chaos Mesh 1.1.3, the security flaw has been fixed. In case you want to enforce that no user should be allowed to create chaos across namespaces, you can achieve the same as discussed in my previous blog.

Happy chaos engineering.