Skip to content

Security

This guide explains how to secure your Neo4j Enterprise clusters using the features provided by the operator.

Authentication

The operator provides first-class, typed configuration for external identity providers. You define providers via spec.auth and the operator generates the correct neo4j.conf entries automatically — no manual dbms.security.* keys required.

Supported providers (first-class typed configuration):

  • Native Neo4j authentication: The default, managed via Kubernetes secrets.
  • LDAP / Active Directory: Full typed support — host, DN templates, group-to-role mapping, system account credentials (injected securely via env vars, never in ConfigMap).
  • OIDC / SSO: Multiple named providers (e.g., Okta + Azure AD simultaneously) with discovery URI, claims mapping, and group-to-role mapping.

JWT: Neo4j has no separate jwt provider — sign-in with a JWT goes through an OIDC provider. Configure it under spec.auth.oidc and list it as oidc-<name> in spec.auth.authenticationProviders. A jwt entry in that list is not a Neo4j provider; the operator still accepts it for backward compatibility, with a warning.

Kerberos is not supported through operator-typed configuration today. Neo4j Kerberos uses the separate Kerberos Add-On — a plugin JAR plus its own kerberos.conf and krb5.conf files — and the operator does not assemble that bundle for you. See the Security Guide § Kerberos Authentication for current state.

If you'd like typed support for Kerberos, open an issue describing the use case.

Multi-provider support: Neo4j evaluates providers in order, so you can configure authenticationProviders: [ldap, native] to try LDAP first with native as fallback.

JVM TrustStore: For LDAPS or OIDC with internal CAs, use the top-level spec.trustedCASecrets field to add extra trust anchors to the operator-managed JKS truststore (seeded from the JDK cacerts). The deprecated spec.auth.trustStore field still works and is folded into the same path — prefer spec.trustedCASecrets for new deployments. See the Security Guide § JVM TrustStore for the full configuration.

For full configuration details and examples, see the Security Best Practices guide and the auth examples.

TLS

The operator makes it easy to enable TLS encryption for all communication to and from your Neo4j cluster. Enable TLS by setting spec.tls.mode: cert-manager and pointing spec.tls.issuerRef at a cert-manager Issuer or ClusterIssuer:

spec:
  tls:
    mode: cert-manager
    issuerRef:
      name: ca-cluster-issuer
      kind: ClusterIssuer
    # strictPeerValidation defaults to true (mutual TLS on cluster links).

The operator integrates with cert-manager to automatically provision and manage TLS certificates. This is the recommended approach for production environments. Intra-cluster mutual TLS is enabled by default via spec.tls.strictPeerValidation: true. See the dedicated TLS Configuration guide for the full configuration surface, including third-party issuers (AWS PCA, Vault) and the strictPeerValidation: false opt-out.

Cross-cluster replication

spec.crossClusterReplication publishes Neo4j's transaction-shipping port through a LoadBalancer Service so a replica in another Kubernetes cluster can stream from it. The proxy in front of that port is a TCP passthrough that authenticates nothing, so the cluster SSL policy is the only access control it has — which is why the operator requires spec.tls.mode: cert-manager and rejects the feature without it.

Keep strictPeerValidation and loadBalancerInternal at their defaults (true), treat spec.tls.additionalClusterTrustCAs as the access-control list it is, and alert on the cluster's CrossClusterProxySecure condition. Full guidance, including backup-mode credential handling, is in Cross-cluster replication § Security.

Network Policies

The operator can automatically create Kubernetes NetworkPolicy resources to restrict traffic to your Neo4j cluster. This helps to enforce a zero-trust security model by ensuring that only authorized applications can connect to the database.

RBAC

The operator itself runs with a specific ServiceAccount that is bound to a ClusterRole with the minimum necessary permissions to do its job. For end-users, the kustomize/OLM manifests (config/rbac/, the OperatorHub bundle) also ship a read-only <kind>-viewer-role and a read-write <kind>-editor-role ClusterRole for each custom resource (for example neo4jbackup-viewer-role, neo4jbackup-editor-role; the bundle prefixes them with neo4j-operator-) that administrators can bind to users or groups. The Helm chart does not install them.

Pod Security Defaults

The operator hardens all Neo4j data-plane pods (servers, standalone, backup jobs, restore jobs, and hook jobs) with strict security contexts by default:

  • runAsNonRoot: true with UID/GID 7474 (Neo4j user) and matching fsGroup.
  • allowPrivilegeEscalation: false, capabilities.drop: ["ALL"], seccompProfile: RuntimeDefault.
  • Root filesystem is writable to support Neo4j startup scripts and tmp usage.

These defaults are applied automatically. If you need to override them (e.g. for Pod Security Standards / OpenShift SCC compatibility), set:

  • spec.securityContext.podSecurityContext — full *corev1.PodSecurityContext override (replaces the operator's default)
  • spec.securityContext.containerSecurityContext — full *corev1.SecurityContext override on the Neo4j container

When either field is unset, the hardened default above is applied. If you add sidecars, align their security contexts with these defaults.