March 2025: Feature releases & highlights

Switch between tenants, UI support for port forwarding command, sharing secrets between tenants, lock topics to specific hosts.

• Simplified flow to switch between tenants: we have added shortcuts in the UI to switch between tenant logins
• UI support to get the port forwarding supctl command: the Avassa Edge Platform command line tool supctl supports a way to forward traffic from a port at the edge to your workstation. This can, for example, be used to access an edge local Web UI. You can now get that command in the Avassa UI by selecting the service instance and copying the supctl command.
• Sharing secrets between tenants: The Avassa system cryptographically separates tenants, covering all domains, including secrets, networks, applications, and more. However, in certain use cases, it is helpful for a tenant to share a secret with other tenants explicitly. This is now supported.
• Lock pub/sub topics to specific hosts. Because cluster hosts might have different storage capabilities, you may want to ensure that certain topics are replicated to specific hosts in your site. That is now available through host label matching for topics.

Tenant logins

As a site provider, you might create tenants for different parts of your organization or external parties. When you have created a tenant with users, you probably want to provide information to the tenant regarding the login URL and supctl login command. These are now available as a shortcut in the UI. You can copy and pass on the information to your tenants.

If you act as the site provider and create tenants, it is common that you want to login to those tenants as well to validate things. Previously, you had to go through a normal logout-login flow. We have now added support for switching between tenants that you have logged in as:

UI support to get the port forwarding command

It is possible to proxy connections to a remote host that are accessible from a service running in the Avassa system. This can be useful, for example, to debug devices on the same local network as the Avassa host or reach a local Web User interface.

supctl do -s stockholm-sergel applications popcorn-controller service-instances \
  popcorn-controller-service-1 connect tcp 443 --ip-address 192.0.2.11 --bind 8443

In this example we are connecting to the IP address 192.0.2.11 on port tcp/443. The TCP connection is initiated from the service instance popcorn-controller-service-1 which runs on the edge site stockholm-sergel as a part of application popcorn-controller. The supctl command listens to port tcp/8443 locally and forwards any connections to this destination.

In order to get that command from the Web UI you can now do:

Read more about the port forwarding functionality.

Sharing secrets between tenants

It is a fundamental principle in Avassa that tenants are 100% isolated across domains, logs, secrets, applications, application networking and more. But in some circumstances it is helpful for a site provider to share secrets to application owners. This can be authentication information or certificates for example.

This can be achieved in two steps, the first step is to give access to a vault to another tenant using allow-tenant-access. The second step is that the application that wants to access this vault needs to specify which tenant that has the secret that one wants to access using from-tenant in the vault-secret or the value-from-secret section. (ℹ️ The value-from-secret statement will only succeed if it matches an allow statement).

Here’s an example:

Define a secret shared with two named tenants.

name: credentials
data:
  password: reallysecret
  user: admin
allow-image-access:
  - "*"
allow-tenant-access:
  - application-team-a
  - application-team-b
EOF

Now an application from application team a or b can pick up that secret:

name: app-team-as-amazing-app
services:
  - name: the-service
    volumes:
      - name: cert
        vault-secret:
          vault: my-app
          secret: cert
          from-tenant: platform-team
    variables:
      - name: MY_USER
        value-from-vault-secret:
          vault: my-app
          secret: credentials
          key: user
          from-tenant: platform-team

Read more about shared secrets.

Lock topics to hosts

The Avassa platform provides an edge native pub/sub bus called Volga. As a developer you can create topics to publish (and consume) data at the edge site. Topics can be consumed and queried locally or centrally through Control Tower APIs.

A Volga topic has certain characteristics. One is replication-factor, which is given the first time the topic is created. If you for example, have replication factor 3, all data produced to the topic will be replicated at 3 nodes. The nodes are chosen by Volga when the topic is created.

In a cluster the individual hosts might have different storage characteristics with the implication that you want to control to which hosts the topic is replicated. This can now be specified by using labels:

💡 match-host-labels A label expression that determines which hosts are eligible to replicate this topic. The label expression is evaluated when the topic is created. To re-evaluate it (and potentially move the topic), run the redistribute action on the topic.

In the screen shot below I have a site with 5 hosts: Three of them have dedicated large disks to store lots of telemetry data. They have been assigned the label disk = large.

Or in subctl:

% supctl show system sites site-1 --fields "hosts/[cluster-hostname,hostname,labels]" 
hosts:
  - cluster-hostname: site-1-001
    hostname: site-1-1
    labels: {}
  - cluster-hostname: site-1-002
    hostname: site-1-2
    labels: {}
  - cluster-hostname: site-1-003
    hostname: site-1-3
    labels:
      disk: large
  - cluster-hostname: site-1-004
    hostname: site-1-4
    labels:
      disk: large
  - cluster-hostname: site-1-005
    hostname: site-1-5
    labels:
      disk: large

Now lets create a topic on that site and produce some data:

% supctl -v do --site site-1 volga create-topic big-telemetry string --replication-factor 3 --match-host-labels "disk = large"

% supctl -v do --site site-1 volga topics big-telemetry produce largetext

And now checking the state of the topic gives, note the matched hosts:

% supctl show --site site-1 volga topics big-telemetry 
name: big-telemetry
tenant: b2
labels: {}
format: string
number-of-chunks: 100
creation-time: 2025-03-28T12:44:50.368Z
requested-replication-factor: 3
current-replication-factor: 3
persistence: disk
match-host-labels: disk = large
matched-hosts:
  - site-1-3
  - site-1-4
  - site-1-5
assigned-hosts:
  - site-1-3
  - site-1-4
  - site-1-5
unsynced-hosts: []
leader-host: site-1-3
worker-hosts:
  - site-1-4
  - site-1-5
size: 124 B
entries: 1

In this way you can optimize the storage of Volga topics at the sites.

Read more in these resources:

• pub/sub bus fundamentals
• WebSocket API create topic options.
• REST API create topic match label option.
• Redistribute action.

Other enhancements

1. The supctl csv output format ( -U, --csv ) now generates more spreadsheet friendly output
2. Alerts have a new kind field which makes it easier to sort alerts for different purposes:
   • infrastructure Alerts related to hosts, sites, cluster, etc.
   • application Application related alerts
   • security Security related alerts.
3. The command line interface supctl will, starting with version 25.2.6, now update itself. Once you install this version it will automatically update itself (silently) to match the version that the Control Tower you are connecting to has available. The installation command is available here: