The twelve capabilities.

Module 7 is the reference module. It is designed to be consulted, not read linearly, and the chapter shape reflects that. Each capability chapter follows the same pattern: what Portainer does, what you would otherwise assemble to do the same thing, the gotchas, and the follow-along in your lab.

The seven capabilities with deep chapters here are the ones Portainer owns end-to-end at the Configure and Consume layers of Module 3's phase model. The other four (cluster lifecycle, identity and SSO, GitOps and delivery, edge and disconnected) get short recap chapters at the end (chapter 10) pointing at the module that covers each properly, so if someone asks "where is templates and catalog taught," you can find it fast.

A gentle warning about scope. Portainer is a bigger surface than any one module can cover completely; each capability chapter is enough to make you competent, not exhaustive. When you need the exact click path or the current API shape, docs.portainer.io is authoritative; this module explains the mechanism and the decisions.

Portainer's RBAC model has three primitives: users, teams, and roles. Assignments happen at the intersection of a team and an environment (or an environment group); a user's effective role at any environment is derived from their team memberships and the group's access policy at request time. Environment-level access policies override group-level ones when both apply.

Roles in the Portainer sense are not Kubernetes ClusterRole or RoleBinding objects; they are Portainer's own authorization sets, evaluated by the server's bouncer and RBAC middleware. When a user hits a Docker or Kubernetes endpoint through Portainer, the request is authorized against the Portainer RBAC map (rbac_docker.go, rbac_kubernetes.go, and the raw-proxy path rbac_kubernetes.go) before Portainer forwards to the runtime. Two consequences of this design worth pinning down.

First, RBAC role definitions are refreshed by migration on upgrade (refresh_rbac_roles.go), which is why permissions can shift across releases; the shift is deliberate but you should tell a customer to review roles after a major upgrade. Second, on Kubernetes environments the raw-proxy path (a direct kubectl-style call through Portainer) has its own authorization mapping distinct from the named-handler mapping the UI uses. If a user can do a thing via the UI but a raw API call is 403, that is the two mappings disagreeing.

Environment groups drive tenancy

Multi-tenancy in Portainer is expressed through environment groups. A group holds a set of environments and a set of access policies (which teams get which roles). A single Portainer server can host groups per business unit, per environment (dev/staging/prod), per customer, or per any other tenancy axis; each group is a governance boundary.

On Kubernetes, tenancy also drops into namespaces. Portainer manages namespace-level RBAC (Environments → the cluster → Kubernetes → Namespaces → per-namespace access controls), and the per-user Kubernetes client cache is invalidated when namespace permission changes are made. If a user reports "I was granted access but still get 403," this is almost always cache lifetime; a re-login clears it.

Fleet governance covers how you apply consistent configuration, policy, and deployment intent across many environments at once, without touching each one individually. Portainer's answer is environment groups (for RBAC and policy), edge groups (for edge stacks, jobs, and configurations), and tags (for flexible filtering and dynamic edge group membership). Together these let one operator hold hundreds of environments coherently.

Environment groups (recap from chapter 02) scope RBAC and policy. Edge groups scope edge-specific concerns; they can be static (specific environment list) or dynamic (tag-based). A dynamic edge group with the rule "all Docker edge devices tagged retail-store" automatically covers a new device added to that tag; no separate deployment step needed. This is the mechanism you use for fleet growth: pre-existing edge stacks, edge configurations, and policies reach a new device the first time it polls, because the fleet operations targeted the group, not the individual environments.

Environment tags are freeform strings. Tags do not enforce anything on their own; they are inputs to dynamic edge groups and filters in the UI. Use them for the operational shape the customer actually has: region, location, customer, environment stage, hardware family. Do not use them for tenancy (environment groups do that); do not use them for RBAC (environment groups do that too); use them for filters and for edge group membership.

Environment overrides

Groups establish defaults; environment-level configuration overrides them where needed. Edge check-in intervals, for example, default to the global Settings value but can be overridden per endpoint. If a customer's industrial fleet has three sites with different link characteristics, you can globally set a sane default and override per site. Similarly, endpoint-level access policies override group-level ones; use with care, because overrides scattered across environments create the exact operational drift Module 1 warned about. Prefer groups.

Portainer policies are governance rules attached to environment groups; they enforce a rule across every matching environment in that group. Policies are typed; each type has an enforcement class, a minimum agent version, an environment-type applicability list, and a per-endpoint status the UI aggregates into a StatusBreakdown (Applied / Warning / Failed / InProgress / NotSupported).

The 2.45.0 catalog has thirteen policy types. Kubernetes-scoped types include rbac-k8s, security-k8s, setup-k8s, registry-k8s, observability-k8s, pod-security-standards-k8s, and network-security-k8s. Docker-family types (Docker, Podman, and Swarm) include rbac-docker, security-docker, setup-docker, registry-docker, and cleanup-docker. One type applies to all environment types: change-confirmation.

How policies land on an agent

