# Strip down superuser

**URL:** <https://discuss.kubernetes.io/t/strip-down-superuser/23296>\
**Category:** General Discussions\
**Tags:** security\
**Created:** [March 3, 2023, 10:18pm UTC](https://discuss.kubernetes.io/t/strip-down-superuser/23296 "2023-03-03T22:18:52Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![PretentiousDonkey](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/pretentiousdonkey/32/11957_2.png) [@PretentiousDonkey](https://discuss.kubernetes.io/u/PretentiousDonkey)\
**Post date:** [March 3, 2023, 10:18pm UTC](https://discuss.kubernetes.io/t/strip-down-superuser/23296/1 "2023-03-03T22:18:52Z")

</div>

Ahoy.

I’ve spent the last few weeks trying to setup a secure GKE cluster. But I’ve hit a wall where it seems impossible to find a solution to my (seemingly) simple issue.

I want to block myself and everyone else from reading `secret` and running `kubectl exec` on a specific customer pod. I’ve tried bruteforce solutions like in [this blog post](https://blog.aquasec.com/kubernetes-authorization), but I start thinking there is no way to achieve what I need since deleiting every single clusterole and its binding doesn’t affect me when I run `kubectl`.

Is there a way to apply RBAC on a pod and its secrets from **EVERYONE** (sysyadmins, devs, owners)?

### Cluster information:

Kubernetes version: 1.24.9-gke.3200  
Cloud being used: GKE  
Installation method:  
Host OS: Container OS  
CNI and version: Cilium  
CRI and version: