Runner security model

Get started with Nextmv container runner security model

The service is authenticated through TLS / certificate to the client. The client passes an API key in metadata to authenticate/authorize with the service. This follows a standard convention for gRPC using RPC credentials in metadata for the authorization request over TLS.

An unauthenticated bootstrapping command ran after the initial deployment of the runner from the Nextmv CLI creates a root administrator key. The service can only be bootstrapped once, and a key is required once bootstrapped.

Administrators can do three operations:

  • Create additional administrators - no special privileges are tied to the root administrator. These keys are named to log auditing information for administrative operations performed.
  • Create application API keys - API keys are used to access the gRPC APIs. API keys are also named for logging purposes.
  • Disable an application or an administrator API key.

The key is provided as part of the gRPC invocation.

Example client connection in Go

(using google.golang.org/grpc/credentials)

rpcCreds := NewAuthAccess(&Token{AccessToken: apiKey})
   opts = []grpc.DialOption{
   AddGRPCRetries(opts, maxRetries)

 // Connects to gRPC server at host
 conn, err := grpc.Dial(host, opts...)

The runner doesn't manage access at the level of user, rather it is intended to be accessed from an application service that enforces and manages users access to performing runs. The runner helps an application associate a run to a specific account or user context through an owner property retained for runs, however there is no boundary enforcement within the runner itself related to owner.

Page last updated

Go to on-page nav menu