The first and most obvious challenge of BYOC is supporting all the cloud platforms you want to deploy to. Leveraging our runner architecture, Nuon is able to provide first-class support for the major cloud platforms, while maintaining a constistent experience for day-2 operations.

​
Install Stacks

To obviate the need for cross-account access to your customer’s account, we support installing the Nuon runner using each cloud platform’s native tools. This allows your customer to install the runner into their cloud account using the platform’s console or CLI, without granting you or Nuon any access. For each install you create, Nuon will generate an install stack that contains the runner and the base infrastructure it requires to start up and execute jobs. The specific resources vary by platform, but each stack includes:
  • A virtual network.
  • Private and public subnets for your application resources.
  • A virtual machine for the runner, deployed into it’s own separate subnet.
  • An identity and permissions to manage the required resources.
Nuon will generate links and CLI commands you can share with your customer to install the stack. You can also download the template if your customer would like to inspect it.
There is necessarily some variation here based on each platform’s capabilities, but we strive to keep the experience as consistent as possible.
AWSAzureGCP
Template LanguageCloudformationBicepTerraform
Deployed AsCloudformation StackARM DeploymentInfra Manager Deployment
GUI Installation
CLI Installation
Download Template

​
Access Control

Each cloud platform has it’s own conventions, best practices, and tools to manage access control. At the same time, BYOC requires an approach that can be consistently applied across all of them. How does Nuon balance these competing concerns?

​
Nuon Runner Identity-Based Authentication

The Nuon runner is designed to be platform-independent and stateless. When deployed, it is given an identity by the install stack, which is granted limited access to the cloud environment based on your application config. The runner does not store platform credentials. It will attempt to authenticate for each job it runs, using whatever identity has been assigned to it. Since your customer installs the stack, they have full control over it, and can revoke the runner identity’s access at any time using their cloud’s native access control. The runner will immediately lose access to the cloud environment if they do this.

​
Platform-Native Permissions

The access the runner identity has is controlled by each platform’s native access control features. See the page for each platform for implementation and configuration details.
AWSAzureGCP
Custom Roles and Permissions
Kyverno Policies on Runner Jobs
Kyverno Policies in Kubernetes Cluster

​
Cross-Platform Policy Enforcement

Coming soon…