Setting IAM permissions and implementing RBAC on a cluster
Role-based access control (RBAC) is a native feature of Kubernetes and a method of regulating access to compute or network resources based on the roles of individual users within your Organization.
The feature is activated on Scaleway Kubernetes Kapsule and Kosmos by default and is compatible with Scaleway’s Identity and Access Management (IAM) service.
IAM and RBAC work together by integrating Scaleway’s IAM with Kubernetes’ native RBAC system. This integration ensures that access permissions are consistent across both the cloud infrastructure and the Kubernetes cluster, providing a secure access control mechanism.
It allows you to assign roles to users, groups or ServicesAccount via RoleBindings and ClusterRoleBindings.
Key components of RBAC in Kubernetes include:
- Roles and ClusterRoles:
Roles: These are specific to a namespace, and define a set of permissions for resources within that namespace (e.g., pods, services).ClusterRoles: These are similar to roles but apply cluster-wide, spanning all namespaces.
- RoleBindings and ClusterRoleBindings:
RoleBindings: These associate a set of permissions defined in a role with a user, group, or service account within a specific namespace.ClusterRoleBindings: These associate a set of permissions defined in a ClusterRole with a user, group, or service account across the entire cluster.
- Subjects: A subject in RBAC can be a user, a group, or a service account to which roles or cluster roles are bound.
- Rules: Rules are sets of permissions associated with roles or cluster roles. They specify what actions are allowed or denied on specific resources.
RBAC works seamlessly with Scaleway’s IAM (Identity and Access Management) system. Identity and Access Management (IAM) provides control over resource access. IAM policies enable the configuration of permissions for Kubernetes Kapsule clusters at the Project level.
An IAM policy defines the permissions for users, groups, and applications within an Organization. It consists of a principal (the user, group, or application to which it applies) and IAM rules that specify permission sets and their scope.
The combination of IAM and Kubernetes RBAC allows you to define fine-grained access levels for cluster users.
Mapping IAM permission sets to Kubernetes groupsLink to this anchor
The following IAM permission sets are mapped to Kubernetes groups:
| IAM permission set | Kubernetes group | Notes |
|---|---|---|
KubernetesFullAccess | scaleway:cluster-write | |
scaleway:cluster-read | ||
KubernetesReadOnly | scaleway:cluster-read | |
KubernetesSystemMastersGroupAccess | system:masters | Super-user access to perform any action on any Kubernetes resource, ignoring all RBAC rules |
Default ClusterRoleBindingsLink to this anchor
Default ClusterRoleBinding and ClusterRole configurations have been set up:
| Group | ClusterRoleBinding | ClusterRole |
|---|---|---|
scaleway:cluster-write | scaleway:cluster-write | scaleway:cluster-write |
scaleway:cluster-read | scaleway:cluster-read | scaleway:cluster-read |
These groups can be edited and will not be reconciled by Kapsule/Kosmos. If these roles are misconfigured and cut off access to the cluster, the IAM permission set KubernetesSystemMastersGroupAccess should be assigned to the application or user. This permission set allows bypassing the entire RBAC layer.
Users or applications can be added to zero, one, or more IAM groups. IAM groups are mapped to Kubernetes groups in the format scaleway:groups:GROUPID.
Example:
Creating a developers group with write access to dev and staging namespacesLink to this anchor
-
Create an IAM group called
developers:- Assign the
KubernetesReadOnlypermission set to this group. - Note the group ID, as it will be needed later.
- Assign the
-
Create namespaces and roles: As a user or application with
KubernetesFullAccessorKubernetesSystemMastersGroupAccess, create the following manifests:Namespace creation:
apiVersion: v1kind: Namespacemetadata:name: dev---apiVersion: v1kind: Namespacemetadata:name: stagingRole creation for dev namespace:
apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:name: developersnamespace: devrules:- apiGroups: ["*"]resources: ["*"]verbs: ["*"]- nonResourceURLs: ["*"]verbs: ["*"]RoleBinding Creation for dev namespace:
apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:name: developersnamespace: devsubjects:- kind: Groupname: scaleway:groups:<GROUP_ID>roleRef:kind: Rolename: developersapiGroup: rbac.authorization.k8s.ioRepeat the same operation for the staging namespace.
-
Apply the manifests:
kubectl apply -f filename.yaml
After these steps, members of the IAM group will have read access to the cluster and write access to the dev and staging namespaces. Permissions can be refined by modifying the Role.
Assigning permissions to a specific user without using a groupLink to this anchor
-
Assign the
KubernetesReadOnlypermission set to the user. -
Retrieve the IAM user ID and note it.
-
Create the following manifests:
Namespace creation:
apiVersion: v1kind: Namespacemetadata:name: demo-sandboxRole creation for an example namespace:
apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:name: examplenamespace: example-sandboxrules:- apiGroups: ["*"]resources: ["*"]verbs: ["*"]- nonResourceURLs: ["*"]verbs: ["*"]RoleBinding creation for the example namespace:
apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:name: examplenamespace: example-sandboxsubjects:- kind: Username: scaleway:bearer:<USER_ID>roleRef:kind: Rolename: demoapiGroup: rbac.authorization.k8s.io -
Apply the manifests:
kubectl apply -f filename.yamlThe user “demo” now has full rights in the
example-sandboxnamespace.
Limiting cluster-read accessLink to this anchor
To modify the scaleway:cluster-read permissions, use the following command:
Default content: