App Containers and Diego Cell VMs Attempting Outbound Calls to contracts.canonical.com

Products

• VMware Tanzu Platform Core

Issue/Introduction

On Tanzu Application Service (TAS) foundations, outbound firewall logs may show repeated blocked HTTPS connection attempts to contracts.canonical.com.

Administrators investigating this typically find a reference to the destination in /etc/ubuntu-advantage/uaclient.conf and /var/log/ubuntu-advantage.log inside an app container's rootfs (under the Diego cell's grootfs image store), which can suggest the app containers themselves are initiating the calls.

/rootfs/var/log/ubuntu-advantage.log: 

["", "DEBUG", "ubuntupro.http", "readurl", 464, "URL [POST] response: https://contracts.canonical.com/v1/contracts//machine-activity/, headers: {'server': 'nginx/', 'x-trace-id': '', ...}, data: {'activityID': '', 'activityPingInterval': 3600, 'activityToken': '', 'resources': ['esm-infra'], 'series': 'jammy'}", {}]

Cause

There are two separate, related factors:

1. cflinuxfs4 rootfs artifact (not the source of live traffic)
   • The ubuntu-advantage.log and uaclient.conf files found inside an app container's rootfs are leftover build-time artifacts from when Broadcom assembles the cflinuxfs4 stack image on internal build infrastructure. That build process attaches an Ubuntu Pro/ESM subscription to pull security-patched packages into the stack. The resulting log file should not ship in the image, but its presence does not mean the container generated the traffic. The container has no systemd and cannot run the Ubuntu Pro client's scheduled jobs.
2. Diego cell VM (the actual source of live traffic)
   • The ubuntu-jammy stemcell ships with the Ubuntu Pro client (ubuntu-pro-client) installed and its systemd timers (ua-timer.timer, esm-cache.service, and related units) enabled by default. Even when the client is not attached to a Pro subscription, these timers still fire by default roughly every 6 hours per cell and attempt to reach contracts.canonical.com to refresh ESM/entitlement status. This is the real source of the outbound calls the firewall is blocking.

Resolution

No customer action is required, and it is safe to continue blocking outbound traffic to contracts.canonical.com at the firewall. This traffic has no effect on:

• Application staging or runtime
• ESM/CVE patch coverage on the stack (security patches are already baked into the stack image at build time, independent of this call succeeding)

The blocked call only affects a local, informational cache used for update-availability messaging (e.g., MOTD-style notices). Nothing functional depends on it.

Broadcom is addressing the root cause in two ways:

• Masking the Ubuntu Pro client's systemd timers in the stemcell build so the periodic check-in no longer fires from Diego cell VMs.
• Removing the stray ubuntu-advantage.log/build artifact from the cflinuxfs4 rootfs so it no longer appears inside app containers.

These fixes are expected in a future stemcell and cflinuxfs4 stack release. Until then, keeping the existing firewall block in place is the correct and sufficient action.