Security Policy

1. Introduction

KubeOpera ("we," "our," or "us") provides a platform that connects to and operates on your Kubernetes infrastructure. We understand that this requires a high degree of trust, and security is a core consideration in how we design, build, and run our cloud-native infrastructure management platform and services (collectively, the "Services").

This Security Policy describes the technical and organizational measures we use to protect the Services and your data, how responsibilities are shared between KubeOpera and our customers, and how to report a security vulnerability to us. It should be read alongside our Privacy Policy and Terms of Service.

2. Infrastructure Security

The Services are hosted on major cloud providers and run on Kubernetes. We protect this infrastructure through:

• Network Segmentation: Production workloads run in private networks, with access to internal systems restricted to hardened, audited entry points
• Server-Side Service Access: Backend services are reachable only through our application's server-side layer, so internal service addresses and credentials are never exposed to the browser
• Outbound Request Controls: Server-side requests to internal services are restricted to an explicit allowlist of destinations to prevent server-side request forgery (SSRF)
• Hardened Workloads: Containers run with least-privilege service accounts and resource limits, and images are built from minimal, maintained base images
• Infrastructure as Code: Infrastructure and cluster configuration are version-controlled and deployed through reviewed, automated GitOps pipelines
• Environment Separation: Development, staging, and production environments are isolated from one another, and production customer data is not used in non-production environments

3. Data Protection

3.1 Encryption

• In Transit: All traffic between your browser, the Services, and connected clusters is encrypted using TLS 1.2 or higher
• At Rest: Databases, backups, and persistent volumes are encrypted at rest using AES-256
• Secrets: Credentials such as cluster kubeconfigs, API keys, and integration tokens are stored encrypted and are never returned to the browser in plain text

3.2 Tenant Isolation

KubeOpera is a multi-tenant platform. Each customer's data and workloads are logically isolated:

• Every request is authorized against the tenant identified in the user's authenticated session
• Tenant workloads can be placed in dedicated virtual clusters (vClusters) with their own control plane
• Namespace-level access is verified server-side before any resource is read or modified

3.3 Data Minimization

We collect only the cluster metadata, metrics, and events needed to deliver the Services. We do not read the contents of your Kubernetes Secrets or application data volumes as part of normal operation.

4. Identity and Access Control

4.1 Customer Access

• Authentication: Users sign in with a password or through supported OAuth / single sign-on (SSO) providers; sessions use signed, short-lived tokens
• Password Security: Passwords are hashed using a strong, salted, adaptive algorithm and are never stored in plain text
• Role-Based Access Control: Administrators can assign roles to limit what each user can view or change
• Audit Logging: Security-relevant actions, such as sign-ins and changes made to clusters, are logged

4.2 Employee Access

• Access to production systems is granted on a least-privilege, need-to-know basis and reviewed regularly
• Administrative access requires multi-factor authentication and goes through controlled, logged access paths
• Access is revoked promptly when an employee changes role or leaves the company
• Employees receive security and data-protection training and are bound by confidentiality obligations

5. Access to Your Clusters

When you connect a Kubernetes cluster to KubeOpera:

• We recommend granting KubeOpera a dedicated service account scoped to the minimum permissions required for the features you use
• Read-only monitoring features do not require write access to your cluster
• Actions that change your cluster, such as scaling or remediation, are initiated by an authorized user or by automation you have explicitly enabled
• You can revoke KubeOpera's access at any time by deleting its credentials or service account in your cluster

6. AI Features

KubeOpera includes AI-assisted features, such as the AI Chat assistant and AI agents for analysis, recommendations, and automated actions. For these features:

• Only the context needed to answer a request (for example, relevant resource names, metrics, and events) is sent to our AI model provider
• Requests to AI providers are made server-side over encrypted connections; provider credentials are never exposed to the browser
• Our AI providers are contractually prohibited from using your data to train their models
• AI-proposed changes to your infrastructure are subject to the same authorization checks as changes made by users

7. Secure Development

• Code Review: All changes to production code are peer-reviewed before being merged
• Automated Checks: CI/CD pipelines run static analysis, dependency scanning, and container image scanning
• Dependency Management: Third-party dependencies are monitored for known vulnerabilities and updated promptly
• Secrets Hygiene: Credentials are kept out of source code and managed through dedicated secret stores
• Security Testing: We conduct periodic security assessments and penetration tests of the Services

8. Monitoring and Incident Response

We continuously monitor the Services for availability, performance, and suspicious activity. We maintain a documented incident response process that covers:

• Detection, triage, and severity classification of security events
• Containment, remediation, and recovery
• Root-cause analysis and follow-up actions to prevent recurrence
• Notification of affected customers

If we confirm a security incident that affects your data, we will notify you without undue delay, and in any case within the timeframes required by applicable law, with information about the incident and the steps we are taking.

9. Availability and Business Continuity

• Critical services are deployed with redundancy to tolerate the failure of individual nodes
• Data is backed up regularly, and backups are encrypted and stored separately from primary systems
• Backup restoration and recovery procedures are tested periodically

10. Shared Responsibility

Security is a shared responsibility. KubeOpera is responsible for the security of the Services. You are responsible for:

• Keeping your account credentials confidential and enabling SSO or multi-factor authentication where available
• Managing which users in your organization have access to KubeOpera and what roles they hold
• Scoping the permissions you grant KubeOpera within your clusters
• Securing your own clusters, cloud accounts, workloads, and applications
• Reviewing and approving automated actions you enable

11. Reporting a Vulnerability

We welcome reports from security researchers and customers. If you believe you have found a security vulnerability in KubeOpera, please email security@kubeopera.io with:

• A description of the vulnerability and its potential impact
• Steps to reproduce it, including any relevant URLs, requests, or screenshots
• Your contact details, so we can follow up with you

11.1 Our Commitment

• We will acknowledge your report within 3 business days
• We will keep you informed as we investigate and fix the issue
• We will credit you for the discovery if you wish, once the issue is resolved
• We will not pursue legal action against researchers who act in good faith and follow these guidelines

11.2 Guidelines

When researching vulnerabilities, please:

• Only test against accounts and clusters that you own or are explicitly authorized to test
• Do not access, modify, or delete data belonging to other customers
• Do not perform denial-of-service attacks, spam, or social engineering of our staff or customers
• Give us reasonable time to resolve the issue before disclosing it publicly

12. Changes to This Security Policy

We may update this Security Policy as our Services and security practices evolve. The "Last Updated" date at the top indicates when the policy was last revised. Material changes will be communicated via email or through the Services.