Eduard Gert
314d88252d
* Name the account owner in the pending approval error
A user refused because their account is pending approval had no way to
learn who could approve them. The refusal now carries the account
owner's address, masked, so a caller can name someone to contact without
being handed the address itself.
Resolving the owner is best effort: a lookup failure, or an account
predating the stored email, falls back to the refusal as it was.
* Name only the caller's own owner in the pending approval error
The refusal is raised before ValidateAccountAccess has established that
the caller belongs to the account the request asked about, and the user
is loaded by ID alone. Resolving the owner of the requested account
therefore disclosed that owner's address to a pending user with no claim
to it, reachable through any handler that takes an account ID from the
caller — DELETE /api/accounts/{accountId} passes one straight through.
The owner who can approve a pending user is the owner of their own
account, so resolve that one. The requested account is never read.
* Mask short local parts whole in MaskedEmail
Keeping the first two characters and the last hides nothing until the
local part is four long: at three or fewer they are the whole of it, so
"abc@example.com" masked to "ab****c@example.com" and a pending user
could recover the owner's address in full from what is meant to conceal
it. Short local parts are now replaced entirely.
* Name the owner from GetCurrentUserInfo instead of the permission gate
The gate could only read the stored user row, which carries no address
when an external IdP owns the identities — the usual case — so it named
no one in practice. It also had no way to reach the IdP without being
handed the account manager, which meant restoring bootstrap wiring that
a refactor had dropped.
GetCurrentUserInfo already holds that account manager, so it answers for
a pending user itself and reuses GetOwnerInfo, the same lookup /msp uses
to resolve an owner's address. The gate returns to exactly what it was,
and with it goes the risk of naming the owner of an account the caller
only asked about.
MaskedEmail becomes MaskEmail: with a UserInfo in hand there is no stored
row to hang it off.
* [management] Cover the pending approval refusal in GetCurrentUserInfo
The branch that names the owner had no coverage at the manager level, so
neither the named refusal nor the fallback for an owner without a resolvable
address was pinned down.
* [management] Cover the failed owner lookup in the pending approval refusal
The generic fallback has two ways in: no address on the resolved owner, and no
owner to resolve at all. Only the first was pinned down.
* [management] Pin the owner lookup to the caller's own account
A mismatched account claim must not steer which owner the refusal names, and
a blocked user is still answered before the claim is validated. Both are load
bearing and neither was covered.
netbird Management Server
netbird management server will control and synchronize peers configuration within your Netbird account and network.
Command Options
The CLI accepts the command management with the following options:
start Netbird Management Server
Usage:
netbird-mgmt management [flags]
Flags:
--cert-file string Location of your SSL certificate. Can be used when you have an existing certificate and don't want a new certificate be generated automatically. If letsencrypt-domain is specified this property has no effect
--cert-key string Location of your SSL certificate private key. Can be used when you have an existing certificate and don't want a new certificate be generated automatically. If letsencrypt-domain is specified this property has no effect
--datadir string server data directory location
-h, --help help for management
--letsencrypt-domain string a domain to issue Let's Encrypt certificate for. Enables TLS using Let's Encrypt. Will fetch and renew certificate, and run the server with TLS
--port int server port to listen on (default 33073)
Global Flags:
--config string Netbird config file location to write new config to (default "/etc/netbird")
--log-file string sets Netbird log path. If console is specified the the log will be output to stdout (default "/var/log/netbird/management.log")
--log-level string (default "info")
Run Management service (Docker)
You can run service in 2 modes - with TLS or without (not recommended).
Run with TLS (Let's Encrypt).
By specifying the --letsencrypt-domain the daemon will handle SSL certificate request and configuration.
In the following example 33073 is the management service default port, and 443 will be used as port for Let's Encrypt challenge and HTTP API.
The server where you are running a container has to have a public IP (for Let's Encrypt certificate challenge).
Replace with your server's public domain (e.g. mydomain.com or subdomain sub.mydomain.com).
# create a volume
docker volume create netbird-mgmt
# run the docker container
docker run -d --name netbird-management \
-p 33073:33073 \
-p 443:443 \
-v netbird-mgmt:/var/lib/netbird \
-v ./config.json:/etc/netbird/config.json \
netbirdio/management:latest \
--letsencrypt-domain <YOUR-DOMAIN>
An example of config.json can be found here management.json
Trigger Let's encrypt certificate generation:
curl https://<YOUR-DOMAIN>
The certificate will be persisted in the datadir/letsencrypt/ folder (e.g. /var/lib/netbird/letsencrypt/) inside the container.
Make sure that the datadir is mapped to some folder on a host machine. In case you used the volume command, you can run the following to retrieve the Mountpoint:
docker volume inspect netbird-mgmt
[
{
"CreatedAt": "2021-07-25T20:45:28Z",
"Driver": "local",
"Labels": {},
"Mountpoint": "/var/lib/docker/volumes/mgmt/_data",
"Name": "netbird-mgmt",
"Options": {},
"Scope": "local"
}
]
Consequent restarts of the container will pick up previously generated certificate so there is no need to trigger certificate generation with the curl command on every restart.
Run without TLS.
# create a volume
docker volume create netbird-mgmt
# run the docker container
docker run -d --name netbird-management \
-p 33073:33073 \
-v netbird-mgmt:/var/lib/netbird \
-v ./config.json:/etc/netbird/config.json \
netbirdio/management:latest
Debug tag
We also publish a docker image with the debug tag which has the log-level set to default, plus it uses the gcr.io/distroless/base:debug image that can be used with docker exec in order to run some commands in the Management container.
shell $ docker run -d --name netbird-management-debug \
-p 33073:33073 \
-v netbird-mgmt:/var/lib/netbird \
-v ./config.json:/etc/netbird/config.json \
netbirdio/management:debug-latest
shell $ docker exec -ti netbird-management-debug /bin/sh
container-shell $
For development purposes:
Install golang gRpc tools:
#!/bin/bash
go install google.golang.org/protobuf/cmd/protoc-gen-go@v1.26
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@v1.1
Generate gRpc code:
#!/bin/bash
protoc -I proto/ proto/management.proto --go_out=. --go-grpc_out=.