Data Security Strategies for Kubernetes

As the popularity of Kubernetes grows and more organizations start using it for their mission-critical applications, security concerns naturally come to the forefront. Enterprises are under enormous pressure to move more quickly in order to stay competitive, but they also face regulatory and consumer scrutiny for their security and data protection practices. This makes a strong security story essential. While security is a large topic that touches many parts of the stack, this post will focus on the essential topic of data security. In other words, how can you trust that your data management layer is properly secured even if your container orchestrator is up to date on the latest CVEs. This blog will introduce PX-Security and how it can aid in securing your applications data management layer.

Security and Data Management for Kubernetes

Providing a platform that can allow stateful applications to consume storage quickly, efficiently in a performant manner is one thing, but providing trust is another and just as important. Kubernetes has a large surface area for and this release of Portworx allows configurations to lock down the data layer and its APIs from bad actors. Portworx has always provided a way to encrypt volumes to keep the data within them secure, however, encryption is only one important component of a secure data management platform secure. PX-Security is a critical component of the Portworx Platform that provides container-granular role-based authentication, authorization, and ownership in addition to encryption.

The new access control features of PX-Security are all implemented with industry standards such as OpenID Connect (OIDC) which is used with JSON Web Tokens (JWT) to identify and authorize claims for 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. We’ll cover in more detail what these different features and technologies are and how they can help secure your mission-critical Kubernetes data.

Authentication

Authentication is the process of checking that a requester, for example, a user or client and their associated token, is valid. This tells Portworx that the user is real and should able to make an authorization request to interact with a resource in the data management layer.

> *Note that authentication doesn’t mean a requester has access to do something, the must be authorized first.

Authorization

Once the request is known to be valid and is authenticated, authorization takes place. This means that Portworx will verify that the requester has permissions to do what it is requesting to do based on the roles, groups, and rules the token claims contain. In other words, if a request comes in to list volumes, Portworx will make sure that the one making the request has an associated Role or Group that allows them to perform this action.

Ownership

An owner, in this case, is a User and a user can be a person, system or admin interacting with the Portworx platform. That owner can manage various aspects of the ownership model. Such as who can access an object and how those users can interact with the resource. In this case, the object is likely a volume, snapshot or clone.

Owners belong to groups themselves and contain a type of role. In other words, a user can have a specific role, such as an Admin Role, a User Role, a View Only Role or even a Custom Role (we’ll get to this later) which define how the user can interact with the resources in the platform.

An owner of a volume can add access via collaborators and groups. Each type of access can be restricted, so by default, a collaborator or group does not have full access. The different types of access are defined below:

• A Read access type allows access to the volume without modifying it. With a Read access type, one can clone or inspect the volume.
• A Write access type allows modification of the volume and its metadata, for example allowing to mount, unmount, and restoring the volume from a snapshot in addition to all Read access.
• An Admin access type allows full access to the volume, like deleting the volume in addition to all Write access.

Example of assigning groups and collaborator with Read, Write or Admin access.

>Pro tip: r=read, w=write, a=admin

pxctl volume access add --group group1:r
pxctl volume access add --group group2:w
pxctl volume access add --collaborator user2:a

The above example is depicted below and produces the following ownership for the volume.

Role-Based Access Control

I mentioned the use of Roles above. Let’s look at this more closely now. The following are the defaults available in the Portworx platform.

> *Note, Portworx RBAC extends what is available in Kubernetes. While Kubernetes can limit access to PVCs, for example, this does not affect access to the actual volume itself underneath that logical construct. For this, you need Portworx RBAC which deal directly with storage resources.

Custom roles are a way to define, in a more flexible manner, access for a certain type of user. In other words, admins are able to define a custom role and associated rules. Below is an example of providing a custom role called test.view which allows inspection of other services. Once roles are set up you can assign the default or custom roles to the user.

  {
     "name": "test.view",
     "rules": [
       {
         "services": [
           "volumes"
         ],
         "apis": [
           "*enumerate*"
         ]
       },
     ]
   }
$ pxctl role create --role-config onlyvolumes.json
Role test.view created...

As an example of how to associate a user with a role, an admin user would be defined much like the following snippet:

$ cat admin.yml 
name: SystemAdmin
email: admin@abc.com
roles: ["system.admin"]
groups: ["*"]

