# Configuration Reference > With DiscrimiNAT, the Security Groups attached to the applications that need filtered access to the Internet can be annotated with the set of allowed FQDNs. This allows creating **least privilege egress policies** from the protected workload to the Internet. With DiscrimiNAT, the Security Groups attached to the applications that need filtered access to the Internet can be annotated with the set of allowed FQDNs. This allows creating **least privilege egress policies** from the protected workload to the Internet. No need to create VPC-wide allowlists that allow discrete applications access to what they needn't. :::tip DiscrimiNAT's own Security Groups need not be altered. ::: On this page, we cover the syntax for the Cloud-native Security Groups' **description** fields, where the annotations live. ### See-Thru mode The `see-thru` mode is a non-blocking configuration that allows one to [build an appropriate allowlist 🎥](/docs/discriminat/aws/logs-ref/#building-an-allowlist-from-scratch-video-version) up to a specified date. The annotation is added to the description fields of **outbound rules of protected applications to-be**. #### Syntax `discriminat:see-thru:YYYY-mm-dd` :::caution The rule will automatically stop working **after** the `YYYY-mm-dd` date. ::: #### Examples `discriminat:see-thru:2026-12-31` `discriminat:see-thru:2026-09-09` Configuring this mode in the **AWS web console** would look like: ![](img/aws-see-thru-security-group-example.png) In **Terraform**, this would be along the lines of: ``` resource "aws_security_group" "some-app" { name = "monitor-some-app" vpc_id = var.vpc_id egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = ["0.0.0.0/0"] description = "discriminat:see-thru:2026-12-31" } } ``` #### Logs The **flow** logs stream under the DiscrimiNAT log group in CloudWatch will have three additional fields for traffic from any workload that has a Security Group attached with a `see-thru` Rule in it: 1. `see_thru_exerted`: **true** when no `tls` or `ssh` protocol rules allowed this connection through and it's only because of the `see-thru` rule that the connection has been let through. **false** when an already present `tls` or `ssh` protocol rule would otherwise allow this connection through. The rest of the fields in the log line remain as they would without the `see-thru` rule, hence indicating which `tls` or `ssh` protocol rule matched to let this connection through. 1. `see_thru_gid`: The Security Group ID where the enacted `see-thru` was found. 1. `see_thru_days_remaining`: The number of remaining days this rule will continue to work. Runs into negative if the current date goes past the specified date. These log fields are still emitted if a `see-thru` rule with any date, past or future, remains specified. ### TLS and SSH mode The `tls` and `ssh` modes are a blocking configuration that will only allow FQDNs set out in the allowlist. Destination protocols, [FQDNs](https://en.wikipedia.org/wiki/Fully_qualified_domain_name) and IP Addresses are added to the description fields of **outbound rules of the protected applications**. :::caution If transitioning from a `see-thru` rule, note that `tls` and `ssh` rules **require a specific port number** to be specified in the Security Group Rules. ::: #### Syntax `discriminat::` ([ARN variant](#arn-variant)) `discriminat::[,,]` ([Inline variant](#inline-variant)) - Valid protocols are `ssh` and `tls` only. - There can be other text leading and trailing this specification, separated by whitespace. - All of it is case insensitive, except the ARN if specified. - [Wildcards](/docs/discriminat/aws/default-prefs/#wildcard_exposure) are only supported for the TLS protocol. :::caution **Please familiarise yourself with [operation and caveats](/blog/wildcards-and-system-2-thinking/#operation) on the behaviour of wildcard rules before using them.** ::: #### ARN variant - The \ is the full ARN of an SSM Parameter or a Secret. It can be in another AWS Account and/or Region as well, as long as DiscrimiNAT's IAM Instance Profile has [permissions](/docs/discriminat/aws/iam-instance-profile/) to read it. - If using our Terraform modules, consider adding the full ARNs of SSM Parameters to the `iam_get_additional_ssm_params` list variable and of Secrets to the `iam_get_additional_secrets` list variable to automatically update the IAM Instance Profile with requisite _Get_ permissions. - The JSON format for list of FQDNs and IP Addresses in the payload of an SSM Parameter or a Secret is: ```json { "addrs": [ "fqdn1.com", "*.github.com", "203.0.113.9", ... ] } ``` ##### Examples If the above payload were to be stored in an SSM Parameter called `team-foo-allowed-fqdns`, its full ARN could be `arn:aws:ssm:eu-west-2:111111111111:parameter/team-foo-allowed-fqdns`. Therefore, what goes in description field will be: `discriminat:tls:arn:aws:ssm:eu-west-2:111111111111:parameter/team-foo-allowed-fqdns` And if in a Secret: `discriminat:tls:arn:aws:secretsmanager:eu-west-2:111111111111:secret:service-foo-allowed-fqdns` Configuring this variant in the **AWS web console** would look like: ![](img/aws-arn-security-group-example.png) #### Common constraints to both variants - Under `Type`, choose any TCP protocol type and **specify exactly one port number** in `Port range`. To use another port for an alternative set of addresses, simply create another Security Group Rule with that port number. See the [Connecting to MS/Azure SQL Server over TLS](/docs/how-to/tls-upgrade/sql-server/#on-aws) guide for an example. - For your typical **HTTPS** outbound connection, the port number would be `443`. - A typical **SFTP** connection has the port number of `22`. - **Kafka** typically, as another example, is on port `9092`. - `Destination` must be set to the narrowest IP block you can think of. Now if you don't have anything narrower than `0.0.0.0/0` that is absolutely fine! The firewall takes care of validating the destination IP address of actual packets in many ways, but the outbound rule at the AWS networking and security level must allow the packet to leave the protected workload at all. **`0.0.0.0/0` is a safe choice with the DiscrimiNAT Firewall in the way.** - Should you wish to use the same port number again with a different Rule, set the destination to `0.0.0.0/1` or `0.0.0.0/2` or `0.0.0.0/3` and so on. - Multiple such Rules can be added to one Security Group and all of them will be recognised. :::tip You can attach multiple Security Groups to EC2 instances. It's a great way to bunch together related FQDNs. ::: #### Inline variant - There can be as many FQDNs and IP Addresses as you can fit separated by commas. There cannot be whitespace, though. - Multiple Security Groups can be created to accommodate more addresses, or group them by some criteria. - Alternatively, multiple outbound Rules within the same Security Group can be created with destination CIDRs varying like `0.0.0.0/0`, `0.0.0.0/1`, `0.0.0.0/2` and so on. ##### Examples - `DiscrimiNAT:TLS:api.foo.example.com,downloads.example.net,203.0.113.9` - `DiscrimiNAT:SSH:sftp.txs.example.org,ssh.github.com` - `discriminat:tls:api-v_.example.com discriminat:tls:www.example.org` - `lorem ipsum discriminat:ssh:ssh.github.com,gitlab.com,203.0.113.9 dolor sit amet` Configuring this variant in the **AWS web console** would look like: ![](img/aws-inline-security-group-example.png) In **Terraform**, this would be along the lines of: ``` resource "aws_security_group" "acme" { name = "acme-reports-upload" vpc_id = var.vpc_id egress { from_port = 443 to_port = 443 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] description = "discriminat:tls:api.acme.com,auth.acme.com,203.0.113.9,foo.example.com,bar.example.net" } } ``` ### Complete Bypass If you would like to discuss alternate protocols or know how to completely bypass DiscrimiNAT whilst still routing traffic, get in touch with our [DevSecOps Support](/support/) to discuss the best option for your use case.