Use separate SELinux domains for distinct operational roles, then share only the permissions that both roles genuinely need. In practice, create a common attribute or template for baseline access, and add narrower rules for installer-only actions such as home directory access or policy loading. This keeps the policy readable, limits privilege, and reduces the chance that maintenance code inherits installation rights.
Why SELinux policy should separate installation rights from maintenance rights
When the same Kubernetes binary performs two operational roles, the safest pattern is to model those roles as different SELinux domains and then let them share only the baseline permissions they truly need. That keeps the policy aligned to the real execution paths, so installer-only capabilities do not become permanent maintenance privileges simply because both actions happen inside one codebase.
For containerized workloads, that separation matters because the enforcement point is the SELinux domain, not the source tree or the deployment intent. If a maintenance path can transition into the installer domain, it inherits whatever that domain can touch, including sensitive filesystem locations, policy-loading paths, or privileged configuration surfaces. The goal is to make role boundaries explicit in policy instead of relying on application discipline.
A practical design starts with a common attribute or template for shared access, then layers narrower rules only where the installer workflow genuinely needs them. Shared rules should cover ordinary runtime behavior, while installer-specific rules should be narrowly scoped to actions such as writing setup state, touching home-directory data, or loading policy artifacts. That keeps the policy readable and makes review easier when the binary changes over time.
How to model common access without collapsing the domains
The core design choice is to treat the binary as one executable with multiple SELinux identities, not one identity with a long exception list. A shared base makes sense for read-only resources, standard logs, and other permissions that both roles legitimately need. What should stay separate are permissions whose blast radius is materially different, especially anything that can alter policy, modify persistent state outside the normal maintenance scope, or broaden access into other containers or host-adjacent locations.
This approach works best when the common layer is intentionally small. If the shared attribute becomes a catch-all, the two domains stop being meaningfully distinct and policy review turns into exception hunting. A narrower base also makes it easier to reason about future changes, because new permissions are added to one role only when the new behavior is genuinely required, rather than inherited by default.
In Kubernetes environments, that usually means matching SELinux policy to the container lifecycle. Installation may need bootstrap-time access that should never be present during routine maintenance, while maintenance may need ongoing operational access that should not be able to rewrite policy or expand its own authority. Keeping those paths distinct preserves least privilege even when packaging forces both workflows into one binary.
What a readable Kubernetes SELinux policy looks like in practice
Readable policy is not just a documentation win, it is a control mechanism. A common template makes the overlap visible, and the role-specific rules make the exceptions auditable. If a maintainer cannot explain why a rule exists for installer-only behavior, that rule is usually too broad, or it belongs in a different domain entirely.
For this reason, the policy should be reviewed around two questions: what every role must do, and what only installation must do. That split tends to surface hidden coupling, such as a maintenance task that was accidentally depending on bootstrap privileges, or an installer path that can be reduced to a one-time transition. The cleaner the boundary, the easier it is to prove that operational convenience has not become permanent privilege.
For teams managing containers and registry-delivered images, it also helps to validate the surrounding supply chain assumptions. Container policy should not rely on the hope that images stay unchanged, because a leaked secret or embedded credential can turn an apparently narrow binary into a much broader access path. NHIMG’s Ultimate Guide to NHIs is a useful companion reference when you are aligning role-based access with secret hygiene and privilege boundaries in containerized systems, and Docker Hub Auth Secrets in Container Images shows why embedded credentials can undermine otherwise careful access design.
Risk and Threat Considerations
When installer and maintenance permissions are merged, the main risk is privilege creep: a routine operational path inherits one-time setup rights and can then reach files, policy objects, or host-facing resources that were never meant to stay exposed. In a container platform, that can turn a maintenance action into a policy manipulation or persistence opportunity.
Failure mechanism: A shared domain accumulates both baseline and installer-only permissions, so the binary can later invoke sensitive setup behavior from a less trusted operational context. If the policy also touches mounted paths or loadable policy content, the privilege boundary becomes especially fragile.
Impact: Overbroad access increases the chance of unauthorized configuration changes, broader container escape consequences, and harder-to-audit maintenance pathways. It also makes least-privilege review less reliable because reviewers can no longer tell which rights are truly required for steady-state operation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | SELinux role separation is a least-privilege enforcement pattern. |
| CM-7 — Least Functionality | Narrow SELinux domains reduce unnecessary executable capability and policy surface. | |
| Recommendation — Limit each domain to the minimum permissions its role requires. Remove nonessential permissions from the shared base policy. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The question is about structuring access so operational roles stay distinct. |
| Recommendation — Define separate role permissions and review them for overlap. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The policy design is fundamentally about access restriction and role separation. |
| Recommendation — Apply role-based restrictions to separate installation and maintenance rights. | ||
| OWASP ASVS | V8 — Authorization | The binary needs different authorization boundaries for different operational actions. |
| Recommendation — Authorize installer-only actions separately from maintenance actions. | ||
Practitioner Guidance
What to verify: Confirm that the common attribute contains only permissions both roles truly need, and that installer-only rules are limited to one-time or bootstrap-style actions. If maintenance can reach the same sensitive files or policy objects as installation, the split is not tight enough.
What good looks like: A reviewer should be able to identify the maintenance domain, the installer domain, and the exact permissions that differ between them without tracing a long chain of exceptions. That is the practical signal that the policy is maintainable and not quietly expanding access over time.
Practitioner takeaway: The safest SELinux design is to make shared behavior small and explicit, then reserve elevated installer access for the narrowest possible domain so maintenance never inherits setup authority by accident.
Related resources from NHI Mgmt Group
- How should security teams decide whether JIT access is safe for non-human identities?
- How should security teams reduce OT remote access risk without blocking maintenance work?
- How should security teams govern Kubernetes access without giving users direct cluster credentials?
- How should security teams reduce Kubernetes access risk without slowing deployments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