Standard-mode edge agents receive policy desired state in their poll response. Agents at 2.43.0 or later receive the new per-policy state format; older agents receive a legacy per-chart summary. The two formats are mutually exclusive per response; the server picks based on the agent's version header. If a policy shows "NotSupported" on a device, the agent is below the type's minimum version, or the environment type does not match. Resource-patch types (currently pod-security-standards-k8s) require agent 2.44.0 or higher; earlier agents cannot apply it.

Async-mode edge agents only receive policy state when the async-policies feature flag is on (Module 5, chapter 9). Without it, the policy is silently not distributed to those environments; the UI will show them as unaddressed rather than failed. If your customer has async fleet, turn the flag on.

Two enforcement classes worth understanding

Helm-reconcile policies (rbac-k8s, security-k8s, setup-k8s, registry-k8s, observability-k8s, network-security-k8s) are applied by the agent as a Helm chart into the cluster. Detach reverses the chart. If a policy is removed but its resources remain, that usually means the agent's restore coordinator failed to reverse the chart cleanly; check the agent logs.

Resource-patch policies (currently pod-security-standards-k8s) apply owner-scoped field patches to existing cluster resources. Detach reverses those patches. Ordering matters on detach: patches are removed first, then the underlying chart, if any; this is why detach-then-reattach flaps look messier than clean removal.

A registry in Portainer is a stored reference to a container image registry: address, credentials, and per-environment access controls. Portainer supports Docker Hub, AWS ECR, Quay.io, Azure ACR, GitHub Container Registry, GitLab, and any registry that speaks Docker Registry v2. Each type has provider-appropriate credential handling; ECR gets IAM-style access keys, ACR uses Azure credentials, and the generic v2 case uses username and password.

Registry governance is not about hosting a registry; Portainer does not embed one. It is about controlling which environments can pull from which registry and which teams inside an environment can consume it. Registries are stored objects, and access is granted per team on Docker environments and per namespace on Kubernetes environments. The Kubernetes path also handles image pull secrets: Portainer creates them in the target namespace when a registry is granted access there.

What the registry-k8s and registry-docker policies do (from the chapter above) is fleet-scope this: a policy attached to a group can enforce a registry list across every environment in the group. Adding a new environment to that group means the registry policy applies to it automatically. Removing the policy detaches the configuration.

Portainer's alerting model has three cooperating pieces: an embedded Prometheus inside the server, an embedded Alertmanager inside the server, and agent-side rule evaluation on edge environments. Together they give you fleet-wide alerts without you having to run a separate observability stack for basic operational signals.

The embedded stack

The server runs an in-process Prometheus (TSDB, PromQL engine, scrape manager, rules manager, notifier) with 1-hour retention and a 15-second scrape interval, targeting the server's own /api/metrics. If the embedded Prometheus fails to start, the server logs "failed to create/start central prometheus service, continuing without it" and runs without server-side alert evaluation; the failure is non-fatal by design. Agent-evaluated alerts and the alerting settings API continue to work.

The embedded Alertmanager (on 127.0.0.1:9093, never exposed) accepts notifications from both the server-side Prometheus and from agent-side evaluators. It carries canonical inhibit rules so that a single incident firing at multiple severities gets deduplicated to the highest severity; critical inhibits warning and info, warning inhibits info, matched on alertname, alert_rule_id, portainer_environment_group_id, and portainer_environment_id. Alert rules created with custom labels outside this canonical shape do not inhibit each other; that is a common cause of "we get duplicate alerts at three severities for one thing."

Agent-side evaluation

Edge agents receive alert rules in their poll response (as structured rules plus pre-compiled Prometheus YAML). They run their own embedded rule evaluator (default 60s interval) against local metrics and notify the server's Alertmanager. This is what lets you alert on a device that is not directly scrapable from the Management Server. Invalid rule YAML is hash-tracked so an agent does not repeatedly try to apply broken rules; the agent reports the reload error back.

Notification receivers

The alerting settings API (/api/observability/alerting, admin) manages receivers (email, Slack, webhook, PagerDuty, and so on) and writes them into the Alertmanager configuration. A connectivity test endpoint lets you verify a receiver before saving it. Silences are also managed through this surface; a silence quiets alerts matching its label selector for a bounded window.

Portainer emits audit and activity events for every meaningful action: authentication attempts (with method, username, success/failure), environment mutations, RBAC changes, policy changes, stack deploys, add-on installs, and administrative actions. These events are recorded in the datastore for in-product review and streamed to syslog for SIEM ingestion.

The syslog integration supports rfc3164 or rfc5424 formats, over UDP, TCP, or TCP with TLS. Configure it through the Settings API or UI; once configured, Portainer streams events to the target syslog endpoint asynchronously. Failures do not block the originating action; a syslog outage does not lock up Portainer.

SIEM shape matters. Splunk, Elastic, Sumo, and Datadog all accept syslog; the format they prefer varies. Pick rfc5424 with TCP+TLS by default unless your SIEM specifically wants rfc3164, and always TLS in production. UDP is fine for a lab and unacceptable for anything sensitive.

Client IP correctness

