The assumption
Migrating a self-managed Kubernetes cluster to ACK felt, in the first week, like crossing a security posture off the list. No more patching etcd. No more control-plane upgrades at 2 a.m. No more worrying about API server availability, no more diffing certificate rotation schedules against a maintenance calendar. It was easy to let that relief generalize into a broader, unstated belief: managed Kubernetes means a more secure Kubernetes, full stop. The relief was real. The generalization wasn't warranted, and it took me longer than I'd like to notice the gap between the two.
The key idea
Managed Kubernetes shrinks the list of things you operate. It leaves the list of things you're responsible for almost entirely intact: RBAC, network policy, admission control, and workload configuration are still yours.
The problem
What ACK actually manages is the control plane's operational burden: availability, patching, upgrades, etcd backups, the API server's uptime SLA. What it explicitly does not manage (and what Alibaba Cloud's own documentation is reasonably clear about, even if the marketing framing around "managed Kubernetes" tends to blur it) is nearly everything that determines whether workloads running inside that cluster are secure: RBAC bindings, network policies, pod security configuration, admission control, and what images are allowed to run. All of that remains exactly as much the operator's job on ACK as on a self-managed cluster.
The gap between "the control plane is managed" and "the cluster is secure" is easy to lose sight of precisely because the first part is true and represents a real, meaningful reduction in operational load. That truth makes it easy to extend a feeling of safety to parts of the system that received none of the benefit. The shared-responsibility line for Kubernetes isn't drawn in a place that maps neatly onto "things that felt hard before" versus "things that feel easy now." It's drawn between the control plane and everything running on top of it, and workload security lives entirely on the "everything running on top of it" side, regardless of how good the control plane's uptime looks.
Where the confusion actually starts
Part of the reason this is easy to miss is that ACK's onboarding experience is, deliberately, very good. The console walks you through cluster creation, node pool sizing, network plugin choice, and within a few minutes you have a working cluster with kubectl access and a green status indicator. That smoothness is a genuine product win. But it also means the first concrete experience most operators have with ACK is a system that appears to have already made a series of good decisions on their behalf, because the defaults work and nothing throws an error. Nothing in that flow tells you which of those decisions were actually security decisions versus availability decisions, and the two get bundled together in the feeling of "this all just worked."
The experiment
I stood up a default ACK cluster with no additional security configuration beyond what the console's default cluster creation flow applies, then checked several things that a self-managed cluster would need explicit attention to get right: whether default service accounts had any RBAC restrictions beyond Kubernetes' own defaults, whether any network policy existed to restrict pod-to-pod traffic across namespaces, whether any admission controller was enforcing pod security standards, and, separately, whether the audit log was capturing enough detail to reconstruct an RBAC-related incident after the fact.
# cluster created via console defaults, no custom add-ons selected
aliyun cs DescribeClusterDetail --ClusterId c-default-test | \
jq '.meta_data.NetworkMode, .meta_data.SecurityGroupId'
# "Terway"
# "sg-defaultauto"
kubectl auth can-i --list --as=system:serviceaccount:default:default
# create/get/list/watch on pods, configmaps, secrets in namespace "default"
# (identical to any unconfigured Kubernetes cluster's default binding)
The proof
RBAC and default service accounts
Default RBAC matched vanilla Kubernetes defaults, meaning no ACK-specific hardening had been applied, and the same over-privileged default service account behavior that's been a known Kubernetes footgun for years was present unchanged. Every namespace's default service account was automatically mounted into every pod that didn't explicitly opt out, and no cluster-level policy restricted what a compromised pod using that identity could do beyond what upstream Kubernetes restricts by default, which is not much.
kubectl get pod -n kube-system default-sa-test -o yaml | grep automountServiceAccountToken
# automountServiceAccountToken: true (default, unchanged)
kubectl get clusterrolebinding -o wide | grep default
# no ACK-added restriction on the default service account binding
Network policy and admission control
No network policy existed; every pod in every namespace could reach every other pod, identical to an unconfigured self-managed cluster. This matters more on ACK than the phrase "identical to self-managed" might suggest, because Terway (ACK's default CNI) is fully capable of enforcing network policies once they're written; the capability was present and unused, which is a slightly different failure mode than a CNI that can't enforce policy at all. The gap wasn't technical. It was that nobody had written the policy.
kubectl get networkpolicy --all-namespaces
# No resources found in any namespace.
No admission controller was enforcing pod security standards, so a pod requesting privileged: true or hostNetwork: true would be admitted without objection, exactly as it would on a bare kubeadm cluster with no additional configuration.
# this pod spec was admitted without any warning or rejection
apiVersion: v1
kind: Pod
metadata:
name: privileged-test
spec:
containers:
- name: test
image: busybox
securityContext:
privileged: true
hostNetwork: true
None of this is a defect in ACK. It's a managed control plane doing exactly what "managed control plane" means (managing the control plane) while leaving workload-level security exactly where Kubernetes leaves it by default, which is permissive. The audit log, for what it's worth, did capture the admission of that privileged pod correctly; the gap wasn't in observability of the decision, it was in the absence of anything positioned to have made a different decision in the first place.
What the same test looked like on a self-managed cluster
I ran the identical check against a kubeadm-provisioned cluster I still keep around for comparison, expecting a meaningfully different result, and didn't get one. Same default RBAC posture, same absent network policy, same admission of the privileged pod. The interesting finding wasn't that ACK was worse than self-managed Kubernetes. It's that ACK was exactly as permissive by default as self-managed Kubernetes, which contradicts the specific expectation that moving to a managed offering would raise the security floor rather than simply relocate the operational burden. If anything, the self-managed cluster's operator was slightly more likely to have already touched RBAC, if only because standing up kubeadm from scratch forces you to look at more of the manifests along the way. ACK's smoother path meant fewer forced encounters with the parts of the system that needed configuring, not more.
That comparison reframed the finding for me. This isn't a story about ACK falling short of some baseline. It's a story about a baseline (vanilla Kubernetes RBAC and network defaults) that has been permissive since the project's earliest releases, and about how a managed offering's convenience can make that old, well-documented permissiveness easier to inherit unknowingly rather than harder.
You might disagree
Alibaba Cloud would reasonably point out that ACK offers security add-ons (network policy support via Terway, integration with Security Center, admission control options, Pod Security Admission labels) and that none of this is hidden; it's opt-in configuration documented alongside the base product, the same shape as most managed Kubernetes offerings from any major cloud provider, including the hyperscalers whose managed Kubernetes products draw the exact same line between control-plane and workload responsibility. That's accurate, and I'm not arguing ACK is unusually insecure relative to its category, or that Alibaba Cloud is doing something other providers don't also do.
The argument is narrower: the marketing and mental model around "managed Kubernetes" imply a bigger reduction in operator responsibility than the actual technical boundary delivers, and that gap between perception and the documented shared-responsibility line is where real clusters end up under-configured. A vendor being honest in its documentation doesn't guarantee the honesty survives contact with a team's onboarding checklist, a launch deadline, and the very reasonable, very human tendency to assume that "managed" services subtract more work than they actually do. The documentation being correct is necessary but not sufficient; someone still has to read the specific paragraph that draws the line, at the moment it matters, rather than after an incident makes it matter retroactively.
There's a second, more charitable version of the counterargument worth taking seriously: that this is a training and process problem, not a product problem, and no amount of product design can compensate for a team that skips the security section of the onboarding docs. I think that's largely true, and it's part of why the fix I landed on isn't "Alibaba Cloud should change ACK's defaults" (changing Kubernetes' upstream RBAC and admission defaults is a much bigger, more contentious conversation than this piece, and one that would break plenty of existing workloads if flipped silently). The fix is procedural: treat the migration itself as the forcing function to have the RBAC and network-policy conversation, rather than treating a successful migration as evidence the conversation already happened.
What I think now
I now treat "we're on managed Kubernetes" as answering exactly one question (who's responsible for control-plane operations) and no others. Every other item on a Kubernetes security checklist (RBAC review, network policy, admission control, pod security standards, image provenance, audit log retention) gets asked and answered explicitly for an ACK cluster, with the same rigor as I'd apply to a self-managed one, because the honest answer is that migrating didn't change who owns those questions. I've also started treating the ease of ACK's default cluster creation as a reason for more deliberate follow-up, not less, precisely because a smooth onboarding experience is good at hiding which decisions were made and which were simply never made at all.
Concretely, that means a short, explicit checklist runs before any new ACK cluster is considered production-ready, regardless of how quickly the console produced a green status: a network policy baseline denying cross-namespace traffic by default, an admission controller enforcing at least the restricted Pod Security Standard, an RBAC audit that starts from "what does the default service account in each namespace actually need" rather than accepting the binding it ships with, and confirmation that the audit log is retained somewhere that survives node recycling. None of these are ACK features in the sense of things Alibaba Cloud built specifically; they're Kubernetes primitives that exist regardless of who runs the control plane, which is exactly the point. The managed part of managed Kubernetes was never going to configure them, and expecting otherwise was the actual error, not any specific gap in the product.
The lesson learned
A managed control plane is a genuine, valuable reduction in operational burden: I wouldn't go back to self-managing etcd by choice. But it draws a boundary around control-plane operations specifically, not around cluster security generally. Nearly every decision that determines whether workloads inside an ACK cluster are actually safe is still the operator's to make, in exactly the same way it was before the migration, and the fact that the control plane is someone else's problem now says nothing about whose problem the workloads running on top of it are.