Secure Your Data with AWS EKS and Portworx with Role-based Access Control and Auditing
Secure Your Data with AWS EKS and Portworx with Role-based Access Control and Auditing
October 12, 2022
Kubernetes is built upon a Cloud Native security model, which uses a layered security model with four components: cloud, clusters, containers, and code. In the Cloud Native security model, each layer builds on the layer just outside of it (e.g.,., the container layer builds on the cluster layer). The cloud layer of AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. For Amazon EKS, AWS is responsible for the Kubernetes control plane, which includes the control plane nodes and etcd database. Third-party auditors regularly test and verify the effectiveness of AWS’s security as part of the AWS compliance programs. Portworx works alongside the cluster layer to provide a secure data management and data protection platform, creating a solid foundation that the containers and code can be built to run on.
According to the 2021 Kubernetes Adoption survey, organizations report security as one of the top three most difficult challenges for them to overcome. In addition, 40% of respondents report not having the correct Kubernetes related skills, including in the security arena, to appropriately manage and operate a production environments
Portworx is the gold standard when it comes to Kubernetes storage and data management, and it delivers the perfect solution for enterprises that require a secure data management and data protection platform. Portworx allows users to build layered security solutions that meet their compliance and/or regulatory requirements.
For this blog, we will discuss how role-based access control (RBAC) and auditing/logging can be used to limit access to resources and then to monitor and audit users.
Role-based Access Control (RBAC)
Portworx Role-based Access Control (RBAC) security is composed of three models:
Authentication: A model for verifying the token is correct and generated from a trusted issuer
Authorization: A model for verifying access to a particular request type according to the role or roles applied to the user
Ownership: A model for determining access to resources
Portworx RBAC revolves 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 provides the token to Portworx for identification. No passwords are ever sent to Portworx.
As a result of this secure model, Portworx only has 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.
Authentication is based on RBAC 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 token authority 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.
Note: Authentication does not mean a requester has access to do something; the user must be authorized first.
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 that enable access to certain SDK calls.
In this case, an owner 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 – whether aa volume, snapshot, clone, or another related object.
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—that defines 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 restore the volume from a snapshot—in addition to all Read access.
An Admin access type allows full access to the volume—such as deleting the volume—in addition to all Write access.
Lastly, even with purpose-built security for Kubernetes, administrators should audit security by providing security audit logs. Portworx provides security audit and access logs so organizations can help protect critical data, identify security loopholes, create new security policies, and track the effectiveness of security strategies.
Configure Portworx to Enable Security
When generating the storageCluster specification on PX-Central in the Customize tab, select Security Settings and Enabling Authorization.
This will add the following section to the YAML prior to creation of the cluster:
In addition, the following secrets will be generated in the kube-system namespace:
Shared Secret stored under the secret px-shared-secret
Admin token stored under the secret px-admin-token
User token stored under the secret px-user-token
Now that we have enabled authorization on the Portworx Storage Cluster, we will showcase role-based access control and auditing. We will set up a simple multi-tenancy solution using a self-signed security configuration. To facilitate creation of the tokens, we will utilize the Portworx client, which can be used standalone or as an add-on with kubectl. From the machine where you will be running kubectl commands, it is as easy as downloading the latest version from the Releases page, extracting the files, and copying the executable into your PATH.
Note: The Portworx client is not supported and is provided as-is.
First, we will create a few namespaces that we will utilize to showcase how role-based access control and auditing can be used to configure a secure data management platform:
In the next section, we will go into more detail about the output of the above commands and review them as part of the audit logs.
Enabling Auditing and Logging with Amazon Cloudwatch and Portworx
Portworx provides security audit and access logs so organizations can help protect critical data, identify security loopholes, create new security policies, and track the effectiveness of security strategies. We will utilize Amazon CloudWatch Container Insights to aggregate the log information in Amazon CloudWatch using Fluent Bit.
The logs are available on each Portworx node at the following locations:
After that change has been made, the PVC will be successfully created. You can see the logs transition from Access Denied to Volume ID created by firstname.lastname@example.org.
Role-based access controls allow for integration into a customer’s existing authentication frameworks, making it possible to utilize authorization and ownership. This gives users the ability to deploy mission-critical applications into production.
For example, integrating per container data volume access controls 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.
The capability to log and audit user access of the volumes allows customers to integrate Portworx into their existing security frameworks and conform to any security requirements. Audit logs are important, as they give customers the capability to detect and react to instances of inappropriate access to or use of information systems or data.
In the following demo, we will showcase these capabilities.
Subscribe for Updates
Portworx is the leader in cloud native storage for containers.
Thanks for subscribing!
Sr. Solutions Engineer | Cloud-Native BU, Pure Storage