Release notes

v0.4.1

Release date: 2026-10-30

Signing in to the NeuVector web UI through Dex works in the high availability mode. The module images are rebuilt on updated base images.

Highlights

• Signing in to the NeuVector web UI through Dex works with highAvailability enabled.
• The module images are rebuilt on updated base images.

Fixes

• In the high availability mode, signing in to the NeuVector web UI through Dex could end with a return to the login page with the Session has expired. Please login. message: the manager keeps the sessions in memory and does not pass them between replicas. The module now runs a single manager replica in every mode, so with highAvailability enabled the web UI is no longer redundant.

Security updates

• The module images are rebuilt on the Deckhouse base images v3.1.21 with Go 1.27.3, which fix the vulnerabilities found in the previous base images.

v0.4.0

Release date: 2026-10-29

The module ships its own roles in both DKP role models, runs under the restricted pod policy and limits NvSecurityRule to the groups of its namespace. NeuVector is updated to 5.6.4 and the vulnerability scanner to 4.312; read the upgrade notes before updating.

Highlights

• The module ships roles for the NeuVector custom resources and the neuvector ModuleConfig in both role models of DKP.
• NvSecurityRule applies only to the groups of its own namespace, and writing it requires the namespace administrator role.
• The d8-neuvector namespace runs under the restricted pod policy, and each component gets only the permissions it uses.
• In the CSE edition the module is no longer enabled by default and is published at the Experimental stage.
• NeuVector is updated to 5.6.4 and the vulnerability scanner to 4.312.

Improvements

• The module ships its permissions in the role model of DKP 1.78: d8:system-capability:neuvector:{view,edit} for the cluster-wide policies and for reading the module configuration, d8:system-capability:neuvector:manage_config for writing the module configuration, and d8:namespace-capability:neuvector:{view,edit} for NvSecurityRule. On a cluster below 1.78 the module ships the equivalent d8:manage:permission:module:neuvector:* and d8:use:capability:module:neuvector:* objects instead.
• NvAdmissionControlSecurityRule, NvClusterSecurityRule, NvComplianceProfile, NvDlpSecurityRule, NvResponseRuleSecurityRule, NvVulnerabilityProfile and NvWafSecurityRule are managed by the holder of the security subsystem manager role. NvSecurityRule is managed by the administrator of the namespace it lives in and is read by the security subsystem viewer in every namespace. NvGroupDefinition is read by the security subsystem viewer and changed only by the cluster administrator: the NeuVector controller accepts it only in d8-neuvector, where namespace roles grant nothing.
• The same access is granted in the deprecated ClusterAuthorizationRule model, by the d8:user-authz:neuvector:user, d8:user-authz:neuvector:admin, d8:user-authz:neuvector:cluster-editor and d8:user-authz:neuvector:cluster-admin roles. In that model the module grants ClusterAdmin only the read of the neuvector ModuleConfig.

Fixes

• The vulnerability scanner no longer reports a vulnerability in a Wolfi or Chainguard image package whose version carries a release candidate suffix, such as 1.3.2.1_rc20260601-r0, when that version is newer than the fixed one. The suffix used to break the version comparison.
• With the controller data on a persistent volume, the controller no longer loses the default password profile when it restarts within seconds of its first start. Without the profile it could not create any local user, including the users of its initial configuration, and a login with such a user was rejected with 401.
• A workload scan finds a Python package that carries only .dist-info/METADATA without WHEEL, as packages installed by an operating system package manager often do. Previously only an image scan found such a package, and the vulnerabilities of the running container went unreported.
• With the controller data on a persistent volume, a configuration change no longer disappears after a controller restart that follows it closely, and a restart soon after the first start no longer loses the default settings. The controller could skip writing a change to the volume when another operation held the configuration lock or when it was stopped before the write, and it marked the backup as complete before writing the data.
• The controller.nodeSelector and controller.tolerations parameters now apply to the controller pods. Before, the controller ignored them and was scheduled by the settings of the whole module.
• Disabling the module now removes the validating webhook configurations neuvector-validating-admission-webhook and neuvector-validating-crd-webhook. Before, they stayed in the cluster and pointed to a Service that no longer existed.
• After a controller restart, for example on a module update, images are scanned again within about two minutes. Before, the controller lost the scanner registration on every restart: no image was scanned for up to an hour, after which the scanner pod restarted.
• In a cluster with Cilium, network rules, quarantine and WAF and DLP blocking take effect. Before, the enforcer could not run iptables on its read-only root filesystem, so these rules silently did nothing.

