A standard manifest creates resources, but an operator continuously manages them through their lifecycle. For stateful services, that means it can observe cluster state, apply migrations, coordinate upgrades, and enforce conventions such as ownership and status. The practical difference is automation of ongoing operations, not just initial creation, which is why operators fit recurring maintenance tasks better than static manifests.
Why the Difference Matters for Stateful Kubernetes Services
A standard manifest is declarative and finite: it describes the desired objects, but it does not keep reasoning about them after creation. An operator adds a control loop, so the workload can be managed as a living system. That matters most for stateful services because upgrades, failover, backups, schema changes, and recovery are not one-time setup tasks.
For a stateful service, the difference is not just convenience. A manifest may create a database or queue, but it leaves the hard operational decisions to humans or external automation. An operator can observe health, reconcile drift, and apply service-specific logic that understands sequencing, dependencies, and safe transitions. That is why operators are usually chosen when lifecycle correctness matters more than initial provisioning speed.
In practice, this changes the ownership model. With a manifest, the platform team installs resources and the application or data platform team carries the runbook. With an operator, more of that runbook becomes encoded in software, which is useful when the same stateful pattern must be repeated reliably across environments. The Kubernetes NHI Security Guide is relevant here because operators often sit alongside service accounts, RBAC, and admission controls that determine what the control loop may do.
What an Operator Does That a Manifest Cannot
An operator does more than create pods, services, config maps, or persistent volumes. It watches for changes in the custom resource, compares actual state with expected state, and reacts when something drifts. For a stateful service, that can include orderly failover, cluster membership management, backup scheduling, certificate renewal, or version-aware rollout logic.
This is the key distinction: a manifest expresses intent, while an operator encodes operational knowledge. If the service needs a migration before a new version starts, the operator can enforce that sequence. If replicas must come up in order, or a leader election step must complete before traffic shifts, the operator can coordinate it. A standard deployment manifest usually cannot express that service-specific decision logic without additional tooling.
That distinction also affects how failure is handled. A manifest relies on Kubernetes primitives and whatever external automation is layered on top. An operator can decide when a condition is transient, when to retry, when to pause a rollout, or when to surface a degraded state. For stateful systems, that judgement is often the difference between a controlled intervention and data inconsistency.
When credentials are part of the workflow, operators also need careful access scoping. The Kubernetes RBAC Guide is useful because an operator that can patch stateful resources, read Secrets, or trigger scale changes needs tightly bounded permissions, not blanket cluster-admin style access.
When to Prefer an Operator Over a Static Manifest
Choose an operator when the service has recurring operational decisions that cannot be safely reduced to “create and forget.” Typical signs are schema migrations, quorum management, backup and restore workflows, certificate or secret rotation, ordered upgrades, or environment-specific guardrails. The more the service depends on correct sequencing, the stronger the case for an operator.
Choose a standard manifest when the workload is stable, the operational steps are simple, and lifecycle handling is already provided elsewhere. If the deployment only needs a fixed set of objects and ordinary Kubernetes reconciliation is enough, an operator may add unnecessary complexity. Operators are powerful, but they also introduce code that must be tested, versioned, and secured like any other controller.
For stateful systems, the practical question is whether failure to automate the lifecycle would create human error, outage risk, or recovery delay. If the answer is yes, the operator is usually the better fit. If the answer is no, a manifest is often easier to reason about and easier to keep transparent.
Where deployment automation touches token or secret handling, the Kubernetes Service Account Token Guide is a useful companion, because many operators depend on service account tokens for API access and those tokens should be short-lived and auditable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Operators need tightly scoped permissions to manage stateful resources and Secrets. |
| CM-3 — Configuration Change Control | Operators automate lifecycle changes, migrations and upgrades that are configuration-controlled. | |
| IA-5 — Authenticator Management | Stateful operators often rely on service account tokens and other authenticators. | |
| Recommendation — Limit the operator’s permissions to only the Kubernetes actions it actually needs. Require controlled approval and testing for operator-driven state changes. Rotate and manage operator credentials on a defined lifecycle. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Operator service accounts are non-human identities that can easily be overprivileged. |
| NHI-07 — Long-Lived Secrets | Operators commonly depend on long-lived tokens or keys unless lifecycle is designed well. | |
| Recommendation — Audit operator identities and remove any permissions beyond the controller’s exact needs. Replace persistent operator secrets with short-lived credentials and rotation. | ||
Practitioner Guidance
What to verify: Check whether the stateful service has any lifecycle step that can fail silently if treated as a one-time deployment, such as migration order, failover sequencing, or backup consistency. If it does, a plain manifest is usually insufficient because the control problem is ongoing, not initial placement.
Decision rule: Use an operator when the workload needs repeated domain-specific actions that must happen in response to cluster state. Use a manifest when you only need declarative creation and Kubernetes-native reconciliation already covers the lifecycle.
Common mistake: Treating an operator as “just a smarter manifest.” It is really application logic with cluster privileges, which means you should review its upgrade path, failure modes, and access scope with the same seriousness as any other privileged component.
Practitioner takeaway: The right choice is the one that matches the operational burden of the stateful service, if the service needs ongoing judgement, encode it in an operator; if it only needs stable creation, keep the manifest simple.
Related resources from NHI Mgmt Group
- Kubernetes Operator
- How should teams design Kubernetes health checks for stateful services?
- How should security teams handle Kubernetes manifest misconfigurations before deployment?
- How should security teams implement stateful mock services for third-party dependencies in Docker and Kubernetes environments?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org