Namespace access control
Introduction
In authentication strategies other than anonymous
Kiali supports limiting the
namespaces that are accessible on a per-user basis. The anonymous
authentication strategy does not support this, although you can still limit
privileges when using an OpenShift cluster. See the access control section in
Anonymous strategy.
To authorize namespaces, the standard Roles
resources (or ClusterRoles
)
and RoleBindings
resources (or ClusterRoleBindings
) are used.
Kiali can only restrict or grant read access to namespaces as a whole. So,
keep in mind that while the RBAC capabilities of the cluster are used to give
access, Kiali won’t offer the same privilege granularity that the cluster
supports. For example, a user that does not have privileges to get Kubernetes
Deployments
via typical tools (e.g. kubectl
) would still be able to get
some details of Deployments through Kiali when listing Workloads or when
viewing detail pages, or in the
Graph.
Some features allow creating or changing resources in the cluster (for example, the Wizards). For these write operations which may be sensitive, the users will need to have the required privileges in the cluster to perform updates - i.e. the cluster RBAC takes effect.
Granting access to namespaces
In general, Kiali will give read access to namespaces where the logged in
user is allowed to “GET” its definition – i.e. the user is allowed to do a
GET
call to the api/v1/namespaces/{namespace-name}
endpoint of the cluster
API. Users granted the LIST verb would get access to all namespaces of the
cluster (that’s a GET
call to the api/v1/namespaces
endpoint of the cluster
API).
You, probably, will want to have this small ClusterRole
to help you in
authorizing individual namespaces in Kiali:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: kiali-namespace-authorization
rules:
- apiGroups: [""]
resources:
- namespaces
- pods/log
verbs:
- get
- apiGroups: ["project.openshift.io"] # Only if you are using OpenShift
resources:
- projects
verbs:
- get
pods/log
privilege is needed for the pods Logs view.
Since logs are potentially sensitive, you could remove that privilege if you
don’t want users to be able to fetch pod logs.
Once you have created this ClusterRole
, you would authorize a namespace
foobar
to user john
with the following RoleBinding
:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: authorize-ns-foobar-to-john
namespace: foobar
subjects:
- kind: User
name: john
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: kiali-namespace-authorization # The name of the ClusterRole created previously
apiGroup: rbac.authorization.k8s.io
User
, which is the case when
using openid
or openshift
authentication strategies. For other
authentication strategies you would need to adjust the RoleBinding
to use the
right subject kind.
If you want to authorize a user to access all namespaces in the cluster, the
most efficient way to do it is by creating a ClusterRole
with the list verb
for namespaces and bind it to the user using a ClusterRoleBinding
:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: kiali-all-namespaces-authorization
rules:
- apiGroups: [""]
resources:
- namespaces
- pods/log
verbs:
- get
- list
- apiGroups: ["project.openshift.io"] # Only if you are using OpenShift
resources:
- projects
verbs:
- get
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: authorize-all-namespaces-to-john
subjects:
- kind: User
name: john
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: kiali-all-namespaces-authorization
apiGroup: rbac.authorization.k8s.io
ClusterRole
is the list
verb in the first rule.
Alternatively, you could also use the previously mentioned
kiali-namespace-authorization
rather than creating a new one with the list
privilege, and it will work. However, Kiali will perform better if you grant the
list privilege.
Granting write privileges to namespaces
Changing resources in the cluster can be a sensitive operation. Because of
this, the logged in user will need to be given the needed privileges to perform
any updates through Kiali. The following ClusterRole
contains all write
privileges that may be used in Kiali:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: kiali-write-privileges
rules:
- apiGroups: [""]
resources:
- namespaces
- pods
- replicationcontrollers
- services
verbs:
- patch
- apiGroups: ["extensions", "apps"]
resources:
- daemonsets
- deployments
- replicasets
- statefulsets
verbs:
- patch
- apiGroups: ["batch"]
resources:
- cronjobs
- jobs
verbs:
- patch
- apiGroups:
- networking.istio.io
- security.istio.io
- extensions.istio.io
- telemetry.istio.io
- gateway.networking.k8s.io
resources: ["*"]
verbs:
- create
- delete
- patch
Similarly to giving access to namespaces, you can either use a RoleBinding
to
give write privileges only to specific namespaces, or use a
ClusterRoleBinding
to give privileges to all namespaces.