1
Say who needs to reach what.
Choose the tags, protocol and port. Give the rule a name.
- Name
- dev-to-staging
- Source tags
- dev
- Destination tags
- staging
- Protocol
- TCP
- Ports
- 443
Access Control
Let the right people in.
Rest a little easier.
Give each device access to the services it needs. Keep the rest of your network to yourself.
SECURITY THROUGH SIMPLICITY
Real security starts with simplicity.
What you don't understand is easy to misconfigure. Make a rule you can read, then see exactly what it allows.
2
See the access you've defined.
Open Preview and follow the rule from source to destination.
SourceRuleDestination
devTCP 443
stagingDevices tagged dev can reach staging over HTTPS.
Preview maps your configuration, so you can spot broader access than you intended. It isn't a live traffic test.
Start with your own rules, then remove the initial Default ACL allow-all rule. Traffic with no matching allow rule is dropped.
Access Control
Separate staging from production
Give development devices HTTPS access to staging without opening production.
A developer's laptop can reach the staging app without receiving access to production. Describe that boundary with the tags your team already understands.
- Allow dev → staging on TCP 443.
- Apply the same rule to new devices carrying those tags.
ALLOW ONLY WHAT THIS DEVICE NEEDS
Source tag
devTCP · 443
Destination tag
stagingstaging · port 443 is reachable
No access to production from this rule
Example with Default ACL removed and no broader allow rules.
Access Control
Give CI one job
Allow runners to pull from your private registry on the port it uses.
A build runner needs your registry to pull an image. Give it that connection without also opening your databases or administrative services.
- Assign the ci tag when the runner enrolls.
- Limit registry access to the port it actually uses.
ALLOW ONLY WHAT THIS DEVICE NEEDS
Source tag
ciTCP · 5000
Destination tag
registryregistry · port 5000 is reachable
No access to database from this rule
Example with Default ACL removed and no broader allow rules.
Access Control
Make operations explicit
Allow devices tagged sre to reach production servers over SSH.
Make production access something you can explain at a glance: which devices, which servers, which service. The rule stays readable as machines come and go.
- Allow sre → prod on TCP 22 for SSH.
- Review the permitted paths together in Preview.
ALLOW ONLY WHAT THIS DEVICE NEEDS
Source tag
sreTCP · 22
Destination tag
prodprod · port 22 is reachable
No access to other ports from this rule
Example with Default ACL removed and no broader allow rules.
New organizations start with an allow-all rule. Replace it with your own when you're ready to restrict access.Follow the guide
FREQUENTLY ASKED QUESTIONS
Clear rules. Clear answers.
Is a new network locked down by default?
No. New organizations have a Default ACL rule that allows all traffic between nodes so the first connection works. Create your specific rules, then delete Default ACL. The underlying engine denies traffic that matches no allow rule.
Are rules ordered?
No. There are no rule priorities or explicit deny rules. A packet is allowed if any rule matches. An empty source or destination matches all nodes.
Does Preview test live traffic?
Preview is a graph of your configured rules, not a live packet simulator. The example above illustrates how a small rule set behaves.
A LITTLE MORE YOU CAN DO
TRY IT ON YOUR OWN NETWORK
Connect your first two machines.
Install Baseguard, join the same organization, and put it to work.