--- title: Vespa Cloud Security Whitepaper | Vespa.ai description: This document describes the Vespa Cloud service security features and operational procedures. image: https://content.vespa.ai/hubfs/RGP/vespa-security-reader/assets/og.jpg --- [Skip to the document](https://content.vespa.ai/vespa-cloud-security-whitepaper#s01) Vespa Cloud Security WhitepaperIntroductionConcepts and architectureControl plane API accessRoles and privilegesControl plane audit logsService isolationAccess control and service identityNode isolationHost isolationConfiguration isolationNetwork isolationThe isolation stackCommunicationEncryption at RestData classificationAsset typesLogsAccess managementThe security cadenceSecurity MeasuresColophon Contents Close ## Contents --- *Last updated: 2025-06-04* [01 Introduction](https://content.vespa.ai/vespa-cloud-security-whitepaper#s01) [02 Concepts and architecture](https://content.vespa.ai/vespa-cloud-security-whitepaper#s02) [03 Control plane API access](https://content.vespa.ai/vespa-cloud-security-whitepaper#s03) [04 Roles and privileges](https://content.vespa.ai/vespa-cloud-security-whitepaper#s04) [05 Control plane audit logs](https://content.vespa.ai/vespa-cloud-security-whitepaper#s05) [06 Service isolation](https://content.vespa.ai/vespa-cloud-security-whitepaper#s06) [07 The isolation stack](https://content.vespa.ai/vespa-cloud-security-whitepaper#s07) [08 Communication](https://content.vespa.ai/vespa-cloud-security-whitepaper#s08) [09 Encryption at Rest](https://content.vespa.ai/vespa-cloud-security-whitepaper#s09) [10 Data classification](https://content.vespa.ai/vespa-cloud-security-whitepaper#s10) [11 Logs](https://content.vespa.ai/vespa-cloud-security-whitepaper#s11) [12 The security cadence](https://content.vespa.ai/vespa-cloud-security-whitepaper#s12) [13 Security Measures](https://content.vespa.ai/vespa-cloud-security-whitepaper#s13) [14 Colophon](https://content.vespa.ai/vespa-cloud-security-whitepaper#s14) ![Vespa.ai](https://content.vespa.ai/hubfs/RGP/vespa-security-reader/img/VespaAI-logo-white-RGB.svg) --- # Vespa Cloud Security Whitepaper *Last updated: 2025-06-04* Vespa.ai7 minute read ## Introduction --- This document describes the Vespa Cloud service security features and operational procedures. **Vespa.ai has a SOC 2 attestation** - read more in the [Trust Center](https://trust.vespa.ai/). ## Concepts and architecture --- The Vespa Cloud consists of a *Control Plane* and a *Data Plane*. Each has its own web service APIs, respectively managing Vespa applications (Control), and interacting with a deployed Vespa application (Data). The Control Plane manages deployment of applications in the zones they specify, and lets tenant administrators manage their tenant information in Vespa Cloud. The Control Plane is shared among all tenants in Vespa Cloud and is globally synchronized. The Data Plane lets the tenants communicate with their deployed Vespa applications. It supports queries, feeding, and any other type of requests the tenant has configured and deployed in their application. The Data Plane is isolated for each tenant, application, and (optionally) service. The Vespa Cloud is divided into *Zones*. A zone is a combination of an *environment* and a *region* and has names like *prod.aws-us-east-1c*. Zones are stand-alone and do not have critical dependencies on services outside the zone. Tenants can implement service redundancy by specifying that applications be deployed in multiple zones. A Zone is managed by a *Configuration Server* cluster. These receive the application packages from the *Control Plane* on deployment and manage the local deployment process in the zone, including provisioning the node resources required to run the deployed application in the zone. Separately, it is responsible for maintaining those resources - replacing failed nodes, upgrading their OS and similar. Vespa applications run on *Nodes* - a Linux container executed on a *Host*. The *Host* is the actual machine running the containers. Each Host has a management process that receives instructions from the Configuration Server about what containers should run on the Host. Once started, the containers ask the Configuration Server cluster what Vespa services of what application they should run. It is the individual Node that contains the customer data such as indexes and documents, and which receives the queries and feeding requests from the customer's authenticated and authorized clients. Each Node is always dedicated to a single Vespa application cluster. Hosts are shared by default, but applications may specify that they require dedicated hosts to obtain an additional level of security isolation. Vespa Cloud overall architectureApplication package and Manage applications point to the Control Plane API. The Control Plane API points to the Configuration Servers in the first of three zones, and to the other two zones. The Configuration Servers point to a Host and to the Node on it. Vespa Documents and Vespa Queries point to the Data Plane, which points to the Node and to the other two zones.Control PlaneAPIData PlaneApplicationpackageManageapplicationsVespaDocumentsVespaQueriesZone: ...Zone: ...Zone: ...ConfigurationServersHostNodeVespa Cloud overall architectureApplication package and Manage applications point to the Control Plane API. The Control Plane API points to the Configuration Servers in the first of three zones, and to the other two zones. The Configuration Servers point to a Host and to the Node on it. Vespa Documents and Vespa Queries point to the Data Plane, which points to the Node and to the other two zones.Control Plane APIData PlaneApplicationpackageManageapplicationsVespaDocumentsVespaQueriesZone: ...Zone: ...Zone: ...ConfigurationServersHostNode Figure 1. Overall architecture: the Control Plane and the Data Plane, with the zones between them. Redrawn from the source's diagram. Service deployment ## Control plane authentication and authorization --- ### Control plane API access All API operations towards the Vespa Cloud control plane require authorization, and no tenant or application information will be presented for unauthorized access. A user can present a valid OAuth2 token which will be verified by the API. If an OAuth2 token is not available the user can choose to use an API key instead. The intended use for API keys is for service automation (e.g. CI/CD workflows or GitHub actions), but they can also be used by developers. ## Roles and privileges --- Members of tenants in Vespa Cloud can be assigned to three different roles that grant different privileges: - **Reader:** Can read tenant and application metadata. This is the minimal privilege which is implicitly granted to all members of a tenant. - **Developer:** Can create applications, deploy to dev and prod zones. These are the privileges needed by members working on applications. - **Administrator:** Can manage members of a tenant and tenant metadata, such as tenant contact information and billing actions. All role memberships are stored in an external identity provider. ## Control plane audit logs --- All operations against the control plane are persisted in an audit log capturing *timestamp*, *client*, *principal* (user), *HTTP method*, *resource* accessed, and *payload* (for certain requests). As this data can potentially be sensitive, it is available upon request from Vespa Cloud support. ## Service isolation --- Nodes belonging to the same application are allowed to communicate with each other while nodes of different applications are isolated on the network layer and through authorization. Communication between Vespa services is encrypted and authenticated using mutual TLS (mTLS). Identities and certificates are provided by infrastructure components that can validate the configuration. Service isolationVPC - Cfg holds three Config Servers. VPC - Tenant Hosts holds Host 1, with Node A of App A and Node B of App B, and Host 2, with Node C of App B. The Config Servers connect to Host 1 and to Node A. Node A to Node B is blocked. Node A to Node C is blocked. Node B to Node C is allowed, over Athenz mTLS. The key: App A in ink, App B in white, Infra in grey, allowed in mint, blocked struck through.VPC - CfgConfigServerConfigServerConfigServerVPC - Tenant HostsHost 1Node ANode BHost 2Node CAthenzmTLSLegendApp AApp BInfraallowedBlockedService isolationVPC - Cfg holds three Config Servers. VPC - Tenant Hosts holds Host 1, with Node A of App A and Node B of App B, and Host 2, with Node C of App B. The Config Servers connect to Host 1 and to Node A. Node A to Node B is blocked. Node A to Node C is blocked. Node B to Node C is allowed, over Athenz mTLS. The key: App A in ink, App B in white, Infra in grey, allowed in mint, blocked struck through.VPC - CfgConfigServerConfigServerConfigServerVPC - Tenant HostsHost 1Node ANode BHost 2Node CAthenzmTLSLegendApp AApp BInfraallowedBlocked Figure 2. Service isolation: two applications on two hosts, with the configuration servers in a VPC of their own. Redrawn from the source's diagram. ### Access control and service identity Each host and node has a unique cryptographic service identity. This identity is required in all inter-service communication, including HTTPS and internal binary RPC protocols. On the host, node, and configuration server level there are authorization rules in place to ensure that only relevant services can communicate with each other and retrieve resources from shared services, like the configuration server. ### Node isolation The identity of the node is based on the tenant, application, and instance the node is part of. The host and configuration server will together establish the identity of the node. The configuration server tells the host which nodes it should start, and the host requests a cryptographic identity for the nodes from the identity provider. This node identity is used for all internal communication inside the application. Nodes are implemented as Linux containers on the hosts. Each node runs in its own container user namespace, and each node has a dedicated IP address. ### Host isolation The lowest physical resource in the service architecture is a host. The configuration server is responsible for provisioning hosts and will keep track of known hosts, and reject any unknown hosts. Hosts only communicate directly with the configuration server and cannot communicate with each other. ### Configuration isolation Both nodes and hosts will consume application configuration from the configuration server. The configuration server will apply authorization rules based on the host and node identity. Authorization rules are based on least privilege. Hosts will only see which nodes to run, while the nodes are able to access the application configuration. ### Network isolation All communication between services is protected through mTLS. mTLS authorization is based on the identity mentioned above. In addition, network level isolation is used to prevent any unauthorized network access between services. The network rules are configured in the configuration server and applied by the host. Changes to the topology are reflected within minutes. ## The isolation stack --- 1. 01 Network isolation The network rules are configured in the configuration server and applied by the host. 2. 02 Host isolation Hosts only communicate directly with the configuration server and cannot communicate with each other. Hosts are shared by default, but applications may specify that they require dedicated hosts to obtain an additional level of security isolation. 3. 03 Node isolation Nodes are implemented as Linux containers on the hosts. Each node runs in its own container user namespace, and each node has a dedicated IP address. Each host and node has a unique cryptographic service identity. 4. 04 Encryption at Rest It is the individual Node that contains the customer data such as indexes and documents All customer data is encrypted at rest using the cloud provider's native encryption capabilities (AWS KMS or Google Cloud KMS). 5. 05 mTLS Communication between Vespa services is encrypted and authenticated using mutual TLS (mTLS). The isolation stack, outside inThree nested layers and what the innermost holds. Outermost, network isolation, whose rules are configured in the configuration server and applied by the host. Inside it, host isolation. Inside that, node isolation. In the node, the customer data it contains, indexes and documents, encrypted at rest. Below, inside the same network, a second node on a host of its own, and between the two nodes a link: mutual TLS, encrypted and authenticated, between nodes of the same application.Network isolationHost isolationNode isolationcustomer dataindexes and documentsencrypted at restHostNodemutual TLSencrypted andauthenticatedsame application Figure 3. The isolation stack, outside in: what contains a node, what the node holds, and how nodes of the same application talk. Each label is a phrase from the text. ## Communication --- ### Data plane All access to application endpoints is secured by mTLS and optionally token authentication. Upon deployment, every application is provided a certificate with SAN DNS names matching the endpoint names. This certificate will be automatically refreshed every 90 days. The application owner must provide a set of trusted Certificate Authorities which will be used by all clients when accessing the endpoints using mTLS. ### Federation It is possible for an application owner to federate calls to 3rd party services. Either as scheduled jobs, or per request. To support this use case we provide access to credential storage in the customer's AWS account. Data Storage ## Encryption at Rest --- All customer data is encrypted at rest using the cloud provider's native encryption capabilities (AWS KMS or Google Cloud KMS). Encryption is performed with the following properties: - **Cipher:** A strong, industry-standard cipher such as AES-256 (or the provider's default strong cipher) - **Key Management:** Customer-managed keys within the respective cloud provider's key management service (AWS KMS or Google Cloud KMS) Access to the keys is strictly controlled and audited through IAM roles and policies employing least privilege. Key rotation is managed automatically by the cloud provider on a regular basis. ## Data classification --- All data handled by Vespa Cloud is classified into two different classes which have different policies associated with them. - **Internal data:** Information intended for internal consumption in Vespa Cloud operations. This includes system level logs from services that do not handle customer data. Internal data is readable by authenticated and authorized members of the Vespa Cloud engineering team. - **Confidential data:** Confidential data is data that is sensitive to Vespa Cloud or Vespa Cloud customers. Access to confidential data is subject to stringent business need-to-know. Access to confidential data is regulated and only granted to Vespa Cloud team members in a peer-approved, time-limited, and audited manner. *All customer data is considered confidential.* Data classification mapTwo classes. Internal: Control Plane data, Infrastructure logs and Application package, readable by authenticated and authorized members of the Vespa Cloud engineering team. Confidential: Configuration Server data, Node logs, Core dumps and heap dumps, and Node data, under stringent business need-to-know, granted in a peer-approved, time-limited and audited manner. All customer data is considered confidential.InternalInternal data is readable by authenticatedand authorized members of the Vespa Cloudengineering teamControl Plane dataInfrastructure logsApplication packageConfidentialstringent business need-to-knowpeer-approved, time-limited, and auditedAll customer data is considered confidential.Configuration Server dataNode logsCore dumps / heap dumpsNode dataData classification mapTwo classes. Internal: Control Plane data, Infrastructure logs and Application package, readable by authenticated and authorized members of the Vespa Cloud engineering team. Confidential: Configuration Server data, Node logs, Core dumps and heap dumps, and Node data, under stringent business need-to-know, granted in a peer-approved, time-limited and audited manner. All customer data is considered confidential.InternalInternal data is readable byauthenticated and authorizedmembers of the Vespa Cloudengineering teamControl Plane dataInfrastructure logsApplication packageConfidentialstringent business need-to-knowpeer-approved, time-limited, andauditedAll customer data is consideredconfidential.Configuration Server dataNode logsCore dumps / heap dumpsNode data Figure 4. Data classification: the seven asset types in their two classes, with the access rule for each class. ### Asset types --- | Asset | Class | Description | | --- | --- | --- | | Control Plane data | Internal | The Control Plane maintains a database to facilitate orchestration of Vespa applications in multiple zones. This contains metadata about tenants and applications in Vespa Cloud. | | Configuration Server data | Confidential | The configuration server database contains the Vespa application model as well as the orchestration database. Since the configuration server is part of establishing node and host identities, the configuration server data is considered confidential. | | Infrastructure logs | Internal | Logs from infrastructure services like the configuration servers, the control plane services, etc. are considered internal. This includes logs from Control Plane, Configuration Servers, and Hosts. | | Application package | Internal | The application.zip file uploaded to Vespa Cloud by the customer is considered internal. The application package contains settings and configuration that Vespa Cloud operations needs insight into to operate the platform. | | Node logs | Confidential | The logs inside the Node may contain data printed by the customer. Because of this the logs are classified as confidential since Vespa Cloud cannot guarantee they are free of confidential data. This includes Data Plane access logs in addition to the node Vespa logs. | | Core dumps / heap dumps | Confidential | Occasionally core dumps and heap dumps are generated for running services. These files may contain customer data and are considered confidential. | | Node data | Confidential | All data on the node itself is considered confidential. This data includes the document data and the indexes of the application. | ## Logs --- All logs are stored on the nodes where they are generated, but also archived to a remote object storage. All logs are kept for a maximum of 30 days. Access to logs is based on the classifications described above. All logs are persisted in the same geographic region as the Vespa application that generated them. Archived logs are encrypted at rest with keys automatically rotated at regular intervals. Logs on the node are encrypted at rest with the same mechanism that encrypts indexes and document databases. ### Access management Access to confidential data is only granted on a case-by-case basis. Access is reviewed, time-limited, and audited. No Vespa Cloud team member is allowed to access any confidential data without review. ## The security cadence --- The security cadenceFour recurring events in order, from the most frequent to the least. Vespa is released up to 4 times a week. Operating system upgrades are rolled out every 90 days, and each application's certificate is automatically refreshed every 90 days. A hybrid security pentest program, conducted in partnership with Intigriti, runs yearly. Apart from the line, one retention limit: all logs are kept for a maximum of 30 days.Vespa is releasedup to 4 times a weekOperating system upgradesare rolled outevery 90 dayscertificate will beautomatically refreshedevery 90 dayshybrid security pentestprogram, conducted inpartnership with IntigritiyearlyAll logs are kept for a maximum of 30 daysThe security cadenceFour recurring events in order, from the most frequent to the least. Vespa is released up to 4 times a week. Operating system upgrades are rolled out every 90 days, and each application's certificate is automatically refreshed every 90 days. A hybrid security pentest program, conducted in partnership with Intigriti, runs yearly. Apart from the line, one retention limit: all logs are kept for a maximum of 30 days.Vespa is releasedup to 4 times a weekOperating system upgradesare rolled outevery 90 dayscertificate will beautomatically refreshedevery 90 dayshybrid security pentestprogram, conducted inpartnership with IntigritiyearlyAll logs are kept for amaximum of 30 days Figure 5. The security cadence: four recurring events, from the most frequent to the least, and one retention limit marked apart from them. The spacing is an order, not a scale. ## Security Measures --- Vespa Cloud employs a multi-layered approach to security, encompassing vulnerability management, secure development practices, and proactive testing. These include: 1. ### Security Testing Vespa Cloud proactively assesses its security posture through: - A vulnerability disclosure program, detailed at https://vespa.ai/responsible-disclosure/, enabling security researchers to responsibly report potential vulnerabilities. - A yearly hybrid security pentest program, conducted in partnership with Intigriti, to proactively identify and address vulnerabilities. 2. ### Secure Development Vespa Cloud follows a CI/CD process with mandatory code review for all commits. Static analysis tools are employed to detect issues in source code and third-party dependencies. In addition, the security team conducts regular internal security reviews of code and infrastructure to identify and address potential vulnerabilities throughout the development lifecycle. 3. ### Vulnerability Management Vespa is released up to 4 times a week, and we strive to keep all applications and dependencies updated to the latest versions. Operating system upgrades are rolled out every 90 days to address OS-level vulnerabilities. In case of a severe security issue, fixes are applied and rolled out as quickly as possible. 4. ### Incident Response Any unexpected production issue, including security incidents, is handled through our incident management process. Non-security incidents are announced through our console. Security incidents are communicated directly to affected customers. A post-mortem review process is initiated after every incident. In the event of a potential security breach, a forensic investigation is conducted. ## Colophon --- Vespa Cloud Security Whitepaper *Last updated: 2025-06-04* Text from docs.vespa.ai (last updated 2025-06-04), with spelling and grammar corrected and headings set for this edition. Source [https://docs.vespa.ai/en/security/whitepaper.html](https://docs.vespa.ai/en/security/whitepaper.html) PDF edition [Download the PDF](https://content.vespa.ai/hubfs/RGP/vespa-security-reader/vespa-cloud-security-whitepaper.pdf?hsLang=en) Vespa.ai 7 minute read ```json { "@context" : "https://schema.org", "@type" : "TechArticle", "articleSection" : [ "Introduction", "Concepts and architecture", "Control plane API access", "Roles and privileges", "Control plane audit logs", "Service isolation", "The isolation stack", "Communication", "Encryption at Rest", "Data classification", "Logs", "The security cadence", "Security Measures", "Colophon" ], "dateModified" : "2025-06-04", "description" : "This document describes the Vespa Cloud service security features and operational procedures.", "headline" : "Vespa Cloud Security Whitepaper", "inLanguage" : "en", "isBasedOn" : "https://docs.vespa.ai/en/security/whitepaper.html", "publisher" : { "@type" : "Organization", "name" : "Vespa.ai", "url" : "https://vespa.ai" }, "url" : "https://content.vespa.ai/vespa-cloud-security-whitepaper", "wordCount" : 1877 } ```