Docs

Docs

Security Model and Best Practices

Understand how Control Center secures Kubernetes access, secrets, and application management.

Control Center simplifies the management of Vaadin applications in Kubernetes environments. It is designed with security in mind and follows best practices to minimize risk when managing sensitive configuration and infrastructure.

This page outlines how Control Center interacts with Kubernetes resources, how access is scoped and isolated, and what considerations apply to deployed applications.

Kubernetes Permissions

Control Center requires permission to manage common Kubernetes resources such as deployments, services, secrets, config maps, and custom resources. These permissions are necessary to support application lifecycle operations and to provision supporting infrastructure like databases.

The full list of permissions granted to Control Center is defined in the RBAC template included in the Helm chart.

Operator and UI Access Scope

Control Center is split into two components:

  • Operator: a Kubernetes controller with cluster access

  • User Interface (UI): a Vaadin web application used for management and interaction

The operator has full access to the Kubernetes API within the installation namespace, including secrets and configuration data. This is required to support application deployment, configuration, and service provisioning.

However, the UI is intentionally limited to interacting with a single custom resource type: vaadin.com/apps. This separation prevents the UI from accessing sensitive Kubernetes resources directly and ensures that all operations are mediated and validated by the operator.

Access to the UI is authenticated and does not require users to have direct access to the Kubernetes cluster.

Application Isolation and Resource Access

Applications deployed by Control Center are isolated and only have access to the configuration resources explicitly created for them.

Specifically:

  • Each application can read its own config maps and secrets

  • Applications cannot access other applications’ resources or cluster-wide secrets

  • Resource names and labels are automatically generated to enforce this boundary

This isolation ensures that applications cannot accidentally—or intentionally—interfere with one another.

Control Center Starter and Management Endpoint

Applications that include the Control Center starter are enhanced with a management endpoint used by Control Center to collect runtime metadata, such as:

  • Vaadin version and features

  • Health and readiness signals

This metadata is exposed via a dedicated Spring Boot Actuator endpoint:

  • /actuator/vaadin – exposes Vaadin-specific metadata

This endpoint is only available inside the cluster and is not exposed externally. It runs on an internal management port that is not included in the public service configuration.

Standard health probes used by Kubernetes (/actuator/health/liveness and /actuator/health/readiness) are also exposed but only to the cluster, as required by Kubernetes itself.

Summary of Best Practices

  • Grant Kubernetes API access to users only if needed. In that case, access should be limited to the vaadin.com/apps custom resource.

  • Users who interact with Control Center exclusively through the UI do not require any access to the Kubernetes cluster.

  • Ensure that applications are deployed with the Control Center starter to enable management and monitoring via internal-only endpoints.

  • Rely on the default resource isolation behavior: each application can only access its own config maps and secrets.

  • Avoid sharing secrets or configuration outside the application’s own scope; Control Center manages isolation automatically.