Security updates

• Module images are rebuilt with updated Go dependencies to remediate CVE-2026-61801 in github.com/moby/sys/user, CVE-2026-116585, CVE-2026-116586 and CVE-2026-116587 in github.com/go-jose/go-jose/v4, CVE-2026-78659, CVE-2026-78660, CVE-2026-78661, CVE-2026-78663, CVE-2026-78669, CVE-2026-97032 and CVE-2026-97045 in golang.org/x/net and CVE-2026-56851 in golang.org/x/text.
• CspAdapterUsageRecord is granted read-only. It is the licensing record the SUSE CSP adapter reports for billing, not a security policy, so the right to write one stays with the cluster administrator.
• The module roles carry no rbac.deckhouse.io/namespace label, so they grant nothing inside d8-neuvector. That namespace holds the internal TLS material the controller, the enforcer and the scanner authenticate to each other with, and the registry credentials of the module.
• Each NeuVector component runs under its own service account, and only the controller has roles. Before, the controller, the enforcer, the scanner and the manager shared one account with the admin role in d8-neuvector and the view role across the cluster. The controller now gets only the calls it makes, the enforcer and the scanner keep a token only to read the Kubernetes version, and the manager, which talks only to the controller, gets no token at all.
• The d8-neuvector namespace runs under the restricted pod policy of admission-policy-engine with the checks of system namespaces enabled. The controller, the manager and the scanner drop all capabilities and keep only root, the se-bridge sidecar runs as a non-root user, and every remaining deviation, including the privileged enforcer in the host PID namespace and its host paths, is declared by a SecurityPolicyException of its component with the reason for each relaxation.
• The validating webhook configurations and the secrets neuvector-bootstrap-secret and neuvector-store-secret, which the NeuVector controller creates at run time, carry the heritage: deckhouse label, so the platform rejects changes to them by users as it does for the other objects of the module.
• The DLP and WAF sensors (NvDlpSecurityRule, NvWafSecurityRule) are registered with multitenancy-manager as cluster resources that NvSecurityRule references by name. An administrator can restrict which sensors the rules of a project may name with ClusterResourceGrantPolicy; without a policy every sensor, including the built-in ones, stays available.
• The controller changes only its own objects instead of every object of their kind: the secrets neuvector-bootstrap-secret and neuvector-store-secret in d8-neuvector, the webhook configurations neuvector-validating-admission-webhook and neuvector-validating-crd-webhook, and the NeuVector CRDs. The neuvector-binding-job-creation role is no longer shipped: the controller creates no jobs and changes no CronJob.
• Write access to the neuvector ModuleConfig is granted by a role separate from the security policies: on a cluster running 1.78 or later the superadmin level of the security subsystem includes it, on an earlier one the d8:manage:all:manager role does. The configuration is not a plain setting: auth.defaultRole (admin by default) and auth.groupRoleMapping assign the NeuVector role of every user of the NeuVector web UI, and the NeuVector admin role can capture the traffic of any pod in the cluster. The manager of the security subsystem reads the ModuleConfig and manages the NeuVector policies, but cannot change the configuration. In the ClusterAuthorizationRule model the module does not grant the write, see the known issues.
• A NvSecurityRule names only the groups of its own namespace: the target and every ingress and egress group must have the domain criterion of that namespace and a name ending with .<namespace>, a learned group must have the service criterion of its name, a group whose name has a NvGroupDefinition must have the criteria of that definition, and only external, nodes and Workload:ingress need neither, as peers. A NeuVector network rule joins two groups across the cluster, so without this check the namespace administrator, who writes NvSecurityRule starting with this release, could open the traffic of another namespace in spite of its Protect mode, or take the name of a group that a NvClusterSecurityRule refers to and make the controller delete that cluster policy at its next start.
• The se-bridge sidecar can read and update only its own leader election Lease neuvector-se-bridge instead of every Lease in d8-neuvector.

Breaking changes

