RBAC Overview

Portworx has always provided support for volume encryption in order to keep data secure. Starting with version 2.1, Portworx introduced support for RBAC. Thus, the platform provides namespace-granular, role-based authentication, authorization, and ownership in addition to encryption.

This document walks you through the different components used to secure Portworx through RBAC.

General considerations

Portworx RBAC centers around the ubiquitous JWT based authentication and authorization model. This technology is currently used by most major internet systems, providing a proven secure model for user and account identification.

A token is generated by a token authority (TA) and signed using either a private key or a shared secret. Then, the user should provide the token to Portworx for identification. No passwords are ever sent to Portworx.

This secure model enables Portworx to only have to verify the validity of the token to authenticate the user. Portworx then destroys the token ensuring tokens are never saved on a Portworx system.

The token contains a section called claims which identifies the user and provides authorization information in the form of RBAC. Portworx uses the RBAC information to determine if the user is authorized to make the request.

Terminology

Security tokens

To enable Portworx security the administrator must generate a token using their own TA application. The administrators can also generate user tokens using pxctl command-line tool. For more details, refer to Generate token.

For Portworx to verify the tokens are valid, they must be signed with either a:

• shared secret
• an RSA private key
• an ECDSA private key

Also, Portworx must be configured with the same shared secret or a pair of keys.

Required JWT claims

Portworx requires a set of claims to be provided in order to authorize the user. The following table lists the set of required claims:

Portworx RBAC Security Models

Portworx RBAC security is composed of three models:

1. Authentication: A model for verifying the token is correct and generated from a trusted issuer.
2. Authorization: A model for verifying access to a particular request type according to the role or roles applied to the user.
3. Ownership: A model for determining access to resources.

1. Authentication

Authentication is based on Role Based Access Control for all clients in the stack and an ownership model that is much like the familiar unix style permissions. Portworx will determine the validity of a user through a token-based model. The token will be created by the TA and will contain information about the user in the claims section. When Portworx receives a request from the user, it will check the token validity by verifying its signature, using either a shared secret or public key provided during configuration.

2. Authorization

Once the token has been determined to be valid, Portworx then checks if the user is authorized to make the request. The roles claim in the token must contain the name of an existing default or customer registered role in the Portworx system. A role is the name given to a set of RBAC rules which enable access to certain SDK calls. Custom roles can be created using pxctl or through the OpenStorage SDK.

See also Role management using pxctl.

3.Ownership

Ownership is the model used for resource control. The model is composed of the owner and a list of groups and collaborators with access to the resource. Groups and collaborators can also have their access to a resource constrained by their access type. The following table defines the three access types supported:

For example, user1 could create a volume and give Read access to group1. This means that only user1 can mount the volume. However, group1 can clone the volume. When a volume is cloned, it is owned by the user who made the request.

The Administrator Role

Similar to the root user in a Linux system, Portworx has the concept of a system administrator. This role is not constrained by RBAC and participates in every group. The built-in RBAC role for system administrators is called system.admin and gives the caller access to every API call. To have access to every resource, a user must be in group *, which means they are part of every group. Their token claims would then look like this:

{
  "roles" : [ "system.admin" ],
  "groups": [ "*" ]
}

Guest Access

Starting with version 2.6, Portworx introduced a new concept called Guest Role Access. The guest role allows your users to access and manipulate public volumes. The new system.guest role is now used whenever a user does not pass a token to any Portworx operation or SDK call. This role, by default, allows all standard user operations such as Create, Delete, Mount and Unmount for public volumes.

Volumes are public if they are created before security was enabled or without a token. This simplifies the process for upgrading from auth disabled to auth enabled for Portworx 2.6+. Additionally, the admin may mark a volume as public to expose it to the guest role.

The role is mutable and is named system.guest. This allows the admin to change how the auth system behaves when an unauthenticated user interacts with it. Strict admins may disable the guest role entirely if they wish.

Public volumes

A volume is public if it does not have any ownership associated with it. Ownership is added based on the token a volume is created with. If a volume is not public, it has ownership and is considered private.

In addition, volumes may be explicitly marked public via pxctl.

The system.guest can always access public volumes.

Enhance the security of a cluster

To enhance the security of your cluster, enable PX-Security in Portworx. For more details, refer to the Deploying in Kubernetes page.

References

For more information, see also:

• JWT.io
• OpenStorge SDK
• Authorization with pxctl
• Role management with pxctl