Securing Kubernetes and Other Resources at Scale Using RBAC
Prisma, from Palo Alto Networks, sponsored this post.
Controlling information security for an organization of any size can quickly become a full-time job. One of the most effective ways of managing access control is with Role-Based Access Control, or RBAC. RBAC requires you to identify essential and distinct roles within your organization, and then implement your security strategy based on those roles. RBAC makes security administration simpler than managing security at a user level, but that doesn’t mean that it’s easy to get it right.
This article will discuss several reasons why an RBAC strategy is critical for your Kubernetes implementation. We’ll explain the parts that you need to get right and describe some potential pitfalls to avoid, so that your organization can remain secure and out of the news. While an effective RBAC strategy is essential for your Kubernetes environment, you should also design and implement RBAC across all of your organization’s resources.
RBAC Best Practices
With RBAC, you define specific roles within your organization and then add users to those roles as needed. A best practice for RBAC, and indeed any access management structure, is the principle of least privilege. This principle states that a user should have precisely the level of access required to accomplish their responsibilities, and no more. One way to achieve this is by preventing users from accessing resources by default and then granting them access to roles only as needed.
Another best practice is to keep it simple. The easier it is to understand and manage your method, the easier it will be to maintain and enforce. Complexity tends to breed a culture of taking shortcuts and implementing one-off solutions, both of which will lead to a reduction in control and an increase in potential problems. An effective way to reduce complexity is to invest in a single system to manage your RBAC plan. A secure, highly-available and maintainable system will help you to manage access within your Kubernetes environment, as well as your organization’s technical footprint.
Compliance and Staying Out of the News
Depending on the type of data that your organization manages, you may need to be aware of certain regulations and ensure that you remain in compliance with them. Failure to do so could result in the loss of your consumers’ trust and potentially severe legal repercussions. The last thing that you want is to become a lead story on the news because you didn’t protect your data. Why does this belong in a discussion about RBAC? Below, we will illustrate why it’s important to ensure that only those who are responsible for securing sensitive data can access it, by examining a couple of regulations and describing their basic requirements.
HIPAA
The Health Insurance Portability and Accountability Act (HIPAA) of 1996 explicitly protects the privacy of consumers’ health information. Organizations that manage this data need to ensure the confidentiality, integrity and availability of all electronically protected health information. They are also required to certify their compliance and protect against malicious and unauthorized use and disclosures of the data.
PCI
Payment Card Industry (PCI) standards and requirements cover the use and storage of payment card information. Members of your workforce who work with this data need to be certified to manage it. They are also required to protect it from threats from within the organization, as well as from outside of it.
GDPR and PII
The Global Data Protection Regulation (GDPR) of the European Union has the most stringent privacy and security restrictions of any policy worldwide. Even if your organization isn’t located in Europe, you’ll likely have consumers who have a right to its protections. There are hundreds of pages of legislation that describe the GDPR requirements. At its core, the GDPR requires organizations to safeguard personal information and enable those who ultimately own the data — the consumers themselves — to view, update, and even request to remove the data from all servers.
In addition, the same class of data — known as Personally Identifiable Information (PII) — is subject to similar protections worldwide. Examples include the California Consumer Privacy Act (CCPA) in the U.S., the Personal Data Protection Act (PDPA) in Malaysia, and The Privacy Act 1988 in Australia.
RBAC in the Modern Age
The IT infrastructures of modern enterprises can have global footprints since public cloud providers — such as Amazon Web Services, Microsoft Azure, and Google Cloud — enable organizations to support highly-available and secure resources worldwide. We’re able to deploy Kubernetes at scale within that infrastructure — along with privately-held data sources. Whether we’re dealing with a local cluster or a highly-distributed application servicing consumers from the edge, access security is paramount.
Kubernetes contains an RBAC API for managing access control within the cluster; and if you are only managing a single cluster, this may be all that you need. However, the chances are that you maintain resources in the public cloud as well as on local hardware. Implementing a central RBAC system that can provide authentication capabilities and controls for all of your resources is essential to your organization’s success — and its ability to protect critical data and infrastructure. Perhaps best of all, you don’t have to design and build your own system; experts in the information security field have already created, built and fortified systems that you can use to manage this critical function.
Feature image via Pixabay.
