| Minimum Software Version | 8.17 |
| Solution(s) | All Solutions ✓ |
This FAQ explains what the upgrade changes and, importantly, what it does not. It confirms that data remains strictly segregated and protected, clarifies that the platform’s operating model is unchanged, outlines how downtime and rollback are managed, and summarizes the security and compliance controls in place - including updated authentication (ABAC + IRSA) that eliminates static credentials and strengthens tenant-level isolation.
Does this change affect data segregation or confidentiality between customers?
No. Customer data remains strictly segregated and protected. The upgrade does not weaken isolation.
Each customer continues to have:
- A dedicated database
- Dedicated S3 buckets
- IAM-enforced access boundaries
- Encryption and tenancy controls at both the data and application layers
The removal of customer-specific Kubernetes namespaces does not change how data is stored, accessed, or protected. Namespaces were never the security boundary; the security boundary is enforced by the platform, IAM, encryption, and data-layer controls.
Are you moving to a multi-tenant model, and does that increase risk?
We already operate a multi-tenant SaaS model, and this upgrade does not change that model.
The platform already uses shared clusters and shared services with strong logical separation. This is standard for modern SaaS platforms and is widely accepted by regulators, auditors, and cloud security frameworks.
The upgrade improves standardization and reliability but does not introduce new tenants, new data sharing, or new exposure. This consolidation also allows faster roll out of security patches.
What are the security implications of removing customer-specific namespaces?
Security posture is unchanged or improved, not weakened.
Key benefits include:
- Reduced configuration drift
- Fewer bespoke security policies per client
- More consistent patching and upgrades
- Improved monitoring and alerting coverage
Isolation continues to be enforced through IAM, network policies, encryption, and tenancy-aware service logic, which are materially stronger controls than namespace separation.
What is the operational risk of the upgrade (downtime, regressions, rollback)?
Risk is controlled, rehearsed, and reversible.
- Changes are rolled out incrementally per cluster
- Canary and health-check monitoring is in place
- There is a defined rollback path to the previous configuration if required
- No data migration is involved, which materially reduces risk
- The change is architectural and operational, not data-destructive
How does this affect compliance, audits, and contractual obligations?
It does not negatively affect compliance and, in many cases, simplifies it.
ISO 27001, SOC 2, and similar frameworks focus on data protection, access control, logging, change management, and incident response - none of which are weakened by this change.
A more standardized deployment model improves auditability and evidence collection. There is no change to data location, ownership, processing purpose, or access rights.
What authentication changes are being introduced?
The V8 platform now uses modern Attribute-Based Access Control (ABAC) policies in conjunction with IAM Roles for Service Accounts (IRSA) to manage per-tenant access to data storage services. This eliminates static secrets and long-lived credentials entirely.
Access is granted through temporary credentials that are short-lived, scoped to a single tenant, and fully auditable by our security systems. Critically, this also provides a secondary layer of tenant data isolation: AWS evaluates access policies before requests reach storage, so cross tenant access is denied at the infrastructure level regardless of application behavior.