An example of a User who has the system.user and custom test.view role would be defined as the following:

$ cat user.yml 
name: SystemUser
email: user@abc.com
roles: ["system.user","test.view" ]
groups: ["users"]

The above-defined users are a simple example in YAML, but in most cases, users would be represented in something like Lightweight Directory Access Protocol (LDAP), Active Directory or an OIDC provider like Okta, Auth0, or Keycloak. Many of the OIDC providers have a way to integrate social applications or enterprise connections such as Active Directory (AD) or LDAP.

As an example, after requesting a token from Okta, a user would be represented using the snippet below. You can see the same type of information is made available such as email, name, roles, and groups.

{
 "sub": "00uc4wmk3xykIoMjJ356",
 "name": "firstname lastname",
 "email": "user@example.com",
 "ver": 1,
 "iss": "https://dev-123455.okta.com/oauth2/default",
 "aud": "0oac1ghukiNKPCyQf356",
 "iat": 1551980343,
 "exp": 1551983943,
 "jti": "ID.VPWO-ZuG1l69QdICiOOJ4vr95mw_Kh-UYJswisKYOGQ",
 "amr": [
   "pwd"
 ],
 "idp": "00oc1ao17K9cE0JGh356",
 "nonce": "foo",
 "preferred_username": "user@example.com",
 "auth_time": 1551980168,
 "at_hash": "2u8yte0GEOqS4pnqcAegrQ",
 "roles": [
   "system.user"
 ],
 "groups": [
   "Everyone",
   "system.user"
 ]
}

Interacting with PX-Security

Initial Setup

The initial setup of PX-Security is defined in the installation spec. This is no different than installing Portworx as always, just include the needed OIDC or JWT configuration. You can find specifics in the documentation.

Using pxctl

The authentication features can be used via the Portworx CLI pxctl. pxctl has a few commands you can use to interact with the authorization features, listed below.

Great! So… how does this work with Kubernetes?

Kubernetes itself has its own Users and RBAC Authorization to interact with objects such as Pods, DaemonSets, ReplicaSets, Secrets, ConfigMaps, and others. The Kubernetes RBAC model is separate from what we have described here, the above describes a security model that only applies to the resources that Portworx controls. However, that does not mean an integration point for interactions with Kubernetes objects that are backed by Portworx does not exist.

As an example, a Pod can have a volume mounted to it which is backed by a storage class that itself is associated with a persistent volume claim and a volume. The previous objects are Kubernetes objects and can be associated with Kubernetes RBAC, however, the virtual volume that backs up the Persistent Volume which Portworx provisioned from its data management layer IS the object which is controlled by the authorization we’ve been describing. Below shows the separation of objects in Kubernetes RBAC vs Portworx RBAC.

Where these two authorization models meet is when Kubernetes provides access to interact or use Portworx resources, such as creating a volume. To create a volume, the one creating the volume must be authorized to do so, and in order to do so, the user must provide a token which contains the roles and groups for the user making the request. This leads us to our first step. The user must provide their token as a secret in Kubernetes in the namespace they have access to.

$ kubectl create secret generic px-user-token -n <namespace> --from-literal=auth-token=<token>

Once the user has created the token, it can now be used in a PVC spec. This can be provided by including the auth-secret-name and auth-secret-namespace annotations.

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: mysql-data
  annotations:
    px/auth-secret-name: <secret-name> 
    px/auth-secret-namespace: <secret-namespace>
spec:
  storageClassName: fast-storage
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi

As long as the token inside the secret is related to RBAC rules in Portworx that allows volume creation for the user, creating this PVC will succeed. The above also works with CSI, if you are interested in how to configure PX-Security with CSI, visit our docs.

Demo

Below is a demo of using OpenID Connect to manage users, roles and groups for providing users access to Portworx resources. In the below demo, Okta is used as the OIDC provider to provide a system.admin role for an admin user which will allow commands to be run on the cluster.

With PX-Security added to your Portworx arsenal, organizations can now include container-granular role-based authentication, authorization, and ownership in addition to encryption of their Kubernetes data. Per container data volume access controls integrated with a corporate authorization and authentication system provides ways for teams to deploy mission-critical applications that have stricter governance, enabling them to get more out of their Kubernetes investment

Until next time. Thanks for reading!