After upgrading

Some upgrades end with a step the platform cannot take for itself: the objects involved limit what the platform may do, and an identity that could create them could also lift the limits. The After upgrading tab of Settings → Lifecycle Manager collects these steps. While any is outstanding, the tab shows a count, and a reminder at the top of every page links to it:

The platform keeps working while they wait — which is why they are easy to forget.

The platform admin bundle

A release's platform admin bundle holds the cluster objects that fence accounts with wide rights: the account third-party chart upgrades run as and the admission policy that locks it down, the admission guards, and a grant that lets the Lifecycle module read them. Only a cluster administrator can apply it — once when the platform is installed, and again when a release changes it.

When the running release's bundle is not fully in place, the tab opens with a Platform admin bundle section: what is missing, why the platform needs it, and the command, with Copy:

kubectl apply --server-side --field-manager=stackship-installer --force-conflicts -f <release URL>/platform-admin.yaml

The portal shows the exact URL. Hand the command to a cluster administrator, who runs it with a cluster-admin kubeconfig. Applying it again is safe, and takes back any field someone changed by hand. The platform compares the bundle with the cluster every five minutes, so the section and the reminder clear on their own once it has been applied. Each object is listed as Present, Missing, Changed by hand or Unreadable — see Statuses.

A release rollout that needs the bundle cannot start without it: its pre-upgrade check release.prerequisites cannot be overridden.

Settings changed by hand

The Platform drift section shows the last scan for platform settings someone changed directly in the cluster, with Check now and Adopt into config — see Settings changed by hand.

Apply the access-control roles

The platform writes Kubernetes roles for the people and workloads it grants access to, under a permission ceiling it cannot widen itself — see The permission ceiling. When a release changes that ceiling, someone who already holds the rules has to apply it.

1. Open the After upgrading tab. The Clusters table lists each cluster with its State, when it was Last applied, and a Detail. What each state means is in Statuses.
2. Optionally, choose View the manifest to download the YAML that will be applied.
3. Choose Apply to all clusters. It needs rbac/projector/apply at the platform root. The manifest is sent to each cluster with your own credentials, each cluster's API server decides what you may write, and the change is recorded against your name, not the platform's. In practice that means the Platform Owner role.
4. When a cluster shows Needs a cluster administrator, the release adds rules no account on that cluster holds yet. The tab lists the missing rules and the commands, with Copy. A cluster administrator runs them once with a cluster-admin kubeconfig; the cluster then shows Ready — apply again to record, and one more Apply to all clusters records it.

The manifest is the same for every cluster and applying it twice changes nothing. When the tab also says Access limits not yet enforced, the platform is still writing access with its own account instead of the limited one; access works either way, and applying switches it over within a few minutes, without a restart.

If part of it is refused

Nothing breaks: every object in the manifest adds something, so a cluster that missed some is missing pieces, not carrying broken ones. The tab lists which objects did not land on which cluster, and why:

• Refused as forbidden — your account does not hold the Platform Owner role on that cluster yet, as on a cluster being set up for the first time. Apply the manifest there once with a cluster-admin kubeconfig; after that the tab can maintain it.
• Refused to widen the permission ceiling — the release adds rules no account on the cluster holds yet, and the cluster shows Needs a cluster administrator; see step 4 above.
• Admission policies not served — the cluster's API server does not serve the admissionregistration.k8s.io/v1 admission policies the manifest uses as guards, which needs Kubernetes 1.30 or later. Everything else works without them. Upgrade the cluster and apply again.
• Earlier Kyverno policies left in place — the Kyverno ClusterPolicies that carried the same guards before were not removed. They enforce the same rules, so nothing is unguarded; a cluster administrator deletes them, or you apply again once the other refusals are resolved.
• Unreachable — the cluster could not be reached. Check that its agent is running, then apply again.

Apply again as often as you need. Clusters that already succeeded are left as they are.