The client IP recorded in the authentication activity log honors proxy headers only from IPs in --trusted-proxies. If you configured Portainer behind a load balancer and all your auth events show the load balancer's IP as the client, this is why. Add the load balancer's IP or CIDR to --trusted-proxies and the correct client IP will appear thereafter.

Day-2 operations is the collection of ongoing tasks a platform operator does after everything is stood up: inspecting containers and pods, streaming logs, opening exec sessions, restarting workloads, examining events, running one-off manifests, checking resource usage per namespace, and so on. Portainer's UI is the operator control plane for these tasks; the underlying runtime is what you already have.

On Kubernetes, this includes: applications view (a unified list of Deployments, StatefulSets, DaemonSets, and CronJobs with health status), pods view (individual pods with restart counts, resource usage, and logs), YAML-based edit of any resource, drain/uncordon for nodes, PVC and PV inspection, ingress management, service management (including endpoints), RBAC objects inspection, events feed, describe output, aggregate metrics dashboard (fed by the metrics-server if present in the cluster), and pod security. The Kubernetes handler surface (/api/kubernetes/) covers named endpoints for each of these; anything not covered by a named handler falls through to the raw Kubernetes API proxy at /api/endpoints/{id}/kubernetes/... with server-side RBAC applied.

On Docker environments, the equivalent operator surface: containers list (running, stopped, all), images list (pull, push, remove), volumes and networks, container inspection, streaming logs, exec into containers, and stats. On Swarm, add service management (create, update, remove, scale, rollback) and stack management. On both, the agent proxies the operator's Docker API commands with the operator's Portainer-side authorization applied first.

Manifest dry run

A useful safety feature worth calling out: the Kubernetes manifest dry-run endpoint validates one or more YAML manifests against the cluster with a 30-second bound, returning pass/fail per resource. Multi-document YAML is supported. A namespace parameter is applied to namespaced resources that do not declare one; a resource declaring a different namespace is rejected. This backs the "validate before deploy" flow in the UI, and it is worth knowing about when a customer asks whether they can preflight a config. Dry run tests admission at that moment, so a passing dry run does not guarantee a passing deploy (webhook flakiness, quota consumption, race conditions), but it catches most bad manifests early.

Module 2 listed what Portainer does not solve. This chapter names the integrations that fill those gaps, so you never get caught saying "Portainer does that" when it does not.

Secrets management. Portainer does not host secrets. Standard integrations: HashiCorp Vault (and OpenBao), External Secrets Operator (which reconciles from many secret backends into Kubernetes Secret objects), Sealed Secrets (Bitnami's controller that decrypts SealedSecret CRs into Secrets at admission), and cloud-provider secret stores (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager). Portainer surfaces Kubernetes Secret objects in its day-2 UI; it does not create the sealing or encryption layer.

Deep observability. Portainer's embedded stack is enough for operational alerts, not for application observability, distributed tracing, or long-retention metrics. For those, integrate with the customer's existing platform: Datadog, Dynatrace, Splunk, or a Prometheus/Grafana/Loki stack. Portainer's OneUptime integration is the built-in option: the observability-k8s policy deploys the OneUptime kubernetes-agent as a Helm chart with a preset (standard, gke-autopilot, or eks-fargate) and an ingestion key (auto-provisioned by Portainer from OneUptime, or supplied). The environment-facing logs and metrics endpoints then query OneUptime and normalize the result.

Backup and DR for workloads. Portainer backs up its own datastore (Module 10). It does not back up the workloads it manages. Standard integrations: Velero (open source), Kasten K10 (Veeam), and CloudCasa (Catalogic). Deploy those into the customer's cluster; they handle Kubernetes-object-plus-PVC backup with cloud-provider snapshot integration.

Service mesh. If a customer needs mTLS between services or advanced traffic management, deploy Istio or Linkerd. Portainer will manage the mesh's Kubernetes objects the same way it manages any other workload, but it does not itself provide the mesh.

Runtime security anomaly detection. Portainer does not do syscall-level anomaly detection. Falco is the standard open-source answer; commercial alternatives include Sysdig Secure and Aqua. These sit in-cluster and detect at runtime; Portainer complements them by making the events visible and by governing policy through security-k8s.

Container registry. Portainer does not embed a registry. Harbor is the standard open-source answer; ECR, ACR, GAR, GitLab Container Registry, and JFrog Artifactory are the standard commercial ones. Portainer integrates with all of them through the registry governance chapter above.

The pattern is clear. Portainer is the operator control plane; the integrations are the specialist products it coordinates. Never sell Portainer as a replacement for these; sell it as the layer that lets a customer run a coherent operating model on top of the ones they already have.

Four of the twelve capabilities from Module 1 are covered in other modules. Short pointers so this reference is complete.

If a customer asks you where a capability is taught, this table is your answer.

Module 8 goes deep on GitOps and delivery. If Module 7 was reference, Module 8 is procedural: sources and workflows, poll versus webhook, change windows, edge stacks, and how Portainer's GitOps model differs from Argo CD and Flux. Do not skip it; even customers who already run Argo CD or Flux benefit from the sources model, and the divergence points come up in every enterprise conversation.