• Writing NvSecurityRule requires the namespace administrator role (d8:namespace:admin, or the Admin access level of ClusterAuthorizationRule); the namespace manager and Editor only read it. The rule sets the protection mode of the groups of its namespace (target.policymode), and the NeuVector console cannot change the mode of a group a rule manages, so a rule can take the workloads out of Protect for good.
• The NeuVector controller deletes a NvSecurityRule that names a group of another namespace, a group without the domain criterion of its namespace (a group selected by addresses alone among them), a group whose name does not end with .<namespace>, a learned group nv.<service>.<namespace> without the service criterion, or a group whose criteria differ from those of the NvGroupDefinition of its name. kubectl apply reports such a rule as created: the controller deletes it within seconds, deletes an existing one when it starts, and records the reason in the NeuVector event Crd.Error. Traffic between namespaces is set by NvClusterSecurityRule. A policy exported from the NeuVector console puts the rules of a namespace group, including the rules with other namespaces, into a NvSecurityRule, so check an exported policy before applying it.
• In the CSE edition the module is no longer enabled by default in the Default and Managed bundles. A cluster that ran NeuVector only because of its bundle, without enabled: true in the neuvector ModuleConfig, disables the module after the update.
• In the CSE edition the module is published at the Experimental lifecycle stage, as in the other editions, instead of Stable. Deckhouse enables an experimental module only when allowExperimentalModules in the deckhouse ModuleConfig is true or, in the DKP versions that support it, when allowedExperimentalModules lists the module.

Upgrade notes

• Before upgrading the module, check every NvSecurityRule. Move the rules that name groups of other namespaces or groups without the domain criterion of the namespace into NvClusterSecurityRule. Rename every group whose name does not end with .<namespace>, add the service criterion of its name to every learned group nv.<service>.<namespace> that lacks it, and give every group that has a NvGroupDefinition of its name the criteria of that definition. Otherwise the controller deletes these objects at its first start after the upgrade, and their rules stop applying.
• Grant the role d8:namespace:admin (or the Admin access level) to whoever writes NvSecurityRule in a namespace. To review the protection modes set by namespace rules, use the d8:subsystem:security:viewer role: it reads NvSecurityRule in every namespace.
• Grant the superadmin level of the security subsystem (DKP 1.78 and later) to whoever changes the neuvector ModuleConfig; the module role of the ClusterAuthorizationRule model only reads it.
• Before upgrading the platform to DKP 1.78, grant the superadmin level of the security subsystem to those who change the neuvector ModuleConfig through d8:manage:all:manager. On 1.78 that role becomes an alias of d8:system:manager, which does not include the write of the module configuration, so after the upgrade they lose it.
• Before updating the module in a CSE cluster that uses NeuVector, set enabled: true in the neuvector ModuleConfig and allow the module in the deckhouse ModuleConfig: set allowExperimentalModules to true or add neuvector to allowedExperimentalModules.

Known issues

• In the ClusterAuthorizationRule model the ClusterAdmin level still writes the neuvector ModuleConfig: the platform role d8:user-authz:deckhouse:cluster-admin of the deckhouse module grants it writes on every ModuleConfig. The security subsystem manager can assign ClusterAdmin, and the configuration assigns the NeuVector roles of the web UI users, up to admin, which captures the traffic of any pod. Assign ClusterAdmin only to those who may change the module configuration.

Dependencies

• NeuVector: 5.6.2 → 5.6.4 (changelog)

  • Webhook notifications support authentication. The console reports a login whose server user maps to no role and shows a newly added registry without a page refresh. The enforcer no longer deadlocks in fanotify, and process rules apply reliably. Admission control allows dry-run requests to the custom resources instead of denying them. The controller watches ConfigMaps only in the d8-neuvector namespace instead of the whole cluster. In a cluster with many ConfigMaps this removes the excess load on kube-apiserver and the network traffic it caused. A scan detects the PHP interpreter version in images built on the official php images.

• Consul: 2.0.4 → 2.1.0 (changelog)

  • No user-visible change. The breaking changes of Consul 2.1 cover the service mesh, transparent proxy and Enterprise features. The module runs Consul as the internal store of the controller and uses none of them.

• NeuVector Scanner: 4.292 → 4.312 (changelog)

  • Fixes the version comparison of Wolfi packages with a release candidate suffix. An image scan detects the PHP interpreter version, as the controller and the enforcer of NeuVector 5.6.4 do.

• Open Policy Agent: 1.20.2 → 1.21.4 (changelog)

  • No user-visible change. The fixed bundle signature check and the YAML 1.2 parsing do not apply: the controller sends admission control policies to Open Policy Agent as JSON and uses no bundles.

