Security Policy

At Kovra, security is foundational to how we build and operate the platform. This document describes the security measures we implement to protect your data, infrastructure, and deployments.

1. Infrastructure Security

Cloud Hosting

The Kovra platform runs on AWS Elastic Kubernetes Service (EKS) in the US East (N. Virginia) region. Our infrastructure leverages AWS security controls including VPC network isolation, security groups, and IAM role-based access with least-privilege policies.

Network Security

• All external traffic is encrypted via TLS 1.2+ with certificates managed through AWS Certificate Manager (ACM).
• TLS termination occurs at the AWS Application Load Balancer (ALB) with traffic forwarded to pods over the internal VPC network.
• Internal service-to-service communication runs within a private VPC subnet, isolated from public internet access.
• DNS is managed through AWS Route53 with DNSSEC support.

Container Security

• All microservices are deployed as containers on Kubernetes with resource limits and security contexts enforced.
• Container images are stored in private AWS ECR repositories and built using multi-stage Docker builds to minimize attack surface.
• Kubernetes network policies and pod security standards are applied across all namespaces.

2. Data Encryption

Encryption at Rest

• The database (AWS RDS PostgreSQL) uses AES-256 encryption at rest.
• Sensitive values — including cloud provider credentials, OAuth tokens, and application secrets — are encrypted at the application level using AES-256-GCM before storage.
• Encryption keys are versioned to support key rotation without re-encrypting existing data.

Encryption in Transit

• All API communication uses HTTPS/TLS 1.2+.
• Database connections use SSL/TLS.
• WebSocket connections for real-time updates are established over WSS (TLS-encrypted WebSocket).

3. Authentication and Access Control

User Authentication

• Passwords are hashed using bcrypt with appropriate cost factors.
• JWT-based authentication with short-lived access tokens and rotating refresh tokens.
• Password reset flows use time-limited, single-use tokens delivered via email.

Multi-Tenant Isolation

• Row-Level Security (RLS) policies at the PostgreSQL level ensure strict tenant data isolation.
• Every authenticated API request sets a PostgreSQL session variable identifying the tenant before any database query is executed.
• Organization roles (owner, admin, member, viewer) enforce permission boundaries across all API endpoints.

API Security

• All API endpoints require authentication except public health checks and webhook endpoints.
• Webhook endpoints (GitLab, Polar, VMAlert) verify signatures using HMAC-based authentication.
• CORS policies restrict cross-origin requests to approved domains.
• Rate limiting and request size limits protect against abuse.

4. Cloud Credential Security

When you connect AWS, GCP, or Azure accounts to Kovra:

• Credentials are encrypted immediately upon receipt using AES-256-GCM and stored in the encrypted database.
• Credentials are decrypted only at the moment of use and are never logged or cached in plaintext.
• We recommend creating dedicated service accounts or IAM roles with minimal required permissions for Kovra.
• Credential validation endpoints allow you to verify connectivity without exposing secrets.

5. Git Integration Security

• GitHub and GitLab integrations use OAuth 2.0 with scoped permissions — we only request the access needed for repository management and webhook delivery.
• OAuth tokens are encrypted at rest using the same AES-256-GCM encryption as cloud credentials.
• Webhook payloads from Git providers are verified against provider-specific signatures before processing.

6. BYOC (Bring Your Own Cloud) Security

For BYOC clusters, Kovra's agent-based connectivity model ensures:

• The cluster agent initiates the connection outbound from your network — no inbound firewall rules are required.
• Application workloads and data remain entirely within your cloud accounts.
• Kovra stores only orchestration metadata (deployment configurations, pipeline status) — not your application runtime data.
• Agent communication is authenticated and encrypted over WebSocket (WSS).

7. Monitoring and Incident Response

• Platform health is continuously monitored using VictoriaMetrics and Grafana dashboards.
• Automated alerts are configured for anomalous behavior, resource exhaustion, and service degradation.
• Structured logging (via zerolog) provides audit trails across all microservices.
• Incidents are investigated promptly, and affected users are notified of any security events that may impact their data.

8. CI/CD and Deployment Security

• All code changes go through pull request review before merging to the main branch.
• CI/CD pipelines run on GitHub Actions with OIDC federation for AWS authentication — no long-lived credentials in CI.
• Container images are built using Docker Buildx with layer caching and pushed to private ECR repositories.
• Deployments to production use ArgoCD GitOps workflows, ensuring that the running state always matches the declared state in Git.

9. Data Backup and Recovery

• Database backups are taken automatically by AWS RDS with point-in-time recovery support.
• Backups are encrypted and retained according to our backup policy.
• Infrastructure is defined as code (Terraform, Helm) and can be reconstructed from source in the event of a disaster.

10. Vulnerability Management

• Dependencies are regularly reviewed and updated to patch known vulnerabilities.
• We follow secure coding practices aligned with the OWASP Top 10.
• Input validation and parameterized queries protect against injection attacks.

11. Responsible Disclosure

If you discover a security vulnerability in the Kovra platform, we encourage responsible disclosure. Please report security issues to security@kovra.dev. We will acknowledge receipt within 48 hours and work to resolve confirmed vulnerabilities promptly.

12. Contact

For security-related questions or concerns, contact us at security@kovra.dev.