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 pot hills 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 immediately realize — delivering on that promise of BYOC, where it's just like SaaS, in your customer's cloud account is not for the faint of heart. 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, outside of cutting off your access at the first chance they get — 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. Customer's 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 (or 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 just the cloud account or 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 + manage your application without ever needing to grant direct access to their account. We do this by giving you a bundle that your customer can install in their cloud account.

When you create an Install of your app (either via CLI, UI, or a config-file), Nuon automatically generates a CloudFormation, Azure Resource Template or a Google Stack that your customer can use to install your application. This is a lightweight cloud template that bootstraps your application, and exposes a secure way to ask the customer for secrets, configuration options, and to provide things like an existing VPC.

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, so 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, exactly? 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, 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 a stack - a portable CloudFormation Stack, Azure or Google Cloud template 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 provisions three permission sets by default (provision, maintenance and deprovision roles), and vendor's can configure additional roles that are used for break-glass or other 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 toggleable 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 stack, it will connect to the Nuon Control Plane and start the provisioning process. The first thing that is 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 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 (actions). As you change customer inputs, or customer managed secret, 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 controlled, (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 customer's
about what types of updates you can do during day-2 maintenance.

Toggleable 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.

add an image of the cloudformation stack permissions here, or something animated like the homepage

Once your customer has setup their install, they can go back into the stack and remove permissions, cutting off maintenance mode, provision or enabling/disabling 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 customer's 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 vendor's 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 git, and versioned config files.

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

Once each customer is setup, 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 becoming an expert in BYOC and getting the right solution to many challenges and hurdles your customers will want you to face, to ensure your application is secure in their account.

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.