When one of our customers asks for control over their data, they mean full operational control over what goes in and out of the system. SaaS vendors usually know what permissions are required to deploy their app into the customer's environment, but what about maintenance and post-deployment operations? Do they still require such high-level permissions? Can they work with a reduced or crafted set of permissions and still serve their customers in the best way possible? Yes they can!
Assuming admin permissions for operational tasks can be dangerous, and expose your customer to the very risks that BYOC should eliminate in the first place. That’s why it’s vital to have different sets of operational abilities depending on the lifecycle of your customer deployment.
In order to design permissions in an optimal way for your specific purposes, we can break down operational requirements, correlate them to the roles needed for each phase of the app lifecycle, and then use the principle of least privilege to determine who needs what.
The Principle of Least Privilege
The principle of least privilege is the idea that every module — such as a process, a user, or a program — in a particular abstraction layer of a computing environment must be able to access only the information and resources that are necessary for its legitimate purpose.
A BYOC-style application has its own lifecycle, including regular maintenance, upgrades, debugging, and other situations where specific or elevated permissions might be needed. So PoLP in a BYOC context means that software vendors must operate under a very narrow set of permissions and boundaries to ensure only the required operations are being done in the customer's environment during each phase of the application’s lifecycle.
Control Layers and Access Requirements
Let’s break down various control layers of a BYOC environment, and access requirements at each layer. These examples are, well, simply examples! Keep in mind that specifics can vary from software to software.
Network Layer
The network layer is the outermost layer and is mostly controlled by the customers. Network layer requirements define what boundaries the vendor and customer operate within.
Software can operate under various network boundaries: a shared network with cross-network access, an isolated network with only intra-network communications, an egress-only network, airgapped network, and so on.
See more about Control Plane / Data Plane Architectures
Control Plane Access
The control plane is the operating layer for the vendors where they can perform operations like resource creation, scaling, updates, and upgrades. It also defines what permissions are assumed while performing such operations.
The control plane access for the lifecycle of a database application would look something like this:
Provision Phase
- Create application sandbox (cluster or any base infrastructure)
- Create resources necessary to boot up the database
- Create backup stores
- Create logging/telemetry store
Operating Phase
- Database runs on its own, with network ingress and egress rules to allow communication with the database
Maintenance/Upgrade Phase
- For backups, we need read access on the database, and write access on backup stores
- For upgrades, we need write access on database resources
Debugging/Break Glass
- Read access on telemetry store for debugging purposes
- Write access to other resources as needed on a case-by-case basis
Deprovision Phase
- This phase primarily requires delete permissions on various resources. Depending on the kind of deprovision, the permissions may vary.
In such cases, maintenance operations assume these permissions and operate with the same.
Data Plane Controls
The data plane is the storage layer where the data actually lives, along with definitions for who controls the data and what type of access the vendor has over the data.
Each layer has its own set of access control requirements and risk tolerance. BYOC for a SaaS offering should feel like a SaaS offering by giving flexible access as opposed to broader admin level access control to the SaaS providers. This enables them to serve the customers in the best way possible.
Let's take a look at few types of customers and requirements to understand this better:
Case 1: Fully Managed BYOC
Under this, the customer provides cloud access to software vendors with a broad set of permissions to allow them to manage their software end-to-end. The customer does not want to take any part in the software delivery lifecycle.
- Customer provides: Access to their cloud environment and access permissions that vendors request
- Vendor manages: Full infrastructure management, scaling, updates, and end-to-end delivery
- Operation mode: Operates with broad spectrum permissions and boundaries
Case 2: Restricted BYOC
The customer wants to restrict what the vendor can do. Ideally, permissions and network access should be limited and controlled by the customer.
- Customer provides: Limited set of permissions and network boundaries which customer can control
- Vendor manages: Operates under given bounds with a set of permissions enabled by the customer
- Operation mode: Operates under a restricted set of permissions and network boundaries
Case 3: Airgapped BYOC
This is the most complex style of BYOC where, once the application is deployed, the customer has control over the entire thing and the vendor only has access to a limited set of telemetry data to make sure their software is working as expected. For maintenance they rely either on remote diagnostics or schedules/orchestrated SOP.
- Customer provides: Once deployed, only limited telemetry endpoints are provided
- Vendor manages: Monitoring and on-demand support
- Operation mode: Operates under strict and controlled network environment and data flow/operating permissions
These examples are just a taste of the various "flavours" of BYOC, and the range of access control available to both the customer and the vendor. BYOC offerings exist along a spectrum, where control shifts from being predominantly customer-driven at one end to vendor-driven at the other.
Regardless of the specifics, customers must retain control over access boundaries and be able to restrict them as needed throughout the application lifecycle. When necessary, vendors should communicate their access requirements to customers. This allows customers to evaluate the needs and grant SaaS vendors the required access to optimally deliver their software.
Ready to get started?
Deploy your application into customer clouds
See how Nuon can help you unlock BYOC deployment for your entire customer base.