I want to use the ClusterRole edit for some users of my Kubernetes cluster (https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles).
However, it is unfortunate that the user can be accessing and modifying Resource Quotas and Limit Ranges.
My question is now: How can I grant Users via a RoleBinding access to a namespace, such that the Role is essentially the CluserRole edit, but without having any access to Resource Quotas and Limit Ranges?
The edit role gives only read access to resourcequotas and limitranges:
- apiGroups:
- ""
resources:
- bindings
- events
- limitranges
- namespaces/status
- pods/log
- pods/status
- replicationcontrollers/status
- resourcequotas
- resourcequotas/status
verbs:
- get
- list
- watch
If you want a role that doesn't include read access to these resources, just make a copy of the edit role with those resources excluded.
Related
I have been working on creating a application which can perform verification test on the deployed istio components in the kube-cluster. The constraint in my case is that I have run this application as a pod inside the kubernetes and I cannot provide cluster-admin role to the pod of the application so that it can do all the operations. I have to create a restricted ClusterRole just to provide enough access so that application list and get all the required deployed istio resources (Reason for creating a cluster role is because when istio is deployed it created both namespace level and cluster level resources). Currently my application won't run at all if I use my restricted ClusterRole and outputs and error
Error: failed to fetch istiod pod, error: pods is forbidden: User "system:serviceaccount:istio-system:istio-deployment-verification-sa" cannot list resource "pods" in API group "" in the namespace "istio-system"
Above error doesn't make sense as I have explicitly mentioned the core api group in my ClusterRole and also mentioned pods as a resource in the resourceType child of my ClusterRole definition.
Clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: {{ .Values.clusterrole.name }}
namespace: {{ .Values.clusterrole.clusterrolens}}
rules:
- apiGroups:
- "rbac.authorization.k8s.io"
- "" #enabling access to core API
- "networking.istio.io"
- "install.istio.io"
- "autoscaling"
- "apps"
- "admissionregistration.k8s.io"
- "policy"
- "apiextensions.k8s.io"
resources:
- "clusterroles"
- "clusterolebindings"
- "serviceaccounts"
- "roles"
- "rolebindings"
- "horizontalpodautoscalers"
- "configmaps"
- "deployments"
- "mutatingwebhookconfigurations"
- "poddisruptionbudgets"
- "envoyfilters"
- "validatingwebhookconfigurations"
- "pods"
- "wasmplugins"
- "destinationrules"
- "envoyfilters"
- "gateways"
- "serviceentries"
- "sidecars"
- "virtualservices"
- "workloadentries"
- "workloadgroups"
- "authorizationpolicies"
- "peerauthentications"
- "requestauthentications"
- "telemetries"
- "istiooperators"
resourceNames:
- "istiod-istio-system"
- "istio-reader-istio-system"
- "istio-reader-service-account"
- "istiod-service-account"
- "wasmplugins.extensions.istio.io"
- "destinationrules.networking.istio.io"
- "envoyfilters.networking.istio.io"
- "gateways.networking.istio.io"
- "serviceentries.networking.istio.io"
- "sidecars.networking.istio.io"
- "virtualservices.networking.istio.io"
- "workloadentries.networking.istio.io"
- "workloadgroups.networking.istio.io"
- "authorizationpolicies.security.istio.io"
- "peerauthentications.security.istio.io"
- "requestauthentications.security.istio.io"
- "telemetries.telemetry.istio.io"
- "istiooperators.install.istio.io"
- "istiod"
- "istiod-clusterrole-istio-system"
- "istiod-gateway-controller-istio-system"
- "istiod-clusterrole-istio-system"
- "istiod-gateway-controller-istio-system"
- "istio"
- "istio-sidecar-injector"
- "istio-reader-clusterrole-istio-system"
- "stats-filter-1.10"
- "tcp-stats-filter-1.10"
- "stats-filter-1.11"
- "tcp-stats-filter-1.11"
- "stats-filter-1.12"
- "tcp-stats-filter-1.12"
- "istio-validator-istio-system"
- "istio-ingressgateway-microservices"
- "istio-ingressgateway-microservices-sds"
- "istio-ingressgateway-microservices-service-account"
- "istio-ingressgateway-public"
- "istio-ingressgateway-public-sds"
- "istio-ingressgateway-public-service-account"
verbs:
- get
- list
Application I have built leverage the istioctl docker container published by istio on dockerhub. Link.
I want to understand what changes are required in above ClusterRole definition so that I can perform the get and list operations for the pods in the namespace.
I would also want to understand that is it possible that the error I am getting is trying to reference some other resource in the cluster?
Cluster information:
Kubernetes version: 1.20
Istioctl docker image version: 1.12.2
Istio version: 1.12.1
As OP mentioned in the comment problem is resolved after my suggestion:
Please run the command kubectl auth can-i list pods --namespace istio-system --as system:serviceaccount:istio-system:istio-deployment-verification-sa and attach result to the question. Look also here
OP has confirmed that problem is resolved:
thanx for the above command using above I was finally able to nail down the issue and found the issue to be with first resourceName and second we need to mention core api in the api group before any other. Thank you issue is resolved now.
Curious as to how configMaps can be referenced in PODs without appropriate serviceAccount and asscoiated RBAC rules ?
Sample POD Yaml mounting configMap
- mountPath: /kubernetes-vault
name: kubernetes-vault
.................
.................
volumes:
- emptyDir: {}
name: vault-token
- configMap:
defaultMode: 420
name: kubernetes-vault
name: kubernetes-vault
But the associated ServiceAccount and it's corresponding RBAC ( Role and RoleBinding ) does'nt have any rules specifying access rules for this configMap (kubernetes-vault)
Role & Rule for the POD
rules:
- apiGroups:
- '*'
resources:
- services
- pods
- endpoints
verbs:
- get
- list
- watch
Couple of Qs
does'nt access to configMap required appropriate ServiceAccount with access rules specified specifically for configMap access ?
if yest which rule mentioned above governs configMap Access
if not , what objects are governed by RBAC rules ?
doesn't access to configMap required appropriate ServiceAccount with access rules specified specifically for configMap access ?
It will when a ServiceAccount is performing that action, yes, but volumes: are performed by a mixture of kube-apiserver, kube-controller, and the calling credential that interacts with the apiserver. By the time the Pod's volumes mount, all those security checks are a done deal -- one can verify that behavior by running any Pod and suppressing its ServiceAccount and observe that the volume mounts still take place
If one has objects which should only be accessed by a limited set of users, that should happen at the Role level to prevent the users from scheduling Pods that touch the sensitive items.
if not , what objects are governed by RBAC rules ?
As far as I know, everything is governed by RBAC rules, and even if they aren't to your satisfaction, the system offers Validating Admission Controllers which allow extremely fine-grained access rules
Consider the RBAC role below. Is it possible to write a more sophisticated regex for resources: that prevents access to service accounts and namespaces but allows everything else?
- apiGroups:
"*"
resources:
"*"
verbs:
"*"
A simple workaround for it is to disable possibility to access resources within namespace. Execute command:
$ kubectl api-resources --namespaced=false
Non-namespaced resources will be returned, otherwise returning namespaced resources by default.
Also while you are using:
apiGroups:
"*" - this means that you want to grant access for all groups within Kubernetes API (both core API gorups and named groups )
resources:
"*" - this means that you want to grant access for all resources (get, services, endpoints etc.)
verbs:
"*" - this means that you want to allow operations on specified objects (get, list, edit etc.).
In your case as you defined you don't prevent access but give it to every object etc.
Take a look on: api-resources.
Is it possible to create a Kubernetes cluster admin without the ability to read namespace secrets?
I know you can create a ClusterRole and list every single resource and omit secret but seems unintuitive.
Can you use Aggregated ClusterRoles to remove a permission? so using ClusterRole cluster-admin and have a role that uses:
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: [""]
Not really Aggregated Cluster Roles is a set union of several ClusterRoles. To get the behavior you want you would need a set subtraction of cluster-admin role minus the rules that you have defined. It's not supported in K8s as of this writing.
I have created a role, below is definition the role:
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: ${SERVICE_ACCOUNT_NAME}-full-access-role
namespace: ${NAMESPACE}
rules:
- apiGroups: ["", "extensions", "apps"]
resources: ["*"]
verbs: ["*"]
- apiGroups: ["batch"]
resources:
- jobs
- cronjobs
verbs: ["*"]
Using this role a user can create, list and delete any resource in a namespace but problem is it can also list all namespaces in cluster.
I want to enable users to create namespaces and can perform any action in it as well but also they can't list any resource even other namespaces that are't created by the user.
I think you cannot deny user access right to list all namespaces and give them the access you need at the same. At least not in the bare metal kubernetes. Read the following GH issue, it's about the similar issue that you encounter.
It would help if you can tell us which cloud platform you are on. To my knowledge, different cloud platforms handle Role based access differently.
With that being said, I believe there should be predefined roles for the specific level of access you want. Usually role based authorization trickles down. If you grant someone access to a resource at the folder level, the user will be able to access all resources in that folder. Since you want to grant access to any resource in an namespace, I would grant the user access at that level.