Deprecation Notices

Strongbox Vault Secrets allow-image-access

Summary

The allow-image-access setting in Strongbox vault secrets is now deprecated and will be removed in a future release. A new setting, allow-application-access, has been introduced to provide a simpler, more secure, and more maintainable way to control which containers can access a secret.

Key Dates

Event	Date
Deprecation Notice Published	2025‑11‑26
Enforcement Date	2026‑01‑19

Affected interfaces

• REST API
• supctl CLI

Background

Historically, access to a Strongbox secret could be restricted based on container image hashes using the allow-image-access list. This required specifying the exact hash of every image that should have access. In practice, this has proven difficult to work with: even minor changes to an image---such as rebuilding it with updated base layers---produce a new hash, forcing administrators to constantly update their vault configuration.

Because of this, most users ended up setting allow-image-access to '*' (meaning "allow all images"), which defeats the purpose of precise access control and weakens security.

The New allow-application-access Setting

To address these problems, a new setting---allow-application-access---is now available. Instead of relying on image hashes, access is granted based on the application and service structure in the deployment.

Entries in this list can take one of the following forms:

• <application>
  Allow all services and containers within the application.

• <application>.<service>
  Allow all containers within a specific service.

• <application>.<service>.<container>
  Allow a specific container.

As with the old setting, you may use '*' to mean "all applications may access this secret", but this should be avoided unless absolutely necessary.

This new approach makes access control predictable and resilient to image rebuilds, without sacrificing security.

Compatibility and Migration

If an existing configuration currently has:

allow-image-access: ["*"]

then allow-application-access will automatically behave as if it were also set to:

["*"]

This ensures that no existing configuration breaks during the transition period.

To increase security, users should replace wildcard usage ('*') with explicit application/service/container entries. For example:

myapp.orders myapp.payments.frontend

During the deprecation period, access will be granted if either allow-image-access or allow-application-access matches the requesting container.

Removal of allow-image-access

The allow-image-access setting will be removed in a future release. Users should migrate to allow-application-access as soon as possible to ensure forward compatibility and stronger security.

Volga create-topic API change

Summary

We are removing the num-chunks parameter from the volga/create-topic endpoint.

The topic size can be more accurately specified using the max-size parameter instead.

Key Dates

Event	Date
Deprecation Notice Published	2025‑11‑14
Enforcement Date	2026‑01‑15

Affected interfaces

• REST API
• Websocket API
• supctl CLI

Migration instructions

Any topics currently having a num-chunks: N setting will automatically be converted to using max-size instead, with max-size being set to 1000000 * N bytes.

When creating new topics, the equivalent of "num-chunks": N is "max-size": "N MB".

Before:

{"name": "mytopic", "num-chunks": 5, "format": "string"}

After:

{"name": "mytopic", "max-size": "5 MB", "format": "string"}

Ingress inbound-access schema change

Summary

We are renaming

application/services/ingress-ip-per-instance/access

to

application/services/ingress-ip-per-instance/inbound-access

This was necessary to better distinguish between inbound and outbound access. The original name did not clearly convey directionality. This became evident after introducing outbound‑access rules. The new name aligns with established terminology across the platform.

The field access will be renamed to inbound-access. Any application specification referencing the old name will fail after the enforcement date.

Key Dates

Event	Date
Deprecation Notice Published	2025‑05‑14
Enforcement Date	2025‑07‑13

Affected Interface(s)

• REST API
• supctl CLI

Migration Instructions

# BEFORE
services:
  - name: pop-service
    network:
      ingress-ip-per-instance:
        protocols:
          - name: tcp
            port-ranges: "9000"
        access:
          allow-all: true
      outbound-access:
        allow-all: true

# AFTER
services:
  - name: pop-service
    network:
      ingress-ip-per-instance:
        protocols:
          - name: tcp
            port-ranges: "9000"
        inbound-access:
          allow-all: true
      outbound-access:
        allow-all: true

Replace access: with inbound-access: under every ingress-ip-per-instance block in application specifications.

---

Resource profiles for application owners

Summary

Site providers can limit resource usage for application owner subtenants using resource profiles. These can be associated per tenant or per tenant and sites. In the latter case the resource profiles are associated to the assigned sites for the tenant. Assigned sites represent the sites that are visible for the application owner tenant. The application owner tenant can assign their own labels to an assigned site:

In the current version of the Avassa APIs, as a site provider if you want to restrict resource usage for a tenant for a specific site you name the resource profile directly under assigned-sites for that tenant:

% supctl -v show tenants app-developers assigned-sites robot-1 --fields name,resource-profile
Using profile testing.edge.avassa.dev.
GET /v1/state/tenants/app-developers/assigned-sites/robot-1?fields=name%2Cresource-profile
...

name: robot-1
resource-profile: small

Objects owned by the site provider for a tenant will move to assigned-site/settings in coming releases. In this way, objects owned by the application owner like labels are directly accessible at /tenants/{tenant-name}/assigned-sites/{assigned-site-name}/

Whereas objects managed by the site-provider are available at:

/tenants/{tenant-name}/assigned-sites/{assigned-site-name}/settings

Key Dates

Event	Date
Deprecation Notice Published	2025‑05‑14
Enforcement Date	2025‑07‑13
Enforced in Release	25.8.1

Affected Interface(s)

• REST API
• supctl CLI

Migration Instructions

Any supctl or REST API call to assign or view a resource profile for an application owner needs to add settings to the path.

/tenants/{tenant-name}/assigned-sites/{assigned-site-name}/

to

/tenants/{tenant-name}/assigned-sites/{assigned-site-name}/settings