Synadia Protect

Rules reference

Complete field reference for custom rule files. For an introduction to rules and built-in rules, see Rules.

Rule file structure

FieldTypeRequiredDescription
namestringyesunique within the bundle
descriptionstringnohelp text for managing rules
factslistyesconnection-level filters; at least one with connection_kind
conditionslistyesper-message filters; at least rule_type
defaultactionyesaction when no rule body matches
traceboolnoenable per-rule tracer output (debug only, do not use in production)
ruleslistyesone or more rule bodies

Actions

Valid values for default, success, and fail:

ActionTerminalDescription
allownopermit the operation
denyyesreject the operation and close the connection
erroryessame as deny, recorded with error metrics
suspendnopark the connection — keep alive but drop the backend connection
lognolog the raw protocol to the auditor, continue evaluation

Terminal actions (deny, error) stop all further rule evaluation and return immediately. Non-terminal actions (allow, log, suspend) accumulate and evaluation continues.

Facts

Static properties of a connection, set once at connect time. The engine pre-filters the ruleset using facts — rules whose facts don't match are never evaluated for that connection.

KeyValuesDescription
connection_kindclient, leafrequired on every rule
remote_ipIP addressexact string match on source IP

remote_ip uses string equality only. For CIDR-based IP filtering, use matchCIDR(Meta.Address, "10.0.0.0/8") in a rule expression.

Entries use OR logic within the same key and AND across different keys.

Conditions

Conditions filter per protocol message and determine whether a rule applies.

Rule type (required)

KeyValuesDescription
rule_typeconnect, messagewhich protocol messages this rule handles

Direction

KeyValuesDescription
directionto_backend, from_backend, both, inherittraffic direction filter

inherit (or omitting direction) uses the port's default_rule_direction.

Connect conditions

Available for rule_type: connect and rule_type: message:

KeyTypeMatches against
usernamestringConnect.Username
passwordstringConnect.Password
tokenstringConnect.Token
nkeystringConnect.Nkey
jwtstringConnect.JWT
namestringConnect.Name (connection name)
langstringConnect.Lang
versionstringConnect.Version
protocolintConnect.Protocol version number (0 or 1)

Account conditions

Available for rule_type: message:

KeyTypeMatches against
accountstringAccountInfo.Account
is_system_accountboolAccountInfo.IsSystemAccount

Message conditions

Available for rule_type: message:

KeyTypeMatches against
subjectstringexact match on Message.Subject
subject_matchstringNATS wildcard match on Message.Subject
subject_not_matchstringnegative NATS wildcard match
reply_tostringexact match on Message.ReplyTo
has_headerstringtrue if header key exists
not_headerstringtrue if header key does not exist

Conditions use OR within the same key, AND across different keys.

Rule bodies

FieldTypeRequiredDescription
expressionstringyesExpr expression that evaluates to a boolean
successactionnoaction when expression returns true
failactionnoaction when expression returns false
messagestringnoshown in audit logs on deny/suspend

Both success and fail can be set on the same rule body.

Evaluation environment

Meta

FieldTypeExpr accessDescription
DirectionstringMeta.Directionto_backend or from_backend
DefaultDirectionstringMeta.DefaultDirectionport's default direction
HoststringMeta.Hostgateway hostname
AddressstringMeta.Addressclient network address
RemoteServerstringMeta.RemoteServerremote server name
RemoteHoststringMeta.RemoteHostremote host IP
TimestringMeta.TimeRFC3339 timestamp
ConnectionKindintMeta.ConnectionKind1=client, 2=leaf (rarely needed — facts already filter on connection_kind)
ProtoLenintMeta.ProtoLenprotocol message length

Connect

FieldTypeExpr accessDescription
UsernamestringConnect.Usernamebasic auth username
PasswordstringConnect.Passwordbasic auth password
TokenstringConnect.Tokenauth token
NkeystringConnect.NkeyNKey public key
JWTstringConnect.JWTJWT credential
SigstringConnect.Sigsignature
NamestringConnect.Nameclient/server name
LangstringConnect.Langclient language
VersionstringConnect.Versionclient version
ProtocolintConnect.Protocolprotocol version
AccountstringConnect.Accountaccount name
EchoboolConnect.Echoecho mode
VerboseboolConnect.Verboseverbose mode
PedanticboolConnect.Pedanticpedantic mode
TLSRequiredboolConnect.TLSRequiredTLS required
HeadersboolConnect.Headersheaders support
NoRespondersboolConnect.NoRespondersno responders
AccountNewboolConnect.AccountNewnew account flag
ProxySigstringConnect.ProxySigproxy signature

Leaf-only fields:

FieldTypeExpr accessDescription
IDstringConnect.IDserver ID
ServerNamestringConnect.ServerNameserver name
RemoteAccountstringConnect.RemoteAccountremote account
ClusterstringConnect.Clustercluster name
HubboolConnect.Hubis hub
DomainstringConnect.Domaindomain
JetStreamboolConnect.JetStreamJetStream enabled
CompressionstringConnect.Compressioncompression mode
DenyPub[]stringConnect.DenyPubdenied publish subjects
IsolateboolConnect.Isolateisolation flag
ImportSubjectPermissionConnect.Import.Allowimport permissions
ExportSubjectPermissionConnect.Export.Allowexport permissions

Message

FieldTypeExpr accessDescription
SubjectstringMessage.Subjectmessage subject
SIDstringMessage.SIDsubscription ID
ReplyTostringMessage.ReplyToreply subject
Payload[]byteMessage.Payloadmessage body
Headersmap[string][]stringMessage.HeadersNATS headers
Queues[]stringMessage.Queuesqueue groups

AccountInfo

FieldTypeExpr accessDescription
AccountstringAccountInfo.Accountaccount name
IsSystemAccountboolAccountInfo.IsSystemAccountsystem account flag

Config

Available for built-in rules only. Contains the rule's configuration as set in the .conf file. nil for custom rules.

Custom functions

Subject functions

FunctionReturnsDescription
subjectMatch(subject, pattern)boolNATS wildcard match (* matches one token, > matches one or more)
subjectHasWildcards(subject)booltrue if subject contains * or >
isLiteralSubject(subject)booltrue if subject has no wildcards

JetStream functions

FunctionReturnsDescription
normalizeJSSubject(subject)stringstrip domain/prefix from JetStream subjects to $JS.API... form
fromJsRequest()typed structparse JetStream request from message payload; returns the appropriate jsm.go API type (cached per message)
hasAllowedConsumerFilter(allowed)booltrue when all consumer filter subjects are within at least one allowed pattern
hasDeniedConsumerFilter(denied)booltrue when any consumer filter subject overlaps a denied pattern

Header functions

FunctionReturnsDescription
hasHeader(config, headers)boolcheck headers against config map; keys are header names, values are regex patterns (empty = existence check); OR logic across entries

Payload functions

FunctionReturnsDescription
payloadMatches(config, subject, payload)boolmatch payload against regex based on subject pattern
regexMatch(str, pattern)boolGo regex match (cached)
bytesToString(data)stringconvert payload bytes to string

Time functions

FunctionReturnsDescription
matchesTime(schedule, timestamp)boolcron schedule match; format: minute hour day month weekday; truncated to minute precision

Network functions

FunctionReturnsDescription
matchCIDR(address, cidr)boolIPv4/IPv6 CIDR match (cached)

Auth functions

FunctionReturnsDescription
IsTrustedExternalSigner(token, config)boolJWT signature verification; config format: algorithm:base64key

Utility functions

FunctionReturnsDescription
infoLog(message, ...params)boollog at info level; always returns true
debug(...params)booldebug output to stderr; always returns true

Evaluation flow

Fact filtering

When a client or leafnode connects, the engine filters the port's ruleset against the connection's facts. Only matching rules are kept for that connection's lifetime.

When a bundle is activated, deactivated, or upgraded on a port, all active connections on that port are re-evaluated. If the changed ruleset contains connect rules matching a connection's facts, the connection is disconnected to force a full re-evaluation on reconnect.

Per-message evaluation

For each protocol message, the engine iterates through the filtered ruleset:

  1. Condition matching — conditions are grouped by key. Within a key, values use OR logic. Across keys, AND logic. If conditions don't match, the rule is skipped.
  2. Rule body evaluation — rule bodies are evaluated in order. Each expression returns a boolean; the corresponding success or fail action is applied.
  3. Short-circuit on deny/error — if any body returns deny or error, evaluation stops immediately.
  4. Rule default — if no rule body produced a result, the rule's default action is used.
  5. No rules matched — if no rules produced any results, the port's unmatched action applies (defaults to deny).