Skip to content

docs: Plugins are directly reachable via internal vm-vm communication #287

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
danielvallance wants to merge 1 commit into
base: prod-staging
Choose a base branch
from
Open

docs: Plugins are directly reachable via internal vm-vm communication #287

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
9 changes: 9 additions & 0 deletions pages/features/plugins.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -156,6 +156,15 @@ Two consequences follow from `bearer` consulting no user account:
- Your platform token stops working on that plugin, so the plugin's token becomes the only way in.
- Changing the token takes the same [PATCH path](#adding-plugins-to-an-existing-instance) as adding a plugin, so it lands the next time the instance stops.

{/* vale off */}
:::warning
[Internal communication](/platform/networking#internal-communication) is always enabled on the hosted platform, and operators can enable it on BYOC or on-prem installations.
Where it's enabled, instances of the same user reach each other directly at the network level, which includes each other's plugin ports.
That path doesn't pass through the platform, so nothing checks a plugin authorization token on it: any instance can drive the plugin API of every other instance of the same user.
Treat one account as one trust domain where internal communication is enabled and plugins are running, such as on the hosted platform.
:::
{/* vale on */}

## Plugin names

A plugin name has a maximum length of 63 characters and contains only these characters:
Expand Down
9 changes: 9 additions & 0 deletions pages/platform/networking.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,6 +31,15 @@ For example, you wouldn't want to expose your database publicly, but you would w
Even when using internal communication, scale-to-zero triggers will still work as expected, and your instances will scale down to zero when not in use.
:::

{/* vale off */}
:::warning
Internal communication is always enabled on the hosted platform, and operators can enable it on BYOC or on-prem installations.
Where it's enabled, instances of the same user reach each other directly at the network level, which includes each other's [plugin](/features/plugins) ports.
That path doesn't pass through the platform, so nothing checks a [plugin authorization](/features/plugins#authorization) token on it: any instance can drive the plugin API of every other instance of the same user.
Treat one account as one trust domain where internal communication is enabled and plugins are running, such as on the hosted platform.
:::
{/* vale on */}

Every instance, by default, receives a private IP and a private FQDN (of the format `<instance-name>.internal`).
You can see the private IP of your instance by grabbing its details:

Expand Down
Loading