Helm / Advanced: compatibility, trust and delivery evidence / Lesson 15

API compatibility and least privilege

Review generated API inventory and security-relevant defaults while separating template intent from effective admission, authorization and runtime enforcement.

About 5 min readContent reviewed 2026-10-28

On this page

Lesson goals

Inventory API versions across current and recovery candidates.
Keep service-account and RBAC inputs explicit.
Assess security-context and policy assumptions without claiming enforcement.

Inventory APIs before platform upgrades

A chart may render supported APIs today while an older release revision contains an API removed by a planned platform upgrade. Recovery planning therefore includes current desired manifests and rollback candidates, not merely the newest source. Changing apiVersion can require field changes as well, so replacing a version string mechanically is insufficient. Preserve an explicit list of kind and apiVersion pairs and compare it with the target platform documentation. Do not edit stored release metadata using an improvised recipe. Such remediation affects history and ownership and belongs in a carefully authorized environment-specific process.

Review a small API inventory

The first example classifies synthetic API identities against a deliberately tiny allowed set. Its output flags an old Deployment API for review; it does not claim the set covers all Kubernetes versions or organizational policies. A real compatibility matrix must name the target Kubernetes release and distribution assumptions. Capabilities can help select branches, but a branch can still emit invalid fields for its chosen API. Test meaningful variants and examine receiving schemas. Treat compatibility as a maintained contract with dated evidence rather than a timeless claim attached to a chart badge.

python Synthetic API coverage check

allowed = {("apps/v1", "Deployment"), ("v1", "Service")}
rendered = [("apps/v1", "Deployment"), ("apps/v1beta1", "Deployment")]
for identity in rendered:
    print("covered" if identity in allowed else "review")

Expected output

covered
review

The set is a teaching fixture, not a complete support database. The program reads only public in-memory tuples.

Separate create and use decisions

A chart can create a ServiceAccount or use an existing one, but those are distinct ownership choices. Likewise, creating a RoleBinding is not the same as permission to create it, and a namespace does not by itself provide complete security isolation. Expose explicit values for account creation and name, then document required permissions. Avoid broad wildcard rules merely to avoid a sample error. If the application never calls the Kubernetes API, assess whether automatic token mounting is necessary. The second fragment is a Pod-spec security review excerpt with no workload, image or administrative command.

yaml Illustrative Pod-spec security assumptions

serviceAccountName: catalog-runtime
automountServiceAccountToken: false
securityContext:
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault

These fields need compatible images, runtime and admission policy. They are declarative intent, not verified hardening or a complete security policy.

Evaluate security-context compatibility

Security defaults should match application needs and the target policy. Running as non-root can fail when an image expects privileged paths; a read-only root filesystem can require writable temporary mounts. Explain such prerequisites instead of recommending privilege escalation as the first fix. Container-level settings and Pod-level settings have different scopes. A chart can expose controlled overrides, but those overrides should not silently undermine a promised policy. Rendering a NetworkPolicy also does not guarantee enforcement by the network implementation. Keep generated intent, supported environment features and observed security behavior as separate layers of evidence.

Keep security review concrete

Review the exact generated permission verbs, resource scopes, token exposure and workload settings for the synthetic application. A package may request more access through a dependency than through its own templates, so include subcharts and hooks. Name assumptions such as admission requirements and image user compatibility. This course performs no scans, cluster queries or administrative checks and grants no permissions. Its API classifier establishes a tiny local coverage result only. A useful handoff identifies unresolved environment questions and their owners, allowing a later authorized reviewer to assess them without mistaking illustrative settings for a verified secure installation.

Common errors and fixes

Only the newest chart is checked before a platform API removal

Why it happens: Recovery revisions and their stored API identities were ignored.
How to fix it: Review current and recovery candidates against the target platform compatibility matrix.
Prevent it next time: Include rollback viability in platform upgrade planning.

A wildcard role is added to silence an authorization failure

Why it happens: The required action and resource scope were not identified.
How to fix it: Determine the minimal documented application permission and separate installer from runtime needs.
Prevent it next time: Review exact rules for parent, dependencies and hooks.

runAsNonRoot is reported as complete hardening

Why it happens: One declared field replaced evidence of policy and runtime behavior.
How to fix it: State image, runtime and admission assumptions and assess the full workload contract.
Prevent it next time: Keep security claims proportional to the checks actually performed.

Check your understanding

1. The application never calls Kubernetes. What questions should surround token mounting?

Show worked solution

Ask whether any application component genuinely needs an API credential, whether a dependency or sidecar differs, and whether automatic mounting can be disabled under the target policy. Keep installer credentials separate from workload identity. Rendering false expresses intent only; verify effective behavior in an authorized environment rather than assuming the chart controls every admission mutation.

2. Why can replacing an old apiVersion string still leave an incompatible resource?