I have setup my cluster (k3d) to have some RBAC rules and also created a certificate to identify my user for kubectl commands. I've set the user to have a Role via a RoleBinding in a specific namespace.

I want to make it so they could create Deployments, Pods, Services but not create a Secret or ConfigMap. If I do that though, will they be able to use Helm to install things? Doesn't Helm store its info about releases in Secrets or ConfigMaps?

Do I need to grant the user access to also create those things?

Example Role

#################################################################################
################################## Example Role #################################
#################################################################################

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: my-role
  namespace: my-namespace
rules:
  - apiGroups: ["", "extensions", "apps"]

    # Leaving out "configmaps" and "secrets"
    resources: ["pods","deployments","services"]
    verbs: ["*"]
1

There are 1 answers

3
Catastrophe On BEST ANSWER

Yes unfortunately you have to. But from the bright side you can put limitations by defining verbs as

["get, list, create"]

not

["*"]

This gives full authority. I suggest you to check https://kubernetes.io/docs/reference/access-authn-authz/rbac to get a clear view and determine your needs and abilities on the kubernetes side.

Example verbs:

verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Also you can check your users abilities by using the can-i tool in the link below.

https://kubernetes.io/docs/reference/access-authn-authz/authorization/

Hope these links can help you.

Btw, look at the charts and yaml files for Kind: labels.

Those are the things you will need access to.