Skip to main content
FalkorDB Enterprise 1.0 is the release you can audit end to end. Every workload the chart owns now runs under the restricted Pod Security Standard, the Admin Server’s permissions are scoped to the namespaces it actually manages, images and charts are signed, and the entire security posture is written down on a page that CI re-checks against the rendered chart on every change.
1.0 is currently in beta. Helm skips prerelease versions unless asked, so a default install will not pick it up. See Try it below.

​
Least privilege, by default

The Admin Server used to read Secrets and ConfigMaps cluster-wide. It no longer can. Access now lives in a ClusterRole that is only ever bound per namespace — into the release namespace by the chart, and into each database namespace as the server provisions it. In any namespace it has not been bound into, it has no access at all.

No cluster-wide Secret access

Permissions are bound per namespace, and reconciled on startup. Upgrading needs no manual step.

No wildcards

No role the chart owns uses a wildcard, and the grant that creates RoleBindings is restricted to a single named role.

Restricted Pod Security

Admin Server, Admin UI and both hook Jobs run as non-root with readOnlyRootFilesystem and all capabilities dropped.

Namespaces you choose

adminServer.managedNamespaces.pattern restricts which namespaces may hold databases, enforced server-side so it covers API clients too.
The session signing key no longer passes through Helm values either. The installer creates the Secret out of band and hands the chart only its name, so the key never appears in the process table, in the Helm release Secret, or in helm get values.

​
A verifiable supply chain

Container images and the Helm chart are signed with cosign, and images carry a CycloneDX bill of materials as an attestation. The mirroring scripts copy signatures alongside each image, so an air-gapped registry stays verifiable rather than losing provenance at the boundary. adminServer.image.digest and adminUi.image.digest pin images by content — the only reference a registry cannot silently repoint.

Supply chain reference

The verification commands, and how to make signature checking a real admission boundary.

​
Network isolation you can turn on

networkPolicy.enabled creates NetworkPolicies for the Admin Server and Admin UI. Both set policyTypes: [Ingress, Egress], so anything not named is denied. Dedicated values say where your ingress controller, monitoring stack and DNS live, and the address ranges cover the API server and your identity provider. It is off by default on purpose: a CNI that does not implement NetworkPolicy accepts the objects and silently enforces nothing, which is worse than not having them. You can also put HTTP Basic auth on /metrics with adminServer.metrics.basicAuth. Setting only half the credential pair fails the render rather than quietly leaving the endpoint open.

​
Claims you can check

1.0 ships a security reference describing the whole posture in one place: every RBAC grant and why it exists, which controls Kubernetes enforces rather than the product, and where the limits are. A CI job re-checks those claims against the rendered chart, so removing a control from the chart fails the build. Alongside it:

Pod security

The measured Pod Security Admission level for each namespace.

Network policy

What each policy allows, and what it denies.

Helm values reference

Every value the chart accepts, generated from values.yaml.

​
Releases you can plan around

Releases now run on channels. Stable is the default, beta is published as a prerelease version so a default install can never pick one up, and every release has notes, a compatibility matrix and — where it needs one — a migration guide.
  • install.sh --version VERSION installs or moves to an exact chart version.
  • install.sh --channel beta opts in to the latest beta.
  • The installed version and channel show on the Diagnostics page and in the support package, so a bundle identifies the build it came from.

Changelog

Every change in every published release.

Compatibility matrix

The subchart versions each release pins.

​
Smoother installs

Registry credentials have one home: global.imageCredentials. With create: true the chart owns the pull Secret, otherwise it uses one you already have. The Admin Server then replicates those Secrets into every namespace it provisions a database into, so no namespace has to be seeded by hand first. The chart also prints post-install notes naming the release and the pull Secret in use, and warns when the pull secrets configured for the addon omit it — the setting that would otherwise leave database pods pulling anonymously and failing much later.

​
Try it

Upgrading an existing installation? 0.3.x can go straight to 1.0 in one step.

Migrate from 0.3 to 1.0

The registry move, the narrowed permissions and the new secret handling.

Upgrade procedure

Prechecks, the upgrade itself, and how to roll back.