• NeuVector Vulnerability DB Generator: fb6583c → 57eaea9 (changelog)

  • The vulnerability database applies the advisories of the PHP interpreter (php-src) to the PHP version that a scan detects.

v0.3.1

Release date: 2026-09-25

The web console image no longer carries known vulnerabilities, and the vulnerability scanner is updated to 4.290.

Highlights

• Known vulnerabilities are removed from the web console image.
• The vulnerability scanner is updated to 4.290.

Security updates

• The web console image no longer carries four known vulnerabilities of pip and of the libraries bundled with it, two of them of high severity. The image does not need pip at runtime, so pip is removed from it.

Dependencies

• NeuVector Scanner: 4.280 → 4.290 (changelog)

  • Images stored on the nodes are scanned with the same parsing options as images in a registry.

v0.3.0

Release date: 2026-09-23

Admission control starts working: the controller could not issue the certificates of its webhooks, so no rule ever took effect. NeuVector is updated to 5.6.2, the vulnerability scanner to 4.280, Open Policy Agent to 1.20.2 and Consul to 2.0.4.

Highlights

• Admission control rules take effect.
• Response rules are declared as the NvResponseRuleSecurityRule cluster resource.
• Publication of the web console and of the controller API can be turned off.
• Vulnerabilities are reported with a critical severity level of their own.

New features

• NvResponseRuleSecurityRule declares response rules in the cluster: which event to react to, under which conditions, and what to do — quarantine the workload, suppress the log or call a webhook. The same rules can be attached to the workloads of a policy through the response section of NvSecurityRule and NvClusterSecurityRule.
• ingress.enabled turns publication of the web console and of the controller API off, and gatewayAPI.enabled turns off publication of the web console through the Gateway API. Without these parameters the module follows the global settings of the same name.
• The vulnerability list can be filtered by the base operating system of the image.
• The SAML configuration accepts an Audience URI.

Improvements

• The image scanner detects images based on Wolfi and Chainguard. A registry entry whose operating system it does not support is marked OS Unsupported.
• Vulnerabilities carry a critical severity level of their own, counted and filtered apart from high. The console shows them in the color it has always used for the most severe findings.
• The admission rule editor names the criteria that count critical vulnerabilities, and the system settings name the group mode contention resolution.
• The Russian interface covers the strings the new NeuVector release introduces.

Fixes

• Admission control had no effect: rules could be edited in the web console, but nothing was ever rejected. The controller could not issue the certificates of its webhooks, so the webhook configurations were not created and the API server had nothing to call.
• Inspection by the DLP and WAF sensors could stop with nothing to show for it. A single failed read of the rule store left the enforcer on the rules it had applied last, and it stayed there until somebody edited a policy.

Security updates

• The module images no longer carry the known vulnerabilities that the signature verifier, Open Policy Agent and the module hooks brought in: eleven in total, four of them of high severity.

Upgrade notes

• Review the admission rules in the web console before the update. Admission control becomes functional for the first time, so a rule enabled there starts being evaluated, and a rule set to deny starts rejecting workloads that used to pass.
• Run the update in a maintenance window. It restarts the controller, the enforcer, the scanner and the web console, and NeuVector moves forward by two minor releases at once.
• Review the reports and the filters that select by severity: a part of what used to be counted as high is now counted as critical.

Known issues

• A group switched to the Protect policy mode stops being inspected by the DLP and WAF sensors instead of enforcing them: nothing is reported and the requests they are meant to block go through. Keep such groups in Monitor, which restores the inspection within half a minute. Admission control is a separate mechanism and is not affected.

Dependencies

• NeuVector: 5.4.10 → 5.6.2 (changelog)

  • Adds the response rule resource, the base operating system filter and the SAML Audience URI.

• NeuVector Scanner: 3.999 → 4.280 (changelog)

  • Adds detection of Wolfi and Chainguard images.

• Open Policy Agent: 1.18.2 → 1.20.2 (changelog)

  • No user-visible change: the module uses Open Policy Agent to evaluate admission control policies.

• Consul: 1.22.7 → 2.0.4 (changelog)

  • The breaking changes of Consul 2.0 cover the service mesh and the access control lists. The module runs Consul as the internal store of the controller and uses neither, so the major version change has no user-visible impact.

v0.2.4

Release date: 2026-09-10

Component resource requests become configurable, the image scanner starts in clusters with an authenticated registry, and ModuleConfig accepts the web console access list, the HTTPS mode and the high availability switch.

Highlights

• Resource requests and limits of every component can be tuned or fixed to static values.
• Vulnerability scanning of images works in clusters with a private registry.
• Access to the web console can be restricted to a list of CIDRs, and the HTTPS mode and the high availability mode can be set for the module.

New features

• Resource requests and limits are set through controller.resourcesManagement, manager.resourcesManagement, scanner.resourcesManagement and enforcer.resourcesManagement. The VPA mode sets the bounds VPA picks requests within, the limit-to-request ratio and the way a recommendation is applied: Initial, InPlaceOrRecreate or Auto. The Static mode fixes requests and limits and turns the picking off, which suits a component whose restart is unwanted.
• The defaults match the values the module used before, so requests and limits of the components do not change after the update.

Fixes

• The image scanner pod stayed in ImagePullBackOff when the image registry requires authentication, and images were left unscanned. The scanner now pulls its image with the same registry secret as the other components of the module.
• A ModuleConfig that set auth.whitelistSourceRanges, https or highAvailability was rejected on apply, so none of the three could be used. All three are now accepted and documented.

Docs

• The configuration documentation describes signing in to the web console from Deckhouse console. Dex passes NeuVector only those user groups that the client which performed the login allows, so a group missing from console.auth.allowedUserGroups never reaches the auth.groupRoleMapping mapping, and the role of the same user may differ depending on the sign-in path.

v0.2.3

Release date: 2026-08-27

Security fixes for component images: containerd and websocket upgrades, pip upgrade on the manager image, and OpenVEX attestations for remaining not-fixable findings.

Highlights

• Component images remediate fixable CVEs in-tree and publish OpenVEX attestations for findings that cannot be fixed by a dependency bump.

Security updates

• Bumped github.com/containerd/containerd/v2 to v2.2.6 in the common NeuVector tree (CVE-2026-46680), keeping the cri-api replace.
• Bumped gorilla/websocket to v1.5.3.
• Upgraded system pip to 26.1.2 on the manager final image (CVE-2026-3219, CVE-2026-6357, CVE-2026-8643, CVE-2026-1703).
• Added OpenVEX statements for GO-2026-5932 on controller, enforcer, scanner and bundle hooks, and for docker daemon CVEs on the scanner where only the client library is linked.

v0.2.2

Release date: 2026-08-24

Security fixes for component images (CVE remediation).

Highlights

• Component images include dependency and base-image updates that address known CVEs.

Security updates

• CVE-oriented security fixes included in the component images.

v0.2.1

Release date: 2026-08-14

Raised the minimum required Deckhouse version for the module.

Highlights

• The module now requires Deckhouse 1.74 or later.

Upgrade notes

• Verify your Deckhouse cluster is on version 1.74 or later before upgrading the module.

v0.2.0

Release date: 2026-08-10

The NeuVector controller’s persistent volume now only requires ReadWriteOnce (RWO) storage instead of ReadWriteMany (RWX), matching how the controller has actually run since HA support was disabled.

Highlights

• The controller’s persistent volume (data PVC) now only needs ReadWriteOnce (RWO) storage support, not ReadWriteMany (RWX).

Breaking changes

• PersistentVolumeClaim access modes are immutable in Kubernetes. If the module already provisioned a data PVC with ReadWriteMany (i.e. controller.storageClass or a cluster default storage class is configured), it will not be updated automatically on upgrade. Delete the existing data PVC in d8-neuvector before or during the upgrade so it can be recreated with ReadWriteOnce; back up the controller’s configuration via the UI (Settings → Configuration) first, since its contents will be lost when the PVC is deleted.

v0.1.14

Release date: 2026-08-05

Gateway API support for the manager UI, WAF/DLP rule hits forwarded to the Deckhouse security-events-manager, module availability for SE+ and EE editions, and CVE fixes in component images.

Highlights

• The NeuVector manager UI can now be exposed through the Gateway API.
• WAF/DLP rule hits are forwarded into the Deckhouse security-events-manager.
• A custom CA certificate can be configured for the Dex integration.
• CVE-oriented security fixes are included in the component images.

New features

• Added Gateway API support for exposing the NeuVector manager UI (HTTPRoute and ListenerSet resources).
• WAF and DLP rule hits are now forwarded to the Deckhouse security-events-manager so they appear alongside other security events.
• Added a configuration value for a custom CA certificate used with the Dex authentication integration.

Improvements

• Custom certificate support extended to the gateway-based UI exposure.
• Raised the required Deckhouse version to 1.71 or later.

Security updates

• CVE-oriented security fixes included in the component images.

Upgrade notes

• This release requires Deckhouse 1.71 or later. Verify the cluster version before upgrading.
• If you expose the manager UI via the Gateway API, review the custom certificate configuration after upgrade.

v0.1.13

Release date: 2026-06-30

Platform-security integration release: CSE edition, Deckhouse security-event bridge, Russian compliance and WAF/DLP improvements, plus authentication and scanner fixes.

Highlights

• Added support for the CSE edition.
• Security events from Deckhouse (including Falco and Dex audit events) are now forwarded into NeuVector.
• Improved Russian compliance tagging (FSTEC-related tags) and WAF/DLP filters.
• Added a token-exchange API endpoint and refined OIDC authentication behavior.
• Hardened vulnerability database handling and fixed scanner coverage for RED OS and Astra Linux 1.8.

New features

• Support for the CSE edition.
• A security-event bridge routes Deckhouse security and Kubernetes audit events into NeuVector security-event views.
• POST /v1/token-exchange endpoint for token exchange flows with the Deckhouse authentication integration.
• Admission control coverage for Service resources.
• Russian compliance profile improvements so FSTEC-related tags are accepted in compliance filters.
• Automatic update and copy behavior for WAF/DLP groups and rules, with Russian filter improvements.

Improvements

• UI and internationalization: default language and translations, self-hosted Inter font, Moment locale, language links, and related UX fixes.
• Swagger and API documentation polish; unsuitable external links are now hidden in the UI.
• Richer Dex authentication and Falco Kubernetes audit event details in security events.
• Cleaner vulnerability database content and trimming of overly long descriptions.
• Improved reliability of vulnerability processing for large data sets.
• New module configuration values and documentation clarifications (including StorageClass description).

Fixes

• Fixed badge rendering and gray protection/compliance badge presentation in reports.
• Fixed the WAF/DLP upgrade path.
• Fixed BDU links and cache behavior in the vulnerability database path; added related module configuration flags.
• Fixed enforcer operation with iptables rules.
• Removed an overly broad network policy that could over-permit traffic.

Security updates

• OIDC role mapping is now handled through the module API. The built-in default admin account has been dropped in favor of the Deckhouse/OIDC authentication path — review your authentication configuration after upgrade (see upgrade notes).
• CVE-oriented security fixes included in the CSE support.

Breaking changes

• The built-in default admin account has been removed in favor of the Deckhouse/OIDC authentication path. If you relied on the built-in admin user, ensure operators can authenticate via the configured identity provider before upgrading.

Upgrade notes

• Before upgrading clusters that still use the built-in admin account, verify that OIDC/Dex (or another identity provider) login works for administrators.
• If you use WAF/DLP policies, confirm groups and rules after upgrade — the auto-update/copy logic may refresh local WAF/DLP content.
• For CSE deployments, use the CSE-capable release artifacts from this tag.

Docs

• Updated the module description and StorageClass-related configuration documentation.

v0.1.12

Release date: 2025-12-23

NeuVector is now available for the SE+ edition.

Highlights

• NeuVector is available for the SE+ (SE Plus) edition.

New features

• Enabled the module for the SE+ (SE Plus) edition, so SE+ clusters can receive NeuVector releases.

v0.1.11

Release date: 2025-11-14

Added support for scheduling NeuVector workloads on selected nodes using a node selector.

Highlights

• NeuVector components can now be placed on specific nodes via node selector configuration.

New features

• Added node-selector support for scheduling module workloads on chosen nodes.

v0.1.10

Release date: 2025-11-14

Fixed broken links in the module documentation and resolved a missing-file packaging issue in a container image.

Highlights

• Restored broken documentation links so operators can follow references reliably.
• Fixed a missing file in a container image that could affect packaging or runtime.

Fixes

• Restored broken documentation links.
• Added a missing file to a container image that could break packaging or runtime expectations.