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: ["*"]
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.