Defining Network Access | Tessell
Enabling users to define inbound and outbound access rules for their VMs
Role in Project
Lead Designer (0-1)
Duration
4 months, 2 phases
Overview
Customers at Tessell had no way of managing network access on the platform, a service they had earlier commonly used on AWS and Azure. Requests went through calls, emails, SREs, and back-end engineers to be fulfilled, and this was causing frustration.
I led the end-to-end design of a native Security Configuration system: a dedicated app where users could define network access rules by creating custom security profiles or importing existing cloud security groups. The feature spanned 4 touchpoints across the platform, handled different cloud providers and permission models, and replaced an entirely manual, multi-team process with something users could do themselves.
Setting Context
What is Tessell?
Tessell is a DBaaS platform which allows users to deploy their databases, while handling the data infrastructure and enabling data management. It runs a multi-cloud architecture that supports a variety of database engines, to cater to any and all customer needs.
The apps we touch upon:
Provisioning (Where users can create DB services)
DB Services - Details Page (Where users can view & manage a DB service)
Servers - Details Page (Where users can view & manage a server)
Provisioning (Where users can create DB services)
DB Services - Details Page (Where users can view & manage a DB service)
Servers - Details Page (Where users can view & manage a server)
Problem Statement
Customers were frequently contacting Tessell support to help define network access rules for their database resources, something they could do by themselves on AWS and Azure.
The existing process:
At Tessell, users had to go through a longer, more cumbersome process to achieve the same result. They would reach out to the Customer Success team or SREs and make a verbal request, which was then sent over to backend developers, usually through a JIRA ticket. Once the developer has addressed the request, of whitelisting certain CIDR blocks or enabling certain network protocols, they come back to the SRE or Customer Success person, who then reach back to the customer. The customer checks if the whitelisting is done correctly and reflecting on their UI, and confirm back with Tessell.
The process was highly inefficient, taking about 3 days, for a task that took users just minutes on their earlier platforms. The need was clear: we needed to provide feature parity with the cloud providers customers were earlier using, to avoid delays and frustration. At the company’s end, this would also reduce manual effort, saving time and money.
Users needed a quick and self-serviceable way of defining network access rules for their Database Services
Understanding the Domain
To start with the project, I needed to understand what Security Groups are. I spoke with the Customer Success team, reviewed JIRA tickets from customer calls, and then conducted a thorough competitor analysis across AWS Security Groups, Azure Network Security Groups, and GCP Firewall Rules.
We chose these 3 by defining what a 'Security Group' meant to us:
a set of rules that defines inbound and outbound access to any cloud resource.
For each competitor, I mapped complete flows: creating a security group, attaching it to a resource, and viewing or editing it later. I documented differences in flows, touchpoints, interactions, and the granular details of what all a rule could contain.
AWS Security Groups
Azure NSGs
GCP FIrewall Rules
Attached to instances
Attached to Subnets or NICs
Attached to VPCs
Deny all inbound traffic, allow all outbound traffic by default
Deny all traffic by default
Deny all inbound traffic, allow all outbound traffic by default
Rules are stateful
Rules are stateful
Rules are stateful
Rules follow no priority order
Rules are priority-based
Rules are priority-based
Only allow rules can be defined
Both allow and deny rules defined
Both allow and deny rules defined
Our Personas
On the Tessell platform, 2 main personas would be dealing with these network access rules:
Database Administrator (DBA)
The DBA creates and manages the DB Services for which they are responsible. For changes to the servers or networks they are hosting on, they contact their Infra Admins or Account Admins.
JTBDs:
Apply the correct network security rules to their DB Services during creation or as maintenance.
Update network security for their DB Services when required.
Infrastructure Administrator (IA)
The IA manages varying levels of system infrastructure, depending on their role at their company. They generally create and maintain networks and servers within a subscription, handling their compute, storage, privacy and security.
JTBDs:
Create the required sets of network security rules for use by DBAs or other IAs. Maintain and update these as required
Apply the right set when setting up a new server, or updating the same,
Ideation & Process
Our initial iterations focused around letting users create security groups during Provisioning, or attach existing ones - this seemed like the most obvious answer to the problem presented to us, and was also similar to what AWS was following.
Although this approach works for others, for Tessell this neither fit existing patterns, nor did it seem scalable within this flow. While we worked on improving this flow, we also discovered further complexities, that affected the final designs.
While talking to Customer Success, we found that a few customers are already managing their Security Groups on cloud and would rather continue using those. To meet these requirements, we decided to host 2 separate entities on our platform: Security Profiles, and Registered Security Groups.
Security Profiles
A Tessell-native entity, consisting of a set of security rules defined by the user for a particular cloud subscription.
Registered Security Groups
Security Groups from the user’s AWS or Azure cloud, imported for use within Tessell, with the capability of syncing to the original on demand.
Creating a separate app:
We now had 2 factors leading us towards the creation of a separate app for managing these 2 entities. First, the number of actions required for creating and managing the Security Profiles and Registered Security Groups warranted a separate space, as opposed to being stuffed into an existing flow like Provisioning. Further, the persona of Infra Admin is who would be creating and managing the network security, while it is the Database Admins who more commonly use the Provisioning and DB Services apps.
For these 2 reasons, we took the decision to create a new app, placed within the Infrastructure Management family of apps, which included all other apps pertaining particularly to the duties of an Infra Admin.
Infrastructure Management
Differences in AWS and Azure:
Yet another factor within our design was that AWS and Azure differed in the kind and number of entities they supported. While AWS could support the attachment of 5 entities, Azure could support only 1. This led to us creating separate UIs for the two, and following through on these for each touchpoint. The below screens show the UI and interactions we finalised on for the Provisioning app.
Designing for Read-Only permissions:
A complication arose when we had to design the Provisioning UI for client X -- one of our biggest clients. The subscriptions of Client X mostly provided read-only permissions for all aspects, including network security and security groups. This meant that their users would only be able to use Registered Security Groups from their cloud subscription, and not attach any Security Profiles created on Tessell.
This created an issue, because during Provisioning, we also allowed users to create High Availability (HA) Instances. An HA instance communicates with the primary through the DB Port. entered into the ‘Port’ field within Connectivity. However, since the Registered Security Group selected here would define allowed traffic, the selected port needed to be whitelisted within the Registered Security Group, else Provisioning would fail. Further, this port needed to also be whitelisted within the Registered Security Groups attached to the HA instances.
HA Instances in a Read-Only Permissions Usecase - by default, all instances have the same Registered Security Group
When the user disables the toggle to select different Registered Security Groups for all
Selected Port changes to one that is present in all selected Registered Security Groups
Error message in case no common port is available
Final Design
The final design was based on a shift in concepts, moving away from trying to mimic “Security Groups” from our competition, to creating a separate app called “Security Configuration” as a holistic measure to manage access for all Tessell resources. The app handled creation and lifecycle management of the following 2 distinct entities:
Security Profiles:
A tessell-native entity, managed wholly on the platform. The images show the entire journey, from the listing page where a user can see their security profiles, to how they create a new profile, and the details page where they can see and edit the rules, associated resources, and ownership of their profile.
Security Profiles - Listing Page
Security Profiles - Creation Page
Security Profile Detailed View - Security Rules tab
Security Profile Detailed View - Linked Resources tab
Registered Security Groups:
A cloud-hosted entity, synced to the Tessell platform for use on resources managed here. The images show a user's journey, from the listing page where a user can see their registered security groups, to how they register a new group, and the details page where they can see specifications of the rules, associated resources, and ownership.
Registered Security Groups - Listing Page
Registered Security Groups - Registration Panel
Registered Security Group Detailed View - Security Rules tab
Registered Security Group Detailed View - Linked Resources tab
The created Security Profiles or Registered Security Groups were then available for use across the platform at different touchpoints, the 3 prominent ones being the Provisioning, DB Services and Servers apps.
I. Provisioning
Within the connectivity panel of the Provisioning form, a Security Configuration section was added. The options given to the user varied, depending on the selected cloud, engine, as well as the permissions of the specific client.
II. DB Services
Security Configuration was added in the ‘Connection Details’ section of a DB Service’s Overview. For dedicated services, a Database admin could edit it from here, when required.
III. Servers
All servers displayed the Security Configuration within the Overview page itself. For Shared servers, Infra admins could edit the security configuration could from a ‘Connectivity’ section we created within Settings.
Impact & Reflection
Post development and testing, the application was presented in a customer demo where it received highly positive feedback. It is set to soon be released onto the Tessell platform in a phased manner.
Moreover, what started as a small project evolved into an entire app added to the Tessell ecosystem. As a newly joined designer, I was extremely grateful for the trust placed in me to take on a project of this magnitude, and to have contributed at this scale.
Oops.
This page isn't yet optimised for this viewing ratio. Check out this site on a laptop or PC to see!