Firewallregels en IP groups voor workload teams¶
Verkeer dat je spoke verlaat, binnenkomt of naar een andere spoke gaat, passeert de centrale firewall, en de firewall blokkeert alles wat geen regel toestaat. Deze pagina helpt je om een regel aan te vragen of, als je platform dat toestaat, de wijziging zelf voor te bereiden als pull request. Wat je moet aanvragen, wie moet goedkeuren en welk regeltype je kiest staat al beschreven op Hoe doe je een aanvraag. De ontwerpregels die het platformteam volgt staan in de richtlijnen voor firewallregels en IP groups. Die herhalen we hier niet. Deze pagina toont de bestanden en de stappen vanuit jouw kant.
Kies je route¶
| Route | Jij doet | Het platformteam doet |
|---|---|---|
| Aanvraag | Vul de aanvraagvelden van Hoe doe je een aanvraag in een ticket in. | Bewerkt de bestanden, laat de wijziging reviewen en deployt die. |
| Pull request | Bewerk de bestanden zelf, open een pull request en koppel die aan een ticket. | Reviewt, merget en deployt. Je rondt nooit je eigen pull request af. |
Voor de pull request-route heb je toegang tot de configuratierepository nodig. Vraag je platformteam of die voor jou openstaat (Hoe doe je een aanvraag). Elke regel heeft nog steeds een ticket nodig: het ticket is het wijzigingsrecord en bevat de goedkeuringen.
Voordat je begint¶
- Ken het verkeer. Bron (je spoke of subnet), bestemming (FQDN, adres, service tag), poort en protocol, en waarom je het nodig hebt. Zoek bij internetbestemmingen de FQDN op. Het IP-adres van een publieke service kan veranderen.
- Weet wie goedkeurt. De eigenaar van de bestemming keurt regels tussen workloads goed. Security beoordeelt veel andere regels. Zie Wie vraagt welke regel aan en Wat de review meestal controleert.
- Controleer wat er al is. Een regel kan je verkeer al dekken. Kijk in de bestanden van je workload in de configuratierepository.
De bestanden in het kort¶
| Wat | Waar | Eén bestand is |
|---|---|---|
| Firewallregels | firewall_rule_configuration/ (globaal) of <region>/firewall_rule_configuration/ (één regio) |
Eén rule collection group |
| IP groups | ip_groups/ (globaal) of <region>/ip_groups/ (één regio) |
Eén IP group |
Elke platformomgeving heeft zijn eigen mappen (canary en prod). Een wijziging komt in beide, eerst canary. Je
niet-productie- en productieverkeer zitten meestal in aparte rule collection groups, zodat productiedata niet naar
niet-productie kan stromen.
Een firewallregel voorbereiden¶
1. Zoek of maak het bestand van je workload¶
Regels zijn per workload georganiseerd. Gebruik het bestand van je workload en omgevingstype. Als dat er niet is, vertelt het platformteam je de map en het prioriteitsbereik. Kies niet zomaar zelf een prioriteit: prioriteiten moeten uniek zijn en binnen het bereik van de eigenaar vallen.
2. Schrijf de regel¶
Een rule collection group heeft drie maps: NAT-, network- en application rule collections. Alle drie moeten aanwezig zijn, ook als ze leeg zijn. Dit is een regel in een network collection, en een in een application collection:
{
"rule_collection_group": {
"name": "app1-prod",
"priority": 2100,
"nat_rule_collections": {},
"network_rule_collections": {
"NetworkRules": {
"priority": 110,
"action": "Allow",
"rules": {
"app1-vm-to-servicebus": {
"protocols": ["TCP"],
"source_addresses": [],
"source_ip_groups": ["ipgrp-app1-web-prod"],
"destination_addresses": [],
"destination_ip_groups": [],
"destination_fqdns": ["<namespace>.servicebus.windows.net"],
"destination_ports": ["443"]
}
}
}
},
"application_rule_collections": {
"ApplicationRules": {
"priority": 120,
"action": "Allow",
"rules": {
"app1-to-vendor-api": {
"protocols": ["Https:443"],
"source_addresses": [],
"source_ip_groups": ["ipgrp-app1-web-prod"],
"destination_fqdns": ["api.vendor.example"],
"destination_fqdn_tags": []
}
}
}
}
}
}
De getallen en namen zijn voorbeelden. Gebruik de waarden die je platformteam je geeft.
Vuistregels:
- Application rule voor HTTP-, HTTPS- en SQL-verkeer naar een FQDN. Network rule voor al het andere. De checklist staat in Application of network rule.
- Eén brontype en één doeltype per regel. Gebruik als bron adressen of IP groups, en als bestemming adressen, IP groups of FQDN's. Laat de andere lijsten leeg.
- Exacte poorten, geen wildcards. Vraag niet om
*, omAnyof om brede bereiken zonder reden. - FQDN in plaats van IP-adres voor internetbestemmingen.
- Eén ticket en één pull request per rule collection group. Combineer geen niet-gerelateerde wijzigingen.
- Om een regel te vervangen, voeg eerst de nieuwe regel toe en vraag daarna om verwijdering van de oude.
Alle properties, de toegestane waarden en de limieten staan in Rule collection group JSON.
3. Gebruik IP groups voor sets adressen¶
Als meer dan één regel dezelfde set adressen gebruikt, zet die dan in een IP group en verwijs er op naam naar (hieronder).
4. Controleer het bestand¶
Gebruik een editor die de JSON-schema's kent. Die stelt de properties voor, toont de toegestane waarden en onderstreept fouten (De JSON-bestanden bewerken met schema-ondersteuning). Als je kunt, draai dan ook de config tests van de repository (De tests lokaal draaien).
5. Open de pull request¶
- Branchnaam en titel zoals je platformteam heeft afgesproken, bijvoorbeeld
[APP1] Add firewall rules - Service Bus connectivity. - Beschrijving: het verkeer (van waar, naar waar, welke poort en welk protocol), de reden, de omgevingen en het ticket.
- Maak dezelfde wijziging in de map
canaryen de mapprod. - Wacht op de checks van de pipeline en los op wat ze melden.
- Rond de pull request niet zelf af. Het platformteam reviewt hem met de checklist voor firewallregels.
IP groups¶
Een IP group is een benoemde set adressen en bereiken. Regels verwijzen er op naam naar, zodat je de adressen op één plek wijzigt.
Wanneer je er een gebruikt en wanneer niet, staat in IP groups. Kort gezegd: gebruik er een voor een set die meerdere regels gebruiken, die regelmatig verandert of die één duidelijk doel heeft (de webservers van één workload in productie). Maak er geen voor de adressen van één enkele regel.
Het bestand is klein:
{
"ip_group": {
"name": "ipgrp-app1-web-prod",
"cidrs": ["10.20.4.0/26"]
}
}
name: uniek, en volgens het naamgevingsschema van je platform. De naam zegt wat de adressen zijn.cidrs: IPv4-adressen of -bereiken (een enkele host als/32).- Meng geen niet-gerelateerde subnets in één groep en voeg geen adressen toe die niet voor het doel zijn afgesproken.
- Maak de groep in dezelfde pull request als de regels die hem gebruiken, of eerder.
- Om de adressen van een groep te wijzigen, bewerk je het bestand. Elke regel die de groep gebruikt volgt mee, dus vermeld in de pull request welke regels geraakt worden.
- Om een groep te hernoemen of te verwijderen, vraag je het platformteam dat in twee stappen te doen: eerst de regels, dan de groep.
Het runbook voor operators is IP groups.
Na de merge¶
- Het platformteam deployt naar canary, controleert het resultaat en deployt naar productie. Je wordt via het ticket geïnformeerd (Wat er daarna gebeurt).
- Test het verkeer vanuit je workload, bijvoorbeeld met
curlofTest-NetConnection <destination> -Port <port>. - Werkt het niet, controleer dan eerst dit voordat je om hulp vraagt: de regel bestaat in de firewall policy, de NSG van je subnet staat het verkeer toe, de naam wordt opgelost en de bestemming accepteert de verbinding. Het platformteam kan de firewall logs voor je bron en bestemming bekijken (De firewall logs lezen).
- Laat het platformteam weten wanneer het ticket gesloten kan worden.
Niet doen¶
- Firewallregels wijzigen in de portal. De volgende deployment overschrijft ze.
- Een regel aanvragen die je nog niet nodig hebt. Is de toegang tijdelijk, zeg dat dan in het ticket en geef de einddatum, zodat de regel verwijderd kan worden.
- Regels gebruiken om productie en niet-productie te verbinden.
Gerelateerd¶
- Hoe doe je een aanvraag
- Netwerk en IP-dimensionering
- SFTP inbound toegang (een firewallregel die inkomend verkeer vertaalt)
- Support