# Security Policy

This document outlines Apache Texera (Incubating)'s security model, deployment considerations, and procedures for
reporting security vulnerabilities.

## Table of Contents

- [Security Model Overview](#security-model-overview)
- [Resources in Texera](#resources-in-texera)
- [User Categories and Responsibilities](#user-categories-and-responsibilities)
- [UI User Roles and Privileges](#ui-user-roles-and-privileges)
- [Deployments and Computing Units](#deployments-and-computing-units)
- [What is NOT a Security Issue](#what-is-not-a-security-issue)
- [Reporting Security Vulnerabilities](#reporting-security-vulnerabilities)

## Security Model Overview

Texera's security architecture is built around:

1. **Authentication**: JWT-based token authentication with configurable expiration
2. **Authorization**: Role-based access control (RBAC) with four user roles
3. **Resource Access Control**: Fine-grained privileges for datasets, workflows, and computing units
4. **Deployment Isolation**: Separate security considerations for different deployment modes

## Resources in Texera

In Texera, a **resource** is any object within the system that can be created, accessed, modified, or shared by users
via the web application. Understanding resource types and how access to them is managed is critical to following
Texera’s security model.

### Resource Types

Texera supports the following resource types:

- **Datasets**: Input data imported or uploaded for workflow processing
- **Workflows**: Data analytics pipelines defined by users
- **Computing Units**: Execution environments for running workflows (e.g., Kubernates PODs)
- **Results**: Output from workflow executions, including but not limited to data, logs, metrics, and visualizations

### Resource Ownership and Access Control

Every resource is owned by a user. The owner controls the resource's visibility and can share it with other users by
granting access permissions:

- **READ**: View the resource and its contents
- **WRITE**: Modify, execute, delete, and share the resource
- **NONE**: No access to the resource

Resources can be shared with specific users or made public. Public resources are visible to all users. Resource owners
can modify access permissions at any time.

### Resource Visibility

- Users can only see resources for which they have at least READ access.
- Access changes (e.g., revoking WRITE or READ) take effect immediately for affected users.

## User Categories and Responsibilities

Texera's security model distinguishes between two categories of users with distinct responsibilities:

### Deployment Managers

They have the highest level of access and control. They install and configure Texera, and make decisions about
technologies, deployment modes, and permissions. They can potentially delete the entire installation and have access to
all credentials, including database passwords, JWT secrets, and API keys. Deployment managers have full access to:

- The underlying infrastructure (servers, Kubernetes clusters, cloud resources)
- Database administration (e.g., PostgreSQL)
- All configuration files, environment variables, and secrets
- Network and security settings
- Container orchestration and system logs

Deployment managers can also decide to keep audits, backups, and copies of information outside of Texera, which are not
covered by Texera's security model. They operate outside the Texera UI role system and may or may not have a UI user
account.

### UI Users

**Who They Are**: Individuals who interact with Texera through the web interface.

**Access Level**: UI users interact with Texera through the web interface and do not have direct access to:

- The underlying infrastructure (servers, Kubernetes cluster)
- Database administration
- System configuration files
- Network and firewall settings
- Container orchestration

**Important**: REGULAR and ADMIN users can execute arbitrary code through UDFs, which may access resources in the execution environment. Deployment managers are responsible for mitigating this risk. See [What is NOT a Security Issue](#what-is-not-a-security-issue) for details.

**Roles**: UI users are assigned one of four roles (INACTIVE, RESTRICTED, REGULAR, ADMIN) that control their permissions
within the Texera application.

**Security Scope**: UI users are responsible for:

- Protecting their login credentials
- Managing access to their resources, e.g., datasets and workflows
- Following organizational data security policies

## UI User Roles and Privileges

Texera implements four UI user roles with increasing levels of privilege. These roles control what users can do **within
the Texera web application** and do not grant infrastructure-level access.

### 1. INACTIVE

Users with this role cannot log in to the system or access any resources. This is the default role for new registrations
awaiting approval in controlled environments.

### 2. RESTRICTED

Users with this role cannot log in to the system or access any resources. Unlike INACTIVE users, RESTRICTED accounts
typically represent users who previously used Texera but are now inactive and no longer use it. Any resources they
created in the past remain in the system but are inaccessible to them. This role is used to preserve historical data
while preventing further access.

### 3. REGULAR

Users with this role can create and manage their own resources (datasets, workflows, computing units). They have full
READ and WRITE access to resources they own, and their access to other users' resources is determined by granted
permissions (see Resources section above).

They cannot:

- Access other users' private resources without granted permissions
- Manage user accounts or change user roles
- Access system configuration, logs, or global settings

This is the standard role for data scientists, analysts, and researchers.
**Note**: REGULAR users can execute arbitrary code within workflows, so this role should only be granted to trusted
individuals.

### 4. ADMIN

Users with this role are application administrators who manage users and resources through the web interface.

They have all REGULAR privileges, plus:

- Manage all UI user accounts (create, modify, and delete users)
- Change user roles
- View user login information.
- Configure application settings available in the web interface

They cannot:

- Access the underlying servers or Kubernetes cluster
- Modify JWT secrets or database passwords
- Configure HTTPS/TLS or network settings
- Access system-level logs or SSH into servers

**Note**: ADMIN is an application-level role, not an infrastructure administrator. For infrastructure management,
deployment manager access is required.

## Deployments and Computing Units
Texera can be deployed in several configurations, such as local development, single-node setups, or distributed Kubernetes 
clusters. For details on supported deployment options and their operational differences, see the deployment guides in
our [wiki](https://github.com/apache/texera/wiki/How-to-run-Texera-on-local-Kubernetes).

### Computing Unit Types

Texera executes workflows on **computing units**. UI users (REGULAR and ADMIN) can execute arbitrary code (e.g., through
UDFs written in Python, R, Java, Scala) within computing units as part of their workflows. See [What is NOT a Security Issue](#what-is-not-a-security-issue) for the security implications of UDF execution.

Deployment managers configure which types of computing units are available:

#### Local Computing Units

Local computing units run as processes on the same machine as the Texera services (single-node deployment).

**Security characteristics**:

- Suitable for development, testing, and small team use
- All computing units share the same host machine
- No infrastructure-level isolation between users' workflows
- Deployment managers control all computing resources

**Security considerations**:

- Users' workflow code executes on the host machine with limited isolation
- UDF code executes with access to resources in the host environment — see [What is NOT a Security Issue](#what-is-not-a-security-issue)
- Deployment managers must trust all REGULAR and ADMIN users
- Resource exhaustion by one user can affect all users

#### Kubernetes Computing Units

Kubernetes computing units run as separate PODs in a Kubernetes cluster. Each computing unit is dynamically created when
a user needs it.

**Security characteristics**:

- Suitable for production environments and multi-tenant deployments
- Each computing unit runs in an isolated Kubernetes pod
- UI users configure resource limits (CPU, memory, GPU) per pod
- Pods can be scheduled across multiple nodes for better resource distribution

**Security considerations**:

- Better isolation between users compared to local computing units
- Kubernetes provides namespace and pod-level isolation
- Resource limits prevent individual users from consuming excessive resources
- UDF code within a pod can still access resources available inside that pod's environment (e.g., environment variables, mounted secrets)
- Container security and image scanning should be implemented
- Deployment managers must secure the Kubernetes cluster infrastructure

### What is NOT Guaranteed

Texera's security model does NOT guarantee:

- Protection against malicious code in user workflows (users can execute arbitrary code)
- Isolation of application secrets from UDF code executing within the same process or pod
- Strong isolation between workflows in local computing units
- Complete isolation between workflows in Kubernetes computing units within the same namespace
- Protection against infrastructure-level compromises
- Protection against deployment manager misconfigurations
- DDoS protection (requires external infrastructure)
- Compliance with specific regulatory requirements without additional configuration

## What are NOT Security Issues

The following are **NOT considered security vulnerabilities** in Texera:

### User Code Execution

REGULAR and ADMIN users can execute arbitrary code (Python, R, Java, Scala) within computing units through UDFs. This is by design — custom code execution is a core feature of the platform.

UDF code may access resources available in the execution environment, including but not limited to:

- Texera's application configurations
- Environment variables of the host

### Resource Consumption

Users can create workflows that consume significant CPU, memory, or storage. Texera is designed for data-intensive
workloads. Deployment managers control this through computing unit resource limits, quotas, and monitoring.

### Information Disclosure within Authorized Access

Users with READ or WRITE access to a resource can view all its contents. Access control is at the resource level - once
access is granted, full visibility is expected. Resource owners should grant access only to trusted users.

### Public Resources

Resources marked as public are visible to all users. Public sharing is a deliberate collaboration feature. Users should
review resources before making them public and avoid including sensitive data or credentials.

### Issues Requiring Deployment Manager Access

Issues requiring physical access to servers, administrative access to infrastructure, database access, or access to
configuration files are out of scope. These access levels are considered trusted.

### Third-Party Dependencies

Theoretical vulnerabilities in dependencies that have not been exploited in Texera's usage are not in scope.
You are they are welcome to raise an issue or a PR.

## Reporting Security Vulnerabilities

The [Apache Software Foundation](https://apache.org/) takes a rigorous stance on eliminating security issues in its software projects. If you
find a security bug, with that in mind, please **DO NOT** file public issues (e.g., GitHub issues). Before reporting a
security issue, check the security model declared above. To report a new vulnerability you have discovered, please
follow the ASF security [vulnerability reporting process](https://apache.org/security/#reporting-a-vulnerability).
The Texera community follows the ASF
security [vulnerability handling process](https://apache.org/security/#vulnerability-handling), and will fix it as soon
as possible.

## Changes to This Policy

This security policy may be updated from time to time. Significant changes will be announced on the project mailing
lists and website.

---

**Last Updated**: April 2026

**Disclaimer**: This project is currently undergoing incubation at The Apache Software Foundation (ASF). Incubation is
required of all newly accepted projects until a further review indicates that the infrastructure, communications, and
decision-making process have stabilized in a manner consistent with other successful ASF projects. While incubation
status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project
has yet to be fully endorsed by the ASF.

