---
title: "Introducing Security Groups External Sources"
description: "Security groups are gaining in flexibility with the ability to add external sources as objects"
date: 2021-11-23
author: "Pierre-Yves Ritschard"
tags: ["security"]
url: https://www.exoscale.com/blog/introducing-security-group-external-sources/
---
# Introducing Security Groups External Sources

Security Groups form the base primitive with which to build advanced
networking setups on Exoscale as we previously demonstrated in [our
bastion article][1] and [our behind the scenes article][2].

Today we are thrilled to announce the general availability of
*External source* support in Security Groups.

### Current situation

As a quick reminder, Security Groups have two key components:

- A list of rules to apply to members of the group
- A list of members in the group

Having these two components in *Security Group* definition allows for
instance to create rules which let through traffic for all members of a
specific group. Conversely, the list of members is derived from the
list of instances belonging to the group.

### Enabling more

A common request to enable Security Groups to natively work well with
external infrastructure is to have the ability to add CIDRs to the
list of sources, allowing them to become part of the authorized CIDRs
when rulesets are actually applied on target virtual machines.

This enables not only Exoscale instances or nested security groups but also
those external sources to be part of a definition.

### Taking it for a tour

Let's assume we are following the procedure laid out in our
[bastion article][1] but we
would like to also authorize our fictional VPN exit IP 198.51.100.1 as an
authorized source.

This would involve adding the IP to the *management* Security Group:

```
exo compute security-group source add management 198.51.100.1/32
 ✔ Adding Security Group source 198.51.100.1/32... 3s
┼──────────────────┼──────────────────────────────────────┼
│  SECURITY GROUP  │                                      │
┼──────────────────┼──────────────────────────────────────┼
│ ID               │ be5f0364-d146-4578-b5fb-faf648f02481 │
│ Name             │ management                           │
│ Description      │                                      │
│ Ingress Rules    │ -                                    │
│ Egress Rules     │ -                                    │
│ External Sources │ 198.51.100.1/32                      │
┼──────────────────┼──────────────────────────────────────┼
```

> [!NOTE]
> **tip**
>
> you can shorten `exo compute security-group` to `exo c sg`

Let's now make sure that the external source was added:

```
exo compute security-group show management
```

### Use Exoscale networks as sources

A first use-case application of this new feature is to enable CIDRs
from Exoscale sources such as the IPs of a full zone to be used in
a security group. For this purpose we are also introducing the official
publication of our IP sources as both a [JSON file][3] and [Geofeed][4] format
compliant with RFC 8805 from August 2020.

Those lists are officially maintained and can be consumed by your favorite
configuration management tools such as Terraform.

### What's next

While this facility is already useful today and fully available in the
Exoscale API and command-line tool, we intend to follow-up with
the following complementing features:

- Web portal integration.
- Terraform support.
- A number of public groups to represent Exoscale sources (zone
  ranges, healthcheck monitor ranges, SOS endpoint ranges amongst
  others) without having to parse our JSON file.


[1]: https://www.exoscale.com/blog/secure-your-cloud-computing-architecture-with-a-bastion/
[2]: https://www.exoscale.com/blog/behind-scenes-security-groups/
[3]: https://exoscale-prefixes.sos-ch-dk-2.exo.io/exoscale_prefixes.json
[4]: https://exoscale-prefixes.sos-ch-dk-2.exo.io/exoscale_geofeed