# DiscrimiNAT OTF Google Cloud Default Preferences > Configure deployment-wide DiscrimiNAT OTF preferences on Google Cloud for allowlists, wildcard exposure, see-thru monitoring, and StartTLS SMTP. # Default Preferences From v2.9.0 of DiscrimiNAT, certain behavioural preferences can be set at global level per deployment. These are defined in JSON format in a Secret named `DiscrimiNAT_` (case-sensitive) in Secret Manager and the default value if not defined or not accessible is: ```json { "%default": { "allowlist": { "tls": null, "ssh": null }, "wildcard_exposure": "prohibit_public_suffix", "flow_log_verbosity": "full", "see_thru": null, "x509_crls": "ignore", "starttls": { "smtp": { "posture": "closed", "ehlo_entropy_limit": 0 } } } } ``` :::tip Preferences you wish to leave at defaults can be excluded. Also, any additional JSON keys will simply be ignored. ::: :::caution Preferences are refreshed **once every five minutes** from the Secret. ::: ## Preferences ### allowlist This JSON key is the parent for nested, protocol-specific default allowlists. A default allowlist is a list of allowed addresses that applies to workloads not discovered by DiscrimiNAT or that have no Firewall Rule level allowlist specification. The only protocols supported at this time are `tls` and `ssh`. #### Default `"allowlist":{"tls":null,"ssh":null}` ### allowlist.tls This nested key under `allowlist` sets the default list of allowed addresses (FQDNs or IP addresses) over the TLS protocol, on port 443 unless overridden, for all workloads. The value is supposed to be the full path of a Secret containing a list of addresses. See the [Secret Path variant docs](/docs/discriminat/gcp/config-ref/#secret-path-variant) for more. #### Example `{"tls":"projects/000000000000/secrets/foo-default-allowed-fqdns"}` ### allowlist.ssh Same as `tls` above but for the SSH protocol, and on port 22 unless overridden. ### wildcard_exposure Generally, `?` represents one character match exactly which isn't a `.`, and `*` matches any number of characters except `.`. #### Options `none`: no wildcard characters such as `?` or `*` are allowed at all `prohibit_asterisk`: `?` is allowed; `*` is not allowed `prohibit_public_suffix`: `?` is allowed; `*` is allowed as long as the possibility of resulting domain names are not publicly registrable (aka Effective TLDs). For example, `*.github.com` is okay but `*.github.io` is not. Another example would be `*.cloudflare.net` being effectively public. This is determined using [Mozilla's Public Suffix List (PSL)](https://publicsuffix.org/) bundled into DiscrimiNAT. The version of the PSL bundled will be in the [Release Notes](/docs/discriminat/gcp/release-notes/) and will be updated with every release. :::tip If a wildcard pattern is not accepted because it could have led to a Public Suffix List match, a _config_ log message like the following will be emitted: ``{addr: "*.github.io", cat: "addr", outcome: "publicsuffix[.]org list matched with `github.io`"}`` ::: `nuclear`: `?` is allowed; `*` is allowed with no public suffix list safeguard #### Default `prohibit_public_suffix` ### flow_log_verbosity This setting only impacts the _flow_ logs. _config_ logs verbosity and behaviour will not be affected. #### Options `full`: all _allowed_ and _disallowed_ flows for both the client requests and the server responses are logged in the _flow_ logs `only_disallowed`: only _disallowed_ flows will be logged `none`: no logs at all #### Default `full` ### see_thru The `see_thru` non-blocking, monitoring mode can be enabled for an entire deployment rather than per Firewall Rule from this level. This is only the default and does not override a _see-thru_ mode defined at a more granular level – even if the one at the granular level may have expired. :::tip See [see-thru](/docs/discriminat/gcp/config-ref/#see-thru-mode) mode docs for understanding this non-blocking, monitoring mode in detail. ::: #### Options `yyyy-mm-dd` formatted date `null` to not enable _see_thru_ at the default level. `null` value to be specified without quotes or this top-level key can be left out completely. #### Default `null` ### x509_crls #### Options `auto_allow`: Automatically allow plaintext HTTP CRL Endpoints of x509 SSL certificates for all TLS FQDNs allowlisted. `ignore`: Do not allow CRL Endpoints automatically. #### Default `ignore` ### starttls This JSON key is the parent for nested, protocol-specific StartTLS preferences. The only StartTLS protocol supported at this time is `smtp`. #### Default `"smtp":{"posture":"closed","ehlo_entropy_limit":0}` ### starttls.smtp :::tip See the [StartTLS SMTP](/docs/how-to/starttls/smtp/) guide for safely enabling this capability. ::: This nested key under `starttls` controls the posture and limits for the SMTP protocol's StartTLS commands, i.e. the plaintext communication before the connection upgrades to TLS. #### Default `{"posture":"closed","ehlo_entropy_limit":0}` ### starttls.smtp.posture This nested key under `starttls.smtp` sets the deployment-wide posture for DiscrimiNAT to let StartTLS SMTP plaintext commands pass through or not. This includes messages received from an SMTP server beginning with `220` and `250`, and messages sent by a client beginning with `EHLO` and `STARTTLS`. #### Options `closed`: StartTLS SMTP plaintext commands are not allowed. `open`: StartTLS SMTP plaintext messages received from an SMTP server beginning with `220` and `250`, and messages sent by a client beginning with `EHLO` and `STARTTLS` are allowed. #### Default `closed` ### starttls.smtp.ehlo_entropy_limit This nested key under `starttls.smtp` sets the deployment-wide Shannon Entropy limit of the argument to the `EHLO` command in `EHLO` messages sent by any client to the Internet. For example, in the StartTLS command `EHLO mail.example.com\r\n`, the argument is `mail.example.com` of which the Shannon Entropy is `3.20`. `EHLO` messages sent by a client exceeding this limit will be disallowed by DiscrimiNAT. Shannon Entropy is rounded to two decimal places with the [MidpointAwayFromZero strategy](https://docs.rs/rust_decimal/latest/rust_decimal/enum.RoundingStrategy.html#variant.MidpointAwayFromZero). For example, `3.2028` becomes `3.20`, `3.25` remains `3.25` and `3.256` becomes `3.26`. You can calculate the Shannon Entropy of any text input using [GCHQ's CyberChef Entropy tool set to the Shannon scale](https://gchq.github.io/CyberChef/#recipe=Entropy('Shannon%20scale')). [Shannon Entropy is a measure of the average amount of information contained in a message](https://jollycontrarian.com/index.php/Shannon_entropy). It can range from 0 to 8, where the higher the number the more 'information' it can pack by the way of encoding. :::caution Higher numbers can be indicative of exfiltration via the EHLO argument. See the [StartTLS SMTP](/docs/how-to/starttls/smtp/) guide for safely enabling this capability. ::: #### Range Minimum: `0.00` Maximum: `8.00` #### Default `0` ## Examples It may be useful to turn on the non-blocking, monitoring `see_thru` mode on until a specified date on a new deployment of DiscrimiNAT. This would ensure apps continue to work while data is captured for building an allowlist from eventually: `{"%default":{"see_thru":"2026-11-19"}}` :::tip Also see [building an allowlist from scratch video recipe](/docs/discriminat/gcp/logs-ref/#building-an-allowlist-from-scratch-video-version). ::: Ultimately, when allowlists are built and enforced, you may want to turn off _flow_ logs for _allowed_ connections, saving on logging costs: `{"%default":{"flow_log_verbosity":"only_disallowed"}}` To also enable automatic allowing of X509 CRL Endpoints: `{"%default":{"flow_log_verbosity":"only_disallowed","x509_crls":"auto_allow"}}` ## System System-level preferences are passed directly to VM instance creation, are stored as files on the operating system disk, and are only read on start. These are placed within the instance because they represent critical customer choices that must be respected whether external APIs are accessible or not and the right IAM permissions on the Service Account are assigned or not. ### BYOL A licence key supplied by Chaser Support if using a BYOL version. The value can be passed to the `byol` variable in our [Terraform modules](https://registry.terraform.io/namespaces/ChaserSystems). The contents are Base64 decoded and written to the path `/etc/chaser/licence-key.der`. ### ASHR Automated System Health Reporting. 10 minutes after boot and then at around 0200 UTC every day, each instance of DiscrimiNAT collects its OS internals & system logs since instance creation, config changes & traffic flow information from last two hours and uploads it to a Chaser-owned cloud bucket. This information is encrypted at rest with a certain public key so only relevant individuals with access to the corresponding private key can decrypt it. The transfer is encrypted over TLS. Access to this information is immensely useful to create a faster and more reliable DiscrimiNAT as we add new features. We also get to learn about how users interact with the product in order to further improve the usability of it as they embark on a very ambitious journey of fully accounted for and effective egress controls. We understand if certain environments within your deployment would rather not have this turned on. To disable it, a file at the path `/etc/chaser/disable_automated-system-health-reporting` should exist. This can be achieved by setting the `ashr` variable to `false` in our [Terraform modules](https://registry.terraform.io/namespaces/ChaserSystems).