Custom resources for managing access rights
Kubernetes resources that store rights assignments.
API group
All custom access control resources belong to the API group permissions.shturval.tech.
Objects of this group are stored in the management cluster in the namespace shturval-backend and in the namespaces of client clusters (during synchronization). To avoid collisions with possible duplication of names, an auto-generated postfix is added for custom resources UserRole and GroupRole.
For a general overview of custom resources of the Shturval platform and their API groups, see the page “Custom resources in the platform”.
Basic resources
Scope
Stores an indication of which clusters/namespaces which access sets can be applied to, as well as which paths this scope covers within the API. Scope can be of different levels. Depending on the Scope level (scope_level), rights will be applied to different levels of objects:
- Platform - to all clusters in the platform;
- Cluster - to a cluster or a set of clusters united into a tenant;
- Namespace - to a namespace or a set of namespaces combined into a tenant;
Scope_level is specified in the Permission object (set of accesses). In the GUI, access sets are divided by scope levels, for example, when selecting access rights in the namespace, only permissions with the namespace scope level will be available.
Scope is a system object that is created automatically. The administrator does not need to create or modify it.
Scope manifest example:
apiVersion: permissions.shturval.tech/v1beta1
kind: Scope
metadata:
annotations:
clusters: prod
name: cluster-prod
namespace: prod
ownerReferences:
- apiVersion: permissions.shturval.tech/v1beta1
blockOwnerDeletion: true
controller: true
kind: Tenant
name: cluster-prod
spec:
objects:
clusters:
- prod
namespaces:
- "*"
tenants:
- sometenants
status:
objectsStatus:
- metadata:
kind: Cluster
name: prod
namespace: prod
state: exists
paths:
- /clusters
- /clusters/prod
- /clusters/prod/*
- /clusters/prod/ingressclasses/names
- /clusters/prod/namespaces/*
- /clusters/prod/namespaces/*/*
- /clusters/prod/namespaces/permissions/groups
- /clusters/prod/namespaces/permissions/roles
- /clusters/prod/persistentvolumes/names
- /clusters/prod/storageclasses/names
- /clusters/permissions/groups
- /clusters/permissions/roles
- /clusters?page*
- /platform/auth/ldap/search
- /platform/clusters/kubeconfigs
- /platform/clustersinfo
- /platform/clustersinfo/statistics
- /platform/license
- /platform/loginplugin/config
- /platform/permissions/access-map/groups
- /platform/permissions/access-map/groups/*
- /platform/permissions/access-map/roles
- /platform/permissions/access-map/roles/*
- /platform/permissions/custom
- /platform/permissions/custom/*
- /platform/permissions/custom/roles
- /platform/permissions/groups
- /platform/permissions/groups/*
- /platform/permissions/roles
- /platform/permissions/roles/*
- /platform/permissions/scope
- /platform/scopepermissions
- /platform/version
- prod/cluster-prod
permissions:
- cluster-admin
- cluster-admin-restricted
- custom-permission-set
- sec-cluster-audit
- sec-cluster-audit-full
- sec-security-report
Permissions
Permissions are individual resources that describe:
- Platform permissions (granted_platform_permissions) - a closed set of ClusterRoles for providing access to platform objects (cluster, provider, ippool, etc.) located in the management cluster. Creates assignments in the management cluster;
- Cluster permissions (granted_cluster_rules) — RBAC in the format Kubernetes (apiGroups, resources, verbs) for use in client clusters;
- Kubeflow rights - Kubeflow roles (kubeflow-admin, kubeflow-edit, kubeflow-view), which apply to profiles depending on the assignment level;
- Role in Argo CD - admin, edit or view.
Permission manifest example:
apiVersion: permissions.shturval.tech/v1beta1
kind: Permission
metadata:
annotations:
helm.sh/resource-policy: keep
isDefault: "true"
meta.helm.sh/release-name: shturval-backend
meta.helm.sh/release-namespace: shturval-backend
permissions.shturval.tech/description: 'Access to view the "Loads" sections,
"Network", pages: PersistentVolumeClaims, Configmaps, Quotas'
labels:
app.kubernetes.io/managed-by: Helm
name: dev-basic
namespace: shturval-backend
spec:
argo_cd_roles:
- view
granted_cluster_rules:
- apiGroups:
- ""
resources:
- namespaces
- namespaces/status
- configmaps
- endpoints
- persistentvolumeclaims
- pods
- podtemplates
- replicationcontrollers
- resourcequotas
- services
- poddisruptionbudgets
verbs:
- get
- list
- watch
- apiGroups:
- batch
resources:
- jobs
- cronjobs
verbs:
- get
- list
- watch
- apiGroups:
- networking.k8s.io
resources:
- ingresses
- ingressclasses
verbs:
- get
- list
- watch
- apiGroups:
- gateway.networking.k8s.io
resources:
- gateways
- gateways/status
- httproutes
- httproutes/status
- grpcroutes
- grpcroutes/status
- tcproutes
- tcproutes/status
- tlsroutes
- tlsroutes/status
- udproutes
- udproutes/status
verbs:
- get
- list
- watch
- apiGroups:
- events.k8s.io
resources:
- events
verbs:
- get
- list
- watch
- apiGroups:
- apps
resources:
- deployments
- replicasets
- statefulsets
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- events
verbs:
- get
- list
- watch
- apiGroups:
- autoscaling
resources:
- horizontalpodautoscalers
- horizontalpodautoscalers/status
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- persistentvolumesclaims
verbs:
- get
- list
- watch
- apiGroups:
- aquasecurity.github.io
resources:
- configauditreports
verbs:
- get
- list
- watch
- apiGroups:
- aquasecurity.github.io
resources:
- exposedsecretreports
verbs:
- get
- list
- watch
- apiGroups:
- aquasecurity.github.io
resources:
- vulnerabilityreports
verbs:
- get
- list
- watch
- apiGroups:
- kyverno.io
resources:
- cleanuppolicies
- clustercleanuppolicies
- policies
- clusterpolicies
verbs:
- get
- list
- watch
- apiGroups:
- wgpolicyk8s.io
resources:
- policyreports
- clusterpolicyreports
verbs:
- get
- list
- watch
- apiGroups:
- kyverno.io
resources:
- admissionreports
- clusteradmissionreports
- backgroundscanreports
- clusterbackgroundscanreports
verbs:
- get
- list
- watch
- apiGroups:
- kyverno.io
resources:
- updaterequests
verbs:
- get
- list
- watch
granted_platform_permissions:
- cluster-get
- tenant-get
scope_level: namespaces
More details: Setting permissions.
The existence of a permission set (Permission object) does not assign access rights to anyone. To associate a set of accesses with a user, a UserRole object is created, and a GroupRole object is created with a group.
UserRole and GroupRole apply to one or more access sets. When synchronized, the controller merges permissions from all assigned sets, creates a ClusterRole and RoleBinding in the target clusters, and applies Kubeflow and Argo CD roles if they are defined in the set.
UserRole
Assignment: stores the assignment of rights to user.
| Field | Description |
|---|---|
| Subject | Unique username (eg from LDAP or OIDC) |
| Access Sets | Links to sets (Permissions) |
| Level | Platform, Tenant, Cluster or Namespace |
| Target | Tenant, cluster or namespace (depending on the level) |
Location: namespace shturval-backend management cluster.
The status shows the result with which rights were applied at each requested level. If the application was in the platform, then the status will reflect the application to each object included in the platform, incl. into clusters that will be created after assignment. Same with the tenant.
Example UserRole manifest:
apiVersion: permissions.shturval.tech/v1beta1
kind: UserRole
metadata:
labels:
updatedByUser: username
name: p-petrov-user-88s5l
namespace: prod
ownerReferences:
- apiVersion: permissions.shturval.tech/v1beta1
blockOwnerDeletion: true
controller: true
kind: Scope
name: namespacename
spec:
permissions:
- namespace-admin
scope: namespacename
username: p.petrov
status:
permissions:
namespace-admin:
clusters:
prod:
namespaces:
namespacename:
plugins:
kubeflow:
previousstatus: not required
status: not required
rbac:
previousstatus: applied
status: applied
plugins:
argocd:
previousstatus: not required
status: not required
platform:
plugins:
rbac:
previousstatus: applied
status: applied
tenant:
previousstatus: applied
status: applied
GroupRole
Assignment: stores the assignment of rights to a group.
| Field | Description |
|---|---|
| Subject | Group name (from LDAP or manually) |
| Access Sets | Links to sets (Permissions) |
| Level | Platform, Tenant, Cluster or Namespace |
| Target | Tenant, cluster or namespace |
Location: namespace shturval-backend management cluster.
All users included in the group receive the rights specified in the GroupRole.
GroupRole manifest example:
apiVersion: permissions.shturval.tech/v1beta1
kind: GroupRole
metadata:
generateName: admins-group-
labels:
updatedByUser: username
name: admins-group-jpbgn
namespace: shturval-backend
ownerReferences:
- apiVersion: permissions.shturval.tech/v1beta1
blockOwnerDeletion: true
controller: true
kind: Scope
name: platform
spec:
claim: admins
permissions:
- platform-admin
scope: platform
status:
permissions:
platform-admin:
clusters:
managementcluster:
plugins:
argocd:
previousstatus: applied
status: applied
kubeflow:
previousstatus: not required
status: not required
rbac:
previousstatus: applied
status: applied
ml-cluster:
plugins:
argocd:
previousstatus: applied
status: applied
kubeflow:
previousstatus: not required
status: not required
rbac:
previousstatus: applied
status: applied
cluster-stage:
plugins:
argocd:
previousstatus: not required
status: not required
kubeflow:
previousstatus: not required
status: not required
rbac:
previousstatus: applied
status: applied
platform:
plugins:
rbac:
previousstatus: applied
status: applied
tenant:
previousstatus: applied
status: applied
The status shows the result with which rights were applied at each requested level. If the application was in the platform, then the status will reflect the application to each object included in the platform, incl. into clusters that will be created after assignment. Same with the tenant.
Backup
UserRole and GroupRole are among the objects that are recommended to be included in backups when setting up Disaster Recovery.
Example Velero Backup for UserRole and GroupRole:
apiVersion: velero.io/v1
kind: Backup
metadata:
name: backup-platform-roles
namespace: velero
labels:
velero.io/storage-location: s3
spec:
includedNamespaces:
- shturval-backend
includedResources:
- GroupRole
- UserRole
storageLocation: s3
ttl: 24h
More details: DR configuration.
Important notes
Do not edit UserRole and GroupRole manually without understanding the structure. It is recommended to assign rights through the platform GUI.
Platform permissions are required to access API group objects
cluster.x-k8s.io,bootstrap.cluster.x-k8s.io,infrastructure.cluster.x-k8s.ioandpermissions.shturval.tech, as they are stored in the management cluster.Viewobject mapping is possible if you have the
access-map-getorpermissions-getpermission in the access set.