Security Overview
A buyer-facing summary of the security architecture, control model, and operational practices used by openCenter.
openCenter is positioned as an operations-first Kubernetes platform. The public security story should therefore focus on how the system is designed and run, not just on headline claims.
This page summarizes the control themes visible across the website today. Deeper evidence or customer-specific architecture material can be shared during a trust review.
Purpose
Explains how openCenter approaches identity, secrets, workload security, monitoring, and secure operations.
- Primary audience
- Security teams, architects, procurement, platform leads
- Security model
- GitOps-driven operations with layered controls across identity, policy, secrets, and observability
- Public website specifics
- Opt-out analytics and server-side contact-form delivery
- Escalation path
- Responsible disclosure process and direct customer channels during active engagements
Keycloak-backed identity patterns, RBAC, and group-based access controls are central to the platform narrative.
SOPS-encrypted secrets, TLS, and encryption-aware deployment patterns are part of the public product positioning.
Kyverno policies, Pod Security controls, logging, metrics, and audit-friendly GitOps workflows reinforce day-2 security operations.
openCenter emphasizes centralized identity, role-based access, and policy-aware authorization rather than ad hoc cluster administration. Public product materials reference Keycloak integration, OIDC-based access, and group-driven RBAC workflows.
Secrets handling
SOPS-encrypted secrets and declarative key-management workflows are used as the baseline narrative for secure GitOps delivery.
Cluster hardening
Product pages describe Pod Security Admission, Kyverno guardrails, and workload restrictions that reduce common runtime risk.
Transport security
TLS and identity-integrated access are part of the secure-by-default posture described across platform and blueprint content.
- GitOps reconciliation creates auditable, reviewable infrastructure changes rather than unmanaged drift.
- Monitoring, logging, and alerting are treated as security-relevant operational controls, not optional add-ons.
- Lifecycle management, upgrades, and policy changes are positioned as day-2 responsibilities that materially affect security outcomes.
The public site uses an opt-out analytics model and server-side form submission delivery. Optional analytics are enabled by default and stop when the visitor rejects analytics through the cookie controls.
The current website implementation references PostHog for analytics and Mailgun for contact-form routing. Those vendors are disclosed on the subprocessor page.