January 2023: Feature releases & highlights

The releases during January have primarily focused on the following high-level areas:

• Host networking: you can now give a container full access to the host networking features. Be careful out there.
• MFA authentication in Control Tower: there is now an option to enforce Multi-Factor Authentication when creating Control Tower users. Individual users can also enable that themselves. Be cautious out there.
• Deployment history: When running an edge network, you need to be in control what happened at the edge sites: Which versions did we deploy? When did we upgrade? There is now an aggregated view of what happened to individual deployments over time. Be in control.
• Documentation enhancements: amongst other things, new fundamental sections on DNS and image handling. Be knowledgeable.

Host networking

The Avassa system automatically sets up the application network on all sites. Each application gets its own isolated and encrypted VXLAN network. This also keeps strong isolation in multi-tenancy use cases. You can read about the application networking in our documentation.

But in some cases, your application might need full access to the host networking features, for example, when Layer 2-connectivity to the host’s physical network is required. We have now added the possibility to attach an application’s service to the host’s default network namespace, so-called “host networking ”.

This is configured in your application specification as shown below:

name: popcorn
services:
	name: brutal-popper
	...
	network:
		host: true 

It should be noted that this functionality removes the isolation between the applications by giving the tenant the ability to, for example, send and eavesdrop on the traffic on all network interfaces in the host’s default namespaces. This capability gives the tenant read access to all other tenant application traffic. The best practice is to make sure that a tenant who is allowed to attach to the host’s default network namespace is only assigned to sites that are exclusively dedicated to this tenant

For the above to work the following steps need to be done:

• By default the Edge Enforcer install script enables user namespaces for increased isolation. When using the host networking feature needs to be disabled by passing the option --no-userns-remap

$ curl -s [<https://api.test.acme.avassa.net/install>](<https://api.test.acme.avassa.net/install>) | sudo sh -s -- --no-userns-remap

• The tenant needs to be granted service-host-network-mode capability. In many cases it makes sense to also open for  container-net-admin which gives the tenant full read/write access to the host’s network interfaces. The example below shows how to configure policies accordingly:

$ supctl create policy policies <<EOF
name: extended-networking
capabilities:
  container-net-admin: allow
  service-host-network-mode: allow
EOF

$ supctl merge tenants popcorn-systems <<EOF
policies:
  - extended-networking
EOF

Control Tower Multi-factor authentication

Before going into the new Control Tower MFA support, let us elaborate on the overall authentication mechanisms in Avassa.

• Users can be managed either by the Avassa built-in secrets manager, Strongbox, or an external OIDC provider.
• You can enable MFA for users: externally in the OIDC provider and 🆕 internally within Control Tower

We have a dedicated section in our documentation on configuring MFA.

During January we added for MFA configuration and usage in the Control Tower User Interface. The scenario below shows how to create a user, “joe@acme.com” and force MFA.

First create the user and tick the “Require multi-factor authentication” check-box:

In the list of users you will now see that Joe has a “Pending MFA activation” status:

When Joe tries to login the first time he will get the MFA QR code and URL to add that to any authenticator app, for example Google Activator.

Once Joe succesfully added the code, the admin can see that MFA is activated:

After Joe successfully activated MFA he can now continue with the actual MFA login:

Joe can now also inspect his user information, including MFA status.

The above scenario showed the case where the admin enforced MFA. It is also possible to create a local user with only user and password. The user can then enable MFA himself under the user menu shown above.

And as always, the process above can be managed over the command line supctl. We have added a QR rendering function to the command line. To be honest, the internal backlog demo of that feature was one of the most appreciated for a long time 😎

$ supctl do strongbox totp joe@acme.com get-qr-code

Deployment history

Being in charge of edge infrastructure and applications you need to be in full control what happens with the deployment of applications. You need to be able to answer questions like:

• when did we deploy version 2.0 of application X?
• to which sites have we deployed application X?

You might already be acquainted with the two topics that are relevant:

In Control Tower you can view the system:deployment-events to see an event based view of your deployments. For example

 {
    "tenant": "b2",
    "occurred-at": "2023-01-27T13:18:27.028Z",
    "id": "882e9eec-e1cc-4909-8578-2e6e2c9d29a2",
    "event": "deployment-initiated",
    "data": {
      "sites": [
        "helsingborg-roda-kvarn",
        "stockholm-sergel",
        "stockholm-sture"
      ],
      "application-version": "1.0",
      "application-deployment": "pop-everywhere",
      "application": "popcorn"
    }
  },

To see details around the application deployment per site you can inspect the system : scheduler-events at the site. (Use the —site option in supctl or select the site in the Control Tower User Interface and perform the search). An example is given below.

"time": "2023-01-27T13:18:30.857Z",
    "mtime": 1674825510857,
    "host": "helsingborg-roda-kvarn-001",
    "site": "helsingborg-roda-kvarn",
    "topic": "system:scheduler-events",
    "payload": {
      "tenant": "b2",
      "occurred-at": "2023-01-27T13:18:30.857Z",
      "id": "8cf95a72-9e73-4933-9c89-d293a6d37112",
      "event": "application-status-changed",
      "data": {
        "site": "helsingborg-roda-kvarn",
        "oper-status": "starting",
        "application-version": "1.0",
        "application-deployment": "pop-everywhere",
        "application": "popcorn"
      }
    }
  },

To learn more about using supctl to search logs see the tutorial.

During January we added an aggregated view of the deployment history. Per defined deployment, you can see each modification and the resulting changes to your edge sites.

This history is part of the state for the deployment, in the UI select a deployment and click “History”

Read from the bottom to see the time-line. The sites column to the right indicates added or removed sites based on the matching expression.

1. The above example illustrates the following life-cycle events:
2. The deployment was created and matched 2 sites
3. Later the deployment was updated with new label expression witch matched 2 additional sites
4. A redeploy was invoked to match any new potential sites matching the expression, but no new sites
5. The deployment was updated to refer to version 2 of the application. The deployment of version 2 failed.
6. The issue in the application was fixed and the deployment succeeded
7. Finally, the label expression was modified which resulted in 2 sites being removed.

You can drill down to each event and see details, for example:

Here you can see that version 2 of the application was deployed to 3 sites but failed on “stockholm-sture”. This is vital information in order to understand which versions where running where under a distributed edge deployment.

In order to view the history in supctl you can perform the following command:

$ supctl show application-deployments popcorn-deployment --fields history

history:
  - time: 2023-01-31T14:45:20Z
    reason: application-deployment-updated
    version: "2.0"
    result: deployed
    removed-sites:
      - gothenburg-bergakungen
      - helsingborg-roda-kvarn
  - time: 2023-01-31T14:43:45Z
    reason: application-updated
    version: "2.0"
    result: deployed
  - time: 2023-01-31T14:31:52Z
    reason: application-deployment-updated
    version: "2.0"
    result: deploy-failed
    deploy-failed:
      - stockholm-sture
    deployed-to:
      - gothenburg-bergakungen
      - helsingborg-roda-kvarn
      - stockholm-sergel
  - time: 2023-01-31T14:31:28Z
    reason: redeploy-invoked
    version: "1.0"
    result: deployed
  - time: 2023-01-31T14:30:55Z
    reason: application-deployment-updated
    version: "1.0"
    result: deployed
    added-sites:
      - gothenburg-bergakungen
      - helsingborg-roda-kvarn
  - time: 2023-01-31T14:30:29Z
    reason: application-deployment-created
    version: "1.0"
    result: deployed
    added-sites:
      - stockholm-sergel
      - stockholm-sture

Documentation additions

Additions to the documentation site, docs.avassa.io

• New fundamentals section on Avassa DNS
• As referenced above, an instruction how to configure Azure AD as an OIDC provider for a tenant
• Fundamentals section in container image management
• Updates in existing documentation (Edge Enforcer installation, Application Networking, Application Specification, Policies), regarding host networking

Did you know that the QR code was invented in 1994 by Masahiro Hara when playing a game of Go over lunch? He worked at Denso Wave a subsidiary of Toyota. They needed an effective way of tracking assembly parts during the process.

“I used to play Go on my lunch break. One day, while arranging the black and white pieces on the grid, it hit me that it represented a straightforward way of conveying information. It was a eureka moment.”

Masahiro Hara