UA EN
Support

IT Consolidation: Isolating Organisations on a Shared Platform

By:

· Updated · 10 min

Multi-tenancy allows several organisations to share a platform, but it does not create isolation automatically. Data, application authorisation, network, resource, operational-recovery, and privileged-administration boundaries must be designed separately. The choice between dedicated and shared components is a trade-off among risk, manageability, performance, and cost, not a universal scale from “safer” to “less safe”.

Consolidation can reduce duplicated infrastructure and operational processes. It does not prove automatic licence savings: the commercial effect depends on the product's licensing metrics, contract, user count, cores, instances, or other terms.

Six isolation boundaries that cannot substitute for one another

  • Data: a separate instance, logical database, schema, tables, rows, files, and backups have different access and recovery boundaries.
  • Application authorisation: an authenticated identity must reliably establish tenant context for every request, background job, export, and report.
  • Workload and network: Namespace, RBAC, and NetworkPolicy govern different Kubernetes planes and do not replace data protection.
  • Resources: CPU, memory, I/O, connections, and concurrency require separate budgets and observability.
  • Operations: backup, restore, deletion, retention, audit, and incident response must preserve the tenant boundary.
  • Governance and commercial model: standards, legal requirements, contracts, and licences are a separate layer, not a property of RLS or Kubernetes.

Silo, bridge, and pool: what each model actually separates

For PostgreSQL, AWS distinguishes silo, bridge with separate logical databases, bridge with separate schemas, and pool with shared tables. A dedicated instance or cluster creates the strongest resource and failure boundary. A separate database in a shared instance remains a logical construct and shares CPU, I/O, and the failure domain with its neighbours. Schema-per-tenant separates the object namespace within a shared database. Pool uses a shared schema, a tenant key, and row-access policies.

Models can be combined: most tenants may use a pool, while a high-risk or resource-intensive tenant uses a separate shard, database, or deployment stamp. The decision should therefore be made for the specific workload and threat model.

Illustrative comparison of boundaries in multitenant storage
Model Data boundary What remains shared Operational consequences
Silo: instance or cluster per tenant Dedicated database resources and, where needed, a complete deployment stamp Depends on hosting: physical infrastructure, a control plane, or management services may still be shared A stronger resource and failure boundary, but more provisioning, patching, monitoring, and cost
Bridge: logical database or schema per tenant Separate database or schema objects within a shared instance Compute, I/O, instance lifecycle, and often the backup/PITR boundary Requires tenant mapping, automated migrations, and a validated export/restore procedure
Pool: shared schema with a tenant key and RLS Row-access policies and application-enforced tenant context Tables, schema rollout, compute, I/O, and much of the operating model Higher resource density, but a larger blast radius for a policy or tenant-context defect

RLS works only with trustworthy tenant context

Row-Level Security applies row-access policies according to context supplied to the DBMS or server-side data layer. A tenant ID must not be trusted merely because it arrived as a request parameter: bind it to the authenticated identity and propagate it to every downstream call.

In PostgreSQL, native RLS is enforced by the database engine. A table owner normally bypasses policies unless FORCE ROW LEVEL SECURITY is enabled, while a superuser and a role with BYPASSRLS always bypass them. If tenant context is stored in a session variable, a connection pool must set and clear it within a controlled transaction boundary; otherwise, context from one request can leak into the next.

Negative tests must cover not only the normal UI but also background jobs, import, export, search, reports, caches, administrative operations, migrations, and direct integrations. One uncovered access path breaks the entire logical boundary.

ISO/IEC 27017:2026 and privileged access

ISO/IEC 27017:2026 provides guidance for implementing security controls for cloud-service providers and customers. It applies to public, private, and hybrid cloud and helps define the allocation of responsibility. The standard does not prescribe a particular RLS, RBAC, or Kubernetes architecture: controls are selected through risk assessment and applicable legal, regulatory, and contractual requirements.

The standard also does not establish a universal requirement that a platform administrator can never access tenant data. Privileged access should be minimised, formally defined, and controlled through least privilege, separation of duties, MFA, approval, just-in-time or break-glass access, and complete action auditing. Audit records can be physically shared if they have tenant attribution, protection against unauthorised modification, suitable access control, and retention.

A Namespace scopes policies; it is not a complete security boundary

A Kubernetes Namespace creates a logical boundary for API resources and scopes RBAC, ResourceQuota, and NetworkPolicy. A Namespace by itself does not allocate CPU or memory, protect a shared database, or isolate the network.

Without NetworkPolicy, pods are non-isolated for ingress and egress by default. A policy works only when the network plugin supports and enforces it. A practical baseline is default-deny ingress and egress, explicit allow rules, separate service accounts, minimal RBAC permissions, secret protection, and verification of actual network reachability. Hostile tenants or a stronger compliance boundary may require dedicated nodes, virtual control planes, or separate clusters.

  • Namespace and RBAC: group API resources and restrict identity actions through the Kubernetes API.
  • NetworkPolicy: defines permitted pod ingress and egress when the CNI provides enforcement.
  • ResourceQuota and LimitRange: the former sets a namespace-wide budget; the latter supplies defaults and minimum or maximum constraints for individual objects.
  • Requests and limits: the former declares scheduling needs and the latter sets upper bounds for container resources, but neither eliminates every node-pressure scenario.

Noisy neighbours, backups, and the tenant lifecycle

ResourceQuota limits aggregate namespace consumption, while container requests and limits influence scheduling and enforcement. A memory limit reduces the risk of uncontrolled consumption by one workload but does not guarantee the absence of eviction or out-of-memory events on a node. At the data layer, use the controls available in the chosen stack: tenant-aware connection pools, concurrency and query limits, workload management, CPU and I/O controls, rate limiting, or placement of heavy tenants in separate shards or instances.

Isolation must also work during recovery. In PostgreSQL, pg_dump can select a specific schema, but the resulting dump is not necessarily self-contained because of external dependencies. Continuous archiving and PITR restore a database cluster, not one schema. Tenant-specific export, complete restore, point-in-time recovery, RPO/RTO, and return to production must therefore be tested as distinct procedures.

  • Observability: collect latency, errors, queueing, CPU, memory, I/O, connections, and cost attribution per tenant.
  • Deletion and retention: define cleanup of primary storage, replicas, object storage, search indexes, caches, logs, and backups according to policy.
  • Encryption keys: use a separate key per tenant only where the stack supports it and the threat model or contract justifies it.
  • Recovery: regularly verify backup integrity, tenant export/import, disaster recovery, and the absence of cross-tenant mixing.

Tagged storage, on-premises deployment, and UnityBase capabilities

The tagged storage approach described by AWS for a multi-tenant configuration service is a specific technical how-to, not a universal standard pattern. In that implementation, key prefixes route configurations between DynamoDB and Systems Manager Parameter Store. Restart-free updates come not from tagging alone but from event-driven refresh through EventBridge and Lambda, cache invalidation, and gRPC streaming.

In an on-premises environment, a configuration service can be built on Consul KV or another store. Authentication, tenant-scoped authorisation, secret encryption, versioning, audit, rollback, backup, and reliable change delivery must be designed separately. Consul KV is a basic key-value store, not a direct analogue of every Parameter Store capability. Ukrainian public-sector projects should not assume a blanket prohibition on public cloud: current rules provide for the procurement and use of cloud and data-centre services, while the concrete decision depends on information category, protection requirements, risk, continuity, provider, and contract.

UnityBase provides users, groups, roles, entity-level security, RLS, ACL/aclRls, attribute-level security, and an audit trail. Its general rls and aclRls entity mixins add server-side conditions to ORM operations. Separately, UnityBase EE documentation for PostgreSQL multitenancy describes native PostgreSQL RLS: tenant context is passed through ub.tenantID during the connection context, and the multitenancy instance should be configured to use a non-owner database role. The owner-based administration instance can see data for every tenant, so this privileged path requires separate control and auditing. These mechanisms can support logical tenant isolation for solutions such as Megapolis.DocNet and Scriptum.DMS, but the result depends on complete policies, every access path, database roles, privileged bypass, and negative tests. Licensing effects depend on the terms of the specific delivery.

Frequently Asked Questions

When should schema-per-tenant be chosen over a shared schema with RLS?

Schema-per-tenant can be appropriate when tenants need a separate object namespace, tenant-specific extensions, or easier logical exports. It does not guarantee an independent backup or point-in-time restore: cross-schema dependencies, backup granularity, and the recovery procedure must be validated for the specific DBMS.

How can the noisy-neighbour effect be reduced on a shared platform?

At the Kubernetes layer, combine ResourceQuota for a namespace-wide budget with container requests and limits and, where useful, LimitRange. At the data layer, use tenant-aware connection pools, concurrency and query limits, workload management, and per-tenant metrics. Heavy or critical workloads may need a separate shard or instance.

Why is a Kubernetes Namespace insufficient for tenant isolation?

A Namespace groups API resources and scopes RBAC, ResourceQuota, and NetworkPolicy, but it does not by itself block network traffic or protect a shared database. Use default-deny NetworkPolicy with an enforcing CNI, separate service accounts, workload controls, and RLS or another data-access boundary.

Sources

Tags: #Cloud Solutions #UnityBase #Public Sector #System Integration