With backups being a last line of defense for threats such as data encryption attacks, securing access to your backup environment is especially critical. As the leading Kubernetes backup and recovery solution, Kasten K10 by Veeam provides the granular identity and access management controls required to secure your K10 environment and easily provide users with the access their roles require.
In this brief article, we’ll take a look at the role-based access control (RBAC) features within the Kasten K10 UI. Follow along by watching this short demo video.
In this environment, we’ve configured Keycloak to act as the identity provider for Kasten K10, sing OpenID Connect authentication. Kasten K10 also supports Active Directory via LDAP and token-based authentication, including direct integrations with Red Hat OpenShift and Amazon EKS.
As a native data management solution built on Kubernetes custom resource APIs, Kasten K10 is able to integrate with Kubernetes RBAC controls, out-of-the-box. In addition to built-in profiles for administrators and users, custom roles can be configured and assigned to suit the needs of your organization.
New in Kasten K10 V5.0, we are exposing this functionality through the UI to create a simpler management experience for administrators. The new User Roles screen provides the ability to manage both Roles and ClusterRoles, as well as their assignments, aka Bindings:
We can create a new, custom Role by selecting the relevant Read, Write, and Delete access privileges through the UI. In this scenario I’ve defined a ClusterRole for my database administrators. This policy will allow them to create new backup policies and restore applications from available backups:
However, these users should not be authorized to configure infrastructure location profiles, delete existing policies, or, most importantly, delete any backup data. Kasten K10 enables you to customize roles to prevent them from performing these actions:
Once we save the Role, we can assign it to the database administrators:
We can create the Roleinding by clicking New Assignment and begin by providing a name:
We can choose to apply the Role to either all namespaces across the cluster or specify individual application namespaces:
Finally, we specify the relevant user group from the identity provider:
Next, let’s create an additional Role for developers:
Users should be able to create new backup policies to ensure that new projects are protected from the time of creation, without risk of deleting any existing policies or data, or restoring without engaging with the operations team:
After we save the new Role, we can create a new ClusterRoleBinding using the “idp-devusers” group:
Once this is complete, we can run a quick test to verify the capabilities of the custom roles. First, let’s log in as the database admin, “Karl”:
Karl should only have access to the applications and policies defined as part of the Role Assignment:
If Karl tries to delete an existing backup policy, access will be denied. However, he should be able to view all of the available restore points for each application…
Now let’s try logging in as the developer, “Joey”:
Joey will find he is unable to access any of the application restore points or initiate a restore operation:
However, he will have the ability to create a backup policy for the Postgres application:
He can also view the list of available Location Profiles for exporting backup data:
We hope you’ve enjoyed this quick look at how we’re improving the experience for Kubernetes native RBAC capabilities in Kasten K10. Not sure which permissions you’ll need for your own roles? Check the documentation at Kasten.io for a full breakdown of the Kasten K10 API.
