How Trusted Delivery Unifies Security Practices Like IAM, RBAC, & ABAC
The use of policy as code in GitOps pipelines simplifies the implementation of security practices such as RBAC, ABAC, and IAM. This post covers how policy as code can be used to define these practices declaratively and run compliance checks recurringly with Git as the single source of truth.
Who has access to which resources in a system, and what actions they can perform on these resources is of prime importance. Practices like IAM, authorization, and authentication have risen to tackle exactly this problem. However, in practice, modern cloud-native systems that are powered by Kubernetes have made it increasingly difficult for administrators to define and enforce access controls at scale.
In response to this, GitOps, with its Trusted Delivery approach to cloud-native systems, is the ideal solution to manage access controls whether they are the traditional RBAC, or the more fine-grained ABAC. In this post, we look at the different types of access controls available, and how they can be successfully implemented using GitOps and Trusted Delivery.
RBAC vs ABAC: Which to Use When?
Identity management processes are critical to protecting your sensitive data but it’s imperative to understand the different forms of protection available. RBAC and ABAC are two predominant approaches to identity management.
What is RBAC?
Role-based access control (RBAC), as the name suggests, allows access to team members based on their role in the organization. These decisions are generally made by an administrator who assigns the parameters of access to a given role.
This comes in handy in, say, a large project, where you can specify that the project manager has edit access to all project files, but the development team might have such access to only the code repositories. The access doesn’t vary with the individual, but with the role they fulfill.
What is ABAC?
Attribute-based access control (ABAC) considers numerous characteristics or attributes, including that of the user, the environment, and the resources. User attributes may include the user’s name, role, organization, identification, and so on. Environmental attributes include the location of data, the user’s time of access, and threat levels in the organization at that time. Resource attributes like date of creation, owner of the resource, data sensitivity, etc, are also factored in.
It’s important to note that ABAC offers much more versatile control variables than RBAC and is implemented to reduce security risks arising not just from unauthorized access, but also from malicious insiders. Nonetheless, using both approaches to structure access in an organization can prove to be beneficial for a more secure landscape.
The Challenges of Setting Up Policies and How Trusted Delivery Helps
One of the challenges of setting up policies using RBAC, ABAC, or IAM is that the set of policies needs to be set up inside the service manually — a rather painful process, since these need to be updated as the number of policies, users, and services changes.
Another issue stems from the fact that authorization code can get mixed up with application code. This makes it difficult for developers to upgrade and monitor the code since it gets replicated between different microservices. This leads to numerous security loopholes that can be exploited.
Finally, keeping the policies regularly updated is key to ensuring they stay relevant. This is not easy to do manually as it would require constantly updating many policies based on day-to-day changes, and with many development teams, this can be a hassle. This is something that needs to be done in a systematic way that leverages a purpose-built policy management tool.
Problems like these can be easily handled through Trusted Delivery which is policy-as-code integrated into the GitOps pipeline. It enforces security and compliance to enable a completely policy-driven deployment and operational automation. Weave GitOps Enterprise offers the ability to specify RBAC control using Git-based rules.
Trusted Delivery to Implement Access Controls
Trusted Delivery proactively prevents policy misconfigurations in the cloud and can accelerate the software delivery process from end to end. By definition, it is the process of enforcing security, compliance, and operational best practices in the delivery pipeline using policy as code. It serves codified policies that are essentially organization and sector-mandated rules and guidelines and embeds them into the GitOps pipeline, thus automating compliance checks.
Given how trusted delivery has facilitated continuous compliance and security checks, deployments can now be automated with greater confidence. Policy as code automates all pipeline checks and prevents developers from bypassing clearly defined security protocols. When deployed using Weave GitOps Enterprise, this practice can codify hundreds of policies, including GDPR, HIPAA, and PCI-DSS, among others, and ensures that all misconfigurations are detected, duly notified, and all deployments halted. In that sense, Trusted Delivery ensures that the system is secure from code commit to deployment to run time.
Weave GitOps’ policy engine supports the enforcement of OPA-based policies across the stack. It provides a high-level declarative language that can be used to specify policy as code, as well as a few simple APIs that support the offloading of policy decision-making from your product. Here’s how Trusted Delivery uses OPA and the Rego language to help implement various policies from existing systems:
RBAC
With RBAC, we need two particular pieces of information:
- Users (Name) and their roles (Department)
- Roles and their associated permissions (Read/Write)
A user will be authorized for all the permissions assigned to the roles they have and with Trusted Delivery, you can declaratively define the RBAC policy for your organization including the roles associated with users, permissions for certain roles, and even define any authorization decision made by RBAC.
ABAC
ABAC has three main components:
- User attributes (Eg. date of joining, roles like trader or analyst)
- Object attributes (Eg. Stock ticker symbols, their market, and their price per share)
- The logic for defining which combinations of attributes are valid (Eg. Only traders with a minimum of 10 years of experience are allowed to purchase stocks on Nasdaq over $2M)
Through Trusted Delivery, these attributes can be assigned to any entity and then be structured as JSON objects.
IAM
Identity and Access Management (IAM) is used for access control in the cloud. AWS allows you to create policies that can be mapped to users, roles, resources, and groups. With IAM, you can use allow or deny statements to enforce entities that can/can’t execute certain API calls.
What Makes GitOps a Secure Operational Framework?
While DevOps and IaC (infrastructure as code) played a key role in molding an ecosystem of organizations that comply with the global software development best practices, GitOps adoption is on the rise thanks to its ability to simplify the development process.
With Git at its heart, GitOps lays out a secure and compliant method of managing deployments with an audit trail that’s always available. It gives developers much-needed control over code changes that can be verified from a single source — Git.
Config as Code
GitOps uses Git to manage YAML files, making it easy to check if the system is meeting all the security requirements. Moreover, all access policies are declared in a config file. This gives you a clear picture of who has access to what, which can further be verified in code.
Further, any change in attributes is as easy as editing a Git repository and merging a pull request. This way, it’s very easy to keep policies updated, and even give developers edit access to certain policies and not others. There is more control and flexibility built into every step of policy management with trusted delivery.
Accessible Audit Trail
With Git comes version control, meaning you have complete visibility into what you shipped and it can be rolled back at any given point. The commit history itself is a verifiable trail of reviews, comments, and other decisions made to the repository.
The Single Source of Truth
Weave GitOps uses Git as the single source of truth and ensures that production matches the desired state kept in Git. It offers a common workflow for both code and infrastructure changes and automatically alerts developers if it encounters any drift from the desired state. Given the automation, there’s less room for human error, making the system all the more reliable.
Final Thoughts
Trusted delivery that is deployed using a policy as code solution like Weave GitOps automates security and compliance checks, making it a continuous process. It is due to this automation that numerous security practices like RBAC, ABAC, and IAM are now under one roof and can be now deployed as code. The end result is well-integrated security operations, and a more robust security posture.
Whitepaper: Trusted Delivery with GitOps and Policy as Code
Download our latest whitepaper and learn how automated security and compliance checks, in the form of policy as code, make automated continuous deployments safe and secure.
