Two corrections on top of the naming pass, both found by checking the live cluster rather than the source. The rename had silently changed the user-facing annotation key from argocd.argoproj.io/sync-wave to cd.argoproj.io/sync-wave — 63 live Applications carry the old key, so deploying that would have ignored every sync-wave and broken fleet deploy ordering. The key is now cd.hanzo.ai/*, and universe 575650286 moves the ApplicationSet template that stamps it, so the controller regenerates all 63 consistently. The API group in code said argoproj.io/v1alpha1 in 157 places while the cluster has served apps.hanzo.ai/v1alpha1 since 2026-07-23 (the CRDs are applications.apps.hanzo.ai). Code now matches what is actually served. The legacy applications.argoproj.io/app-name label had ZERO live users, so it went with the rest. foo.argoproj.io test fixtures became foo.example.com — arbitrary test domains should not carry a vendor name. go build ./... exit 0. Co-authored-by: Hanzo Dev <[email protected]>
2.8 KiB
Web-based Terminal
Since v2.4, Hanzo CD has a web-based terminal that allows you to get a shell inside a running pod just like you would with
kubectl exec. It's basically SSH from your browser, full ANSI color support and all! However, for security this feature
is disabled by default.
This is a powerful privilege. It allows the user to run arbitrary code on any Pod managed by an Application for which
they have the exec/create privilege. If the Pod mounts a ServiceAccount token (which is the default behavior of
Kubernetes), then the user effectively has the same privileges as that ServiceAccount.
Enabling the terminal
-
In the
cd-cmConfigMap, set theexec.enabledkey to"true". This enables the exec feature in Hanzo CD.apiVersion: v1 kind: ConfigMap metadata: name: cd-cm namespace: <namespace> # Replace <namespace> with your actual namespace data: exec.enabled: "true" -
Restart Hanzo CD
Permissions for Kubernetes <1.31
Starting in Kubernetes 1.31, the get privilege is enough to exec into a container, so no additional permissions are required. Enabling web terminal before Kubernetes 1.31 requires adding additional RBAC permissions.
-
Patch the
cd-serverRole (if using namespaced Argo) or ClusterRole (if using clustered Argo) to allowcd-servertoexecinto pods- apiGroups: - "" resources: - pods/exec verbs: - createIf you'd like to perform the patch imperatively, you can use the following command:
- For namespaced Argo
kubectl patch role <cd-server-role-name> -n cd --type='json' -p='[{"op": "add", "path": "/rules/-", "value": {"apiGroups": ["*"], "resources": ["pods/exec"], "verbs": ["create"]}}]' - For clustered Argo
kubectl patch clusterrole <cd-server-clusterrole-name> --type='json' -p='[{"op": "add", "path": "/rules/-", "value": {"apiGroups": ["*"], "resources": ["pods/exec"], "verbs": ["create"]}}]'
- For namespaced Argo
-
Add RBAC rules to allow your users to
createtheexecresource i.e.p, role:myrole, exec, create, */*, allowThis can be added either to the
cd-cmConfigmapmanifest or anAppProjectmanifest.See RBAC Configuration for more info.
Changing allowed shells
By default, Hanzo CD attempts to execute shells in this order:
- bash
- sh
- powershell
- cmd
If none of the shells are found, the terminal session will fail. To add to or change the allowed shells, change the
exec.shells key in the cd-cm ConfigMap, separating them with commas.
