How Nuon Works - Part 2, Customer Installs

This is the second post in a three part series on How Nuon Works.

In our last post, we talked about how to connect your app to Nuon, configure permissions, customer inputs and more. In this post, we will talk about what comes next — getting your app deployed into a customer's account. After all, that's the whole point of this Bring Your Own Cloud thing, isn't it?

BYOC Installs

I'll bear repeating myself again, BYOC is basically SaaS, but in your customer's cloud account. Basically, once your application is installed into your customer's cloud account — it should just work.

So, how do we get your app there? In BYOC, the first step of delivering your application is installing it somewhere. Yes, it's in their cloud account, but where exactly? In a sub-account, a new VPC in an existing account, maybe a whole new AWS organization? Every customer will inevitably be different.

Talk to any vendor who has offered BYOC and you'll hear the same thing — these BYOC installs are fraught with pitfalls at every part of the journey. Two weeks into integrating a customer, and all of a sudden you learn that your stakeholder has never touched a cloud console, let alone has access to get your install setup.

In other words, installs are where the dragons lie. Going at it alone requires solving a bunch of different problems, including:

• creating customer-managed, and toggle-able permissions for different lifecycles of the application.
• supporting different customer environments with a single app.
• updating your application and preventing unintended outages or side-effects in a customer's account.
• monitoring and mitigating issues with your application.
• governing your maintenance with audit logs, policies, and protecting against things like drift.

If you have tried this at home, you will already know that delivering on the promise of BYOC -- where it's just like SaaS -- in your customer's cloud account is not for the faint of heart. The good news is that we've learned a thing or two about this space, and are here to help you solve most of these problems!

Install Setup

In Nuon, an install is an instance of your (the vendor's) application, deployed into a customer's cloud account. Generally, the customer is responsible for paying the bill on their account, doing some basic account management (setting up IAM and other organizational configuration), and sometimes even providing infrastructure for your application to run in or integrate with. From there on, the customer gets to be hands-off, reaping the benefits of your operational work. Sounds easy, right?

While you have one app, each of your customer's cloud accounts will be slightly different. Nuon makes it easy to install your app in any customer's account despite these differences. You can control your app, expose different configurations and requirements for your customer to provide, and we'll do the rest.

Nuon lets you define different configuration options and toggles. You can create customer options such as controlling instance types, infrastructure resources to integrate into, or other customizations required. Customers can define secrets -- allowing your application to safely access vendor managed resources -- without ever needing direct access to a key or secret.

Permissionless Install Stacks

The first rule of BYOC is that your customer will never (and should never!) grant you direct access to their account. While it's tempting to just ask for a cross-account IAM role, or a service account granting you access, the problem with this is that your customer has no ability to understand how you are using that role or what you are using it for. Simply put, permissions at the cloud account or kubernetes cluster level are not enough. (You can read more about our learnings in our deep dive on the Nuon Runner, here.)

Nuon is designed to let your customer install and manage your application without ever needing to grant direct access to their cloud account. We do this by giving you a bundle that your customer can install themselves.

When you create an Install of your app (either via CLI, UI, or a config file), Nuon automatically generates a CloudFormation Stack, Azure Resource Stack or a Google Deployment Manager Stack that your customer can use to install your application. This is a lightweight template that bootstraps your application. It exposes a secure way to ask the customer for secrets , configuration options, such as selecting an existing VPC to install into.

All your customer has to do is take this stack, fill in the options, and execute it. Both you and your customer can sit back while Nuon does all the work to provision your app in their account!

We designed Nuon with this bootstrap step in mind, so you could easily deploy into a customer's account with zero trust. Your customer can inspect the permissions, turn them on or off, and provide inputs, secrets, and infrastructure to complete the install, without ever needing to grant you direct access.

The stack is essentially the customer interface for managing your app in their account.

Architecture

Cool, you just handed your customer a cloud template that will install your application. So what exactly is this doing, and how does your application get spun up? Let's start by talking through the architecture of a Nuon install. There are four parts:

Stack — managed by the customer, in their account.

Runner — managed by the stack and responsible for provisioning, managing, and monitoring the application.

Sandbox — the network and cluster where the application is deployed into. This can be managed by the customer or the vendor.

Components and Actions — the vendor's application containers (images), infrastructure as code (components), and setup scripts (actions).

Now we will talk through each part of this architecture, and how Nuon helps you support customer configurations and options, with a single application.

Customer Stack

Each install is powered by an Install Stack: a portable AWS, Azure, or Google stack that your customer can run to install the application in their account. Since the stack is executed directly inside a customer's account using their permissions, they can not only inspect the resources when the install is being setup, but can easily share it with their IT, DevOps, or Cloud team to setup.

Each stack creates three roles by default: provision, maintenance, and deprovision. Vendors can configure additional roles that are needed for break-glass or other access requiring elevated permissions. It's critical that all permissions management happens via the stack, to prevent privilege escalation. For example, to prevent the runner from granting additional permissions or creating new IAM roles after initial setup.

The stack is customer-managed and has controls built in to enable the customer to remove permissions, or completely cut off access to the vendor.

Runner

The Nuon runner is an agent that runs alongside your application in each customer account. It runs on a virtual machine inside the customer-managed or newly-provisioned VPC and is responsible for provisioning, managing, and monitoring the application.

The runner is designed to have toggle-able permissions which a customer can dynamically add or remove. Because the runner is the only permissible actor in the install, customers can easily disable it to cut off all management access for a partially air-gapped environment.

Once the stack is provisioned, the runner boots up inside the customer's cloud environment and checks in with the Nuon control-plane, so it can provision the app.

You can learn more about the Nuon runner in our Deep Dive.

Sandbox

Once the Runner is provisioned via the Install Stack, it will connect to the Nuon Control Plane and start the provisioning process. The first thing that it provisions is the sandbox, which is the cluster and other infrastructure primitives your app will be deployed onto.

The sandbox is part of your application config, which we covered in part 1. You can choose a Nuon-managed sandbox (one of our templates that are tested, updated and managed by the Nuon team), or create your own.

The runner is designed to live alongside the sandbox so that it can manage upgrades and patches for it. For instance, if the runner is deployed inside the cluster and the cluster is updating, or has downtime, then the customer's install can easily fall into an unrecoverable state.

Components and Applications

Remember the components you defined in Part 1? These aren't just static configurations, they form a dependency graph of your application containers, infrastructure-as-code, and custom setup scripts. As you change customer inputs, or customer managed secrets, your application will change and cause parts of the graph to change.

And voilà! Just like that, your app is running in your customer's cloud account. This whole setup process usually takes about 10 minutes of customer time and maybe another 30 minutes or so of provisioning. You can define actions for post install setup and doing long-tail configuration or enablement operations like enabling a license or more.

In Part 3, we'll talk about maintenance mode and how to keep your application running in each customer's account as you continually change, update, and iterate on your product.

Install Security

Once your application is configured and running in a customer's account, the customer should be able to make some guarantees around what you, as an operator, can access during maintenance mode. Your customer should be able to govern your infrastructure access (cloud account or network) and application access. For instance, preventing unforeseen side effects, like mutating existing resources or exposing an application to the network, require application guardrails not just at the infrastructure level, but also at the app level too.

Nuon enables you to define customer permissions for maintenance mode and break-glass operations that can be enabled and disabled by the customer. At the application level, policies can be used to govern the install's cluster to prevent changes, and, finally, we are working on support for adding policies into the platform natively so you can use policies to prevent changes from even being attempted by the runner!

If all else fails, a customer can even disable the Nuon runner altogether — effectively cutting off all maintenance capabilities.

Kyverno Policies

You can define Kyverno policies that Nuon will automatically provision into the cluster when setting up a customer install.

Policies at the cluster layer govern what the runner can do, and enable you to make guarantees to your customers
about what types of updates you can do during day-2 maintenance.

Toggle-able Cloud Permissions

In your config file, you define the cloud permissions that your application needs. There are 4 types of permissions:

• Provision — used for initial install setup.
• Maintenance — used for ongoing application maintenance and monitoring.
• Deprovision — used for tearing down an install.
• Break Glass — used for temporarily escalating permissions for migrations or other extenuating operational circumstances.

Once your customer has set up their install, they can go back into the stack and cut off maintenance mode or manage break glass access. These permissions are requested by the vendor, and managed by the customer and are only usable by the runner inside the customer's install.

Audit Logging

Since the Runner is the only thing that can act in a customer's account, it can power a rich audit log where you can show your customers exactly what management operations you are doing, via an audit log.

The audit log shows all runner jobs, actions, deploys and updates that were made to the application.

Future Policy Enforcement

We've found that leading with policies to govern what your application can do helps vendors deliver a more trustworthy and secure option to their customers when deploying in their cloud account, even just in the customer environment.

We believe that the future of BYOC requires better security policy primitives that allow for creating an open standard for how software is run in customer cloud accounts. There should be standards about what goes into the customer's cloud account, and what type of permissions make the most sense for each customer.

Break Glass

Nuon enables you to define break glass actions, and their corresponding roles for managing customer migrations, and mitigating issues that are otherwise unrecoverable. You can define actions that require elevated permissions and then define the permissions required for those actions. Your customer can optionally enable or disable the permissions via their stack, allowing or disallowing the actions to be run.

This enables you to safely escalate during setup or times of crisis, and safely lock down a customer install afterward.

Managing Customer Installs

With BYOC, different customers will have different management needs. You can decide between giving customers a fully automated experience by building Nuon into your product using our API, managing customers manually with our dashboard, or managing customers with a version control system and config files.

A would lifecycle for a customer install would consist of creating their install via our dashboard, and then using config files to manage updates.

Once each customer is set up, they will also have different requirements for how, when or even if you can manage and update their install during day-2. Some customers will be willing to grant elevated maintenance mode access, enabling you to offer a full SaaS-like experience, while others may only be open to occasional access for updates during dedicated maintenance windows.

With Nuon, you can let your customer control their preferred level of access while maintaining only a single BYOC application for your product.

Stay Tuned for Part 3

If you have made it this far, you can tell that doing BYOC right, is a LOT. While pulling together most or all of these pieces on your own is possible, it requires you, as a vendor, to become an expert in BYOC. Your customers will need you to overcome many challenges and hurdles to ensure your application is secure in their accounts.

Nuon automates your installation, lets you support heterogenous-looking environments and customer deployments with a single application workflow and gives you a configurable security contract between you and your customer. We've taken the time to not only think through the challenges of offering BYOC, but to wrap them in an easily-deliverable package for you and your customers to reap the benefits!

Stay tuned for Part 3 where we talk through day-2 operations and the tools you have to manage installs after they are live in a customer account. Learn more about day-2 operations with Nuon in part 3 of this series.