Security - Access to Private Registries

[arne-broering]

What authentication method? e.g.:

• Token-based API access
• User/password pair

Who provides credentials?

• App Developer
• WOS admin?
• WOA admin?
• Marketplace admin?
• ?

Where / how to store credentials?

• Environment variables
• Stored “secrets”
• Symphony: Reference to “secret” and WOA can resolve it from SecretStore
• …

[arne-broering]

The following sequence represents the current state of discussion:

1. WOA (representing the device) offers a way for the device owner to put a key pair (as first step).
2. Public key is sent by the WOA (maybe as part of device onboarding) to the WOS.
3. Once a desired state is requested, the WOS encrypts the secret with the public key and sends it along the desired state.
4. WOA can then decrypt the secret, interpret the deployment spec and get the required packages from the registry.

Open questions are:

• Who provides secret to registry? I.e., where is it coming from? e.g., WOS admin? App developer?

• How to provide different secrets for Docker Images referenced in the Helm chart? e.g., Image Pull Secret?

• How can an App Purchaser prove that she/he owns the app.

[arne-broering]

This extended sequence diagram attempts to answer the open question (1):

[phil-abb]

I think this can get quite complicated depending on what we need (or want) to support.

I don't know that application vendors are going to want to be giving out credentials to customers.

In addition to credentials, do we also need to ensure the application is only installed by the customer who has the right to install the application? I don't think we want to get into software licensing with Margo but do we need to do something as part of Margo to ensure the application is only deployable by customers getting access to the application through approved means?

So, how complex does this need to be, and what options do we have?

I can think of several different options:

• We only support registries that don't require pull credentials
  • Pro: This addresses the complexity of dealing with credentials
  • Con: It opens the door for anyone to be able to potentially install the application if they get access to the application definition.
  • Also, it still has the issue of how the WOS gets access to the application definition in the first place
• We only support application package bundles that contain all the helm charts (and/or docker-compose files) and docker images required (like CNAB's thick bundle)
  • Pro: This addresses the complexity of dealing with credentials
  • Con: it opens the door for anyone to be able to potentially install the application if they get access to the bundle
  • Also, it still has the issue of how the WOS gets access to the bundle in the first place
• We explore something like CNAB again and use this to allow the application vendor to include any encrypted credentials needed in their application definition (or keep it all in the CNAB) that can only be unencrypted by their CNAB bundle when it's installing the software
  • Pro: This allows the application vendor to keep control of their credentials
  • Con: Re-introduces the complexity of something like CNAB
  • Con: This wouldn't prevent the application from being installed by people who shouldn't be installing it if they got ahold of the application definition
  • Also, it still has the issue of how the WOS gets access to the bundle in the first place
• The WOS has a registry it uses so it uploads the helm charts and docker images from the application vendor into its registry and shares its credentials with the device
  • Pro: The application vendor doesn't have to share credentials with the customer
  • Con: The application vendor still has to share credentials with the WOS and there could be a lot of different WOS implementations
  • Con: This would add the extra requirement on the WOS to maintain a registry
• We support secure registries but require a Marketplace to act as the intermediary instead of the application vendor giving credentials to the customer. The application vendor and Marketplace vendor securely share the credentials. The Marketplace and WOS securely share the credentials, and then the WOS and WOA securely share the credentials.
  • Pro: This solves the issue of needing to provide credentials to the customer directly
  • Con: The credentials would still be available on the device so technically someone could get to them.
  • Con: If we don't limit Margo to a single Marketplace this means complexity with both the application vendor and WOS having to be able to integrate with any number of Marketplaces.
• We only support application package bundles and a single Marketplace. When the customer acquires the application bundle from the marketplace a key is generated based on certain information about the customer and application. The WOS validates the key with the Marketplace to determine if it's ok for the customer to install the application. In the response, the Marketplace returns the password to uncompress the application bundle
  • Pro: This solves the issue of needing to provide credentials to the customer directly
  • Pro: This solves the issue of only allowing customers to deploy the application if they get it through the proper channels
  • Con: This is very complex
  • Con: Not sure if we can say there is only one Marketplace since Margo doesn't want to maintain anything apart from the reference implementation and validation tests.

If we add on top of this the need to support air-gapped deployments then the problems just keep getting bigger.

[stormc]

I think this can get quite complicated depending on what we need (or want) to support.

This is the very question to answer IMO. What is the concern of Margo and what is out of scope, i.e., not the concern of Margo. There are many ― secure ― ways how to transport an application from a registry/repository down to the device and likewise many how an app developer gets the apps into such a registry/repository. Alike, there are many ways how to do licensing and license enforcement, even neglecting it altogether because of the effort-result ratio :) For any of these, you can find a technical solution to cater for them, however, IMO, this is not a pure technical but rather a business question: What would a Margo user/app developer expect improving the current situation out there?

I don't know that application vendors are going to want to be giving out credentials to customers.

With imposing this on app developers/vendors, we impose on them a particular Margo way how their process has to look like. The next question would be how to handle/advertise application updates, deprecations, ...

So, IMO, given all the different ways how to handle (a) app distribution and (b) licensing and no unifying layer in sight (to my knowledge at least), shouldn't we sidestep the problem and define+implement an interface including hooks for both concerns into which you can then hook the various ways of doing things out there in the field(s)... ?

[phil-abb]

Regardless of where we end up with securing credentials for OCI registries, I think the approach above can still be applied to enable the use of secret parameters that a customer may need to enter as part of configuring their application to be deployed to the edge. For example, configuring database passwords or sensitive connection strings.

[g0zilla]

We should at least cover the situation that image pulls require a docker login (or an equivalent to other container/image formats) and a way to configure certificates to avoid insecure registry configurations. Even within an organization, image registries will be protected.

[arne-broering]

Here is an approach that hides the secure access behind a PackageProvider interface:

I created a basic python implementation of this here: app-securtiy-trials

The design is inspired by Symphony's provider approach. Many thanks to @Haishi2016 !

Let's discuss on this in tomorrow's telco.

[phil-abb]

@arne-broering a few questions about this:

1. Who owns the PackageProvider, SecretProvider, and SecretStore?
2. Where does the PackageProvider, SecretProvider and SecretStore run?
3. Who populates the SecretStore with the secrets?

[arne-broering]

@arne-broering a few questions about this:

1. Who owns the PackageProvider, SecretProvider, and SecretStore?
2. Where does the PackageProvider, SecretProvider and SecretStore run?
3. Who populates the SecretStore with the secrets?

The PackageProvider could be (similar to 'Pulling Service' and 'Deployment Service' on the WOA) a component that margo defines as part of the WOS. Then, the PackageProvider could also run on the same (central) machine as the WOS, or it could even be considered a part that makes up the WOS. The SecretProvider and SecretStore are hidden behind the PackageProvider and margo could decide to not specify their details, as they can be implementation specific. Thereby, margo can indicate that secrets would be specified during installation of the WOS and onboarding of apps (and devices) and a central SecretStore would be filled in that process, without detailing the interface.