Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 12 additions & 12 deletions docs/admin/hardening/kubernetes.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,27 +16,27 @@ meta:
This guide walks you through the best ways to secure a Kubernetes cluster running FlowFuse. Locking down your cluster shrinks your attack surface and keeps things contained if a single component gets compromised.
These tips work best when implemented together, so roll out as many of them as your environment allows.

{% note %}
::note
These are general hardening recommendations. Adapt them to your organisation's security policies and your cluster's specific configuration.
{% endnote %}
::

## Network Policies

By default, Kubernetes allows unrestricted network traffic between all pods, across all namespaces. Any pod can reach any other pod on any port. This flat network model means that a single compromised pod, for example a vulnerable instance, can be used to reach and attack every other workload in the cluster.

Network Policies let you enforce the principle of least privilege at the network layer: a pod should only be able to talk to the workloads it genuinely needs. Restricting traffic contains lateral movement, so a breach in one component cannot trivially spread to others.

{% warning %}
::warning
**Do not treat the policies below as a copy-and-paste solution.** They are illustrative examples, tied to the assumptions of the environment they were written for - namespace names, the ingress controller, the CNI, service ports, which components are deployed, and where operators live. Applied blindly they will either break platform traffic or leave gaps you believe are closed. Network Policies are one of the easiest things in Kubernetes to get subtly wrong: a rule that *looks* correct can silently drop traffic (wrong port direction, Service vs pod port, a missing return path) or silently allow it (an unenforced CNI, an overly broad selector). Implement them deliberately, with a working understanding of how traffic actually flows in your cluster - pod-to-pod, cross-namespace, ingress, egress, and DNS. Roll out one policy at a time, start in a non-production environment, verify each addition against real traffic (and check the affected pods' logs and Service endpoints), and confirm your CNI actually enforces policies before relying on them for security.
{% endwarning %}
::

### FlowFuse and Network Policies

FlowFuse runs the platform (namespace of your choice, selected during Helm chart installation) and the hosted Node-RED instances (configured with the `forge.projectNamespace` Helm chart value) in separate namespaces. If you enforce Network Policies, you must explicitly allow the traffic FlowFuse needs - otherwise the instances cannot reach the platform. See [I use Kubernetes Network Policies, how can I configure them?](../../install/kubernetes/#i-use-kubernetes-network-policies%2C-how-can-i-configure-them%3F) for the required policy.

{% note %}
::note
The following examples assume the default namespaces `flowfuse`, as a core application namespace, and `projects` for Hosted Instances namespace. If you have configured different namespaces, replace them accordingly.
{% endnote %}
::

The two namespaces have very different trust levels, so they are hardened differently:

Expand Down Expand Up @@ -116,9 +116,9 @@ spec:
kubernetes.io/metadata.name: flowfuse
```

{% note %}
::note
The Helm chart also ships a `flowforge-database-policy` that permits the core app → database connection when using the embedded database. The `allow-intra-namespace` rule above is a superset of it; keep both if you prefer defence in depth.
{% endnote %}
::

**5. Allow inbound from the EMQX operator** - The MQTT broker cluster is managed by the EMQX operator, which usually runs in its own namespace (`emqx-operator` by default) and polls the broker's management API (port `18083`) to set a pod *readiness gate*. If this is blocked, the check times out, the readiness gate never turns true, the broker pods are marked `NotReady`, their Service endpoints go empty, and every broker client fails to connect with a `503` error response. This rule is required for the operator to manage the broker cluster correctly:

Expand All @@ -144,9 +144,9 @@ spec:
port: 18083
```

{% note %}
::note
The same pattern applies to any other operator, admission webhook, or metrics controller that must reach pods in this namespace: allow ingress from its namespace, or its readiness/reconcile checks will silently break your Services. If a Service unexpectedly loses its endpoints after applying policies, check the managing controller's logs for connection timeouts.
{% endnote %}
::

### Hosted Instances namespace (`projects`)

Expand Down Expand Up @@ -337,9 +337,9 @@ Regular backups protect against data loss from accidental deletion, corruption,
- **External / managed database:** use your database provider's backup and point-in-time-recovery features
- **Embedded database:** if you use the Helm chart's internal PostgreSQL (`forge.localPostgresql: true`), you can schedule backups with a Kubernetes CronJob running `pg_dump`. A ready-to-use `CronJob` + `PersistentVolumeClaim` example is provided in the installation guide: [How to backup embedded database?](https://flowfuse.com/docs/install/kubernetes/#how-to-backup-embedded-database%3F)

{% warning %}
::warning
**Test your restores.** A backup is only useful if it can be restored. Periodically verify that you can restore from a backup into a clean database.
{% endwarning %}
::

## RBAC (Role-Based Access Control)

Expand Down
8 changes: 4 additions & 4 deletions docs/device-agent/quickstart.md
Original file line number Diff line number Diff line change
Expand Up @@ -52,13 +52,13 @@ powershell -Command "Start-Process 'powershell' -Verb RunAs"
Set-Location $env:USERPROFILE; powershell -c "irm https://flowfuse.github.io/device-agent/get.ps1 | iex"; .\flowfuse-device-agent-installer.exe
```

{% note %}
::note
The installer checks to see if port 1880 is available to use. If it isn't, it will let you know before exiting. This is typically because you already have Node-RED running locally. You can tell the installer to configure its Node-RED to use a different port using the `--port <port>` argument. Pick a different port, for example `1881` and re-run the above command with `--port 1881` added to the end.
{% endnote %}
::

{% note %}
::note
By default, the installer will use `/opt/flowfuse-device` (Linux/MacOS) or `c:\opt\flowfuse-device` (Windows) as the install location. To use a different location, use the `--dir` option with the install command. For example, `--dir /path/to/custom/location`.
{% endnote %}
::

## Step 2: Follow the installer prompts

Expand Down
4 changes: 2 additions & 2 deletions docs/install/docker/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -174,9 +174,9 @@ Proceed to the [next paragraph](#start-flowfuse-platform) to start the platform

If you have own TLS certificate, you can use it in FlowFuse platform installation as well. As mentioned before, the certificate must be a wildcard one for the domain you are using.

{% note %}
::note
If your TLS certificate is issued by a private Certificate Authority, additional configuration is required so that Hosted Instances trust the CA. See [What additional configuration is required when the TLS certificate is issued by a private Certificate Authority?](#what-additional-configuration-is-required-when-the-tls-certificate-is-issued-by-a-private-certificate-authority%3F) for the step-by-step instructions.
{% endnote %}
::

To configure FlowFuse platform with your certificate, you need to have:
* certificate key file
Expand Down
4 changes: 2 additions & 2 deletions docs/install/file-storage/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -86,9 +86,9 @@ On FlowFuse v2.6.0 or later, the File Storage service is used exclusively for Pe

Before FlowFuse v2.6.0, this service was also the primary way to provide persistent storage to Node-RED in container-based environments, in addition to Persistent Context.

{% note %}
::note
The File Storage service is only required in Docker or Kubernetes environments. If you are using the LocalFS platform driver, Node-RED already has direct access to the local filesystem.
{% endnote %}
::

### Configuring

Expand Down
11 changes: 2 additions & 9 deletions docs/install/introduction.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,10 +10,6 @@ meta:
- kubernetes
- trial license
- deployment models
templateEngineOverride: njk,md
installationServiceHubspot:
formId: "22edc659-d098-4767-aeb1-6480daae41ad"
targetId: "hs-form-installation-service"
---

# Installing FlowFuse
Expand Down Expand Up @@ -44,8 +40,5 @@ for any specific actions required.

If you need assistance, request our complimentary Installation Service, and we will help you install FlowFuse.

{% set formId = installationServiceHubspot.formId %}
{% set targetId = installationServiceHubspot.targetId %}
{% set cta = "cta-request-installation-service" %}
{% set reference = "docs-install-intro" %}
{% include "hubspot/hs-form.njk" %}
::HubSpotForm{formId="22edc659-d098-4767-aeb1-6480daae41ad" cta="cta-request-installation-service" reference="docs-install-intro"}
::
4 changes: 2 additions & 2 deletions docs/install/kubernetes/ingress-controller-migration.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,12 +14,12 @@ meta:

# Ingress Controller Migration

{% note %}
::note
This guide should not be treated as a one-size-fits-all solution. Consider it as a blueprint and adapt it to your specific Kubernetes cluster setup.
Test the migration in a testing/staging environment before applying it to production.

If you have any questions about the migration, please contact [support@flowfuse.com](mailto:support@flowfuse.com).
{% endnote %}
::

This document describes how to migrate a FlowFuse Platform Kubernetes deployment from the NGINX Ingress Controller to Traefik.

Expand Down
4 changes: 2 additions & 2 deletions docs/user/ff-tables.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,9 +4,9 @@ navTitle: FlowFuse Tables

# FlowFuse Tables

{% warning %}
::warning
This feature is currently in [the beta state](https://flowfuse.com/handbook/engineering/releases/#beta-release).
{% endwarning %}
::

From FlowFuse v2.20.0 Teams (Enterprise teams only) can create a relational database to use to store data.

Expand Down
Loading