Nätverksisolering

Plattformen stänger in varje boundary med samma uppsättning nätverksregler. Den skriver dem i var och en av boundaryns resursgrupper, på varje kluster, och håller dem på plats.

Viktigt

En ny resursgrupp får sina regler vid plattformens nästa genomgång, som körs var femte minut som standard. Fram till dess gäller ingen av reglerna nedan för den: dess arbetslaster kan ansluta vart som helst, molnens metadataadresser (169.254.0.0/16) inräknade, och ta emot anslutningar från allt vars egna regler släpper igenom dem.

Vad reglerna tillåter

• Inom boundaryn. Arbetslaster i boundaryns alla resursgrupper når varandra på alla portar, i båda riktningarna.
• Routad webbtrafik. Klustrets ingress-kontroller kan nå varje arbetslast, så att appar och andra publicerade slutpunkter får sin trafik.
• Utgående HTTPS. Varje arbetslast kan öppna TCP 443 mot vilken adress som helst, utom molnens metadatatjänster och andra link-local-adresser (169.254.0.0/16), som alltid blockeras. Vilken adress som helst omfattar adresser inom klustret: en sådan anslutning går igenom när målets egna regler släpper in den.
• Klustrets API. Varje arbetslast kan öppna TCP 6443, Kubernetes API-serverns port. Om inte plattformsadministratören har begränsat den gäller det TCP 6443 mot vilken adress som helst.
• DNS och telemetri. Namnuppslag (port 53) och plattformens telemetrimottagare går alltid att nå.
• Det plattformen själv behöver. Snäva regler med ett syfte var: byggen som skickar avbildningar till plattformens register, arbetslaster som hämtar sina hemligheter när de startar, plattformens databasutforskare och databasoperator som når databaser, och några till. Alla finns i Nätverksregler och orsaker.

Vad reglerna blockerar

• Andra boundaries. Arbetslaster i två olika boundaries kan inte ansluta till varandra, utom till det som en av dem publicerar — se Mellan boundaries.
• Utgående trafik på alla andra portar. En databas utanför klustret på 5432, en SMTP-server på 25, ett API på 8443: allt blockeras. Det går inte att lägga till utgående regler för andra portar i dag.
• Allt annat inkommande. Bara källorna ovan, och de som anropar det du publicerar via en lastbalanserare (se Databaser), kan öppna en anslutning till dina arbetslaster.

En blockerad anslutning misslyckas inte tydligt. Den hänger tills klienten ger upp, och applikationsloggen säger bara att tiden gick ut. Boundaryns flik Nätverk finns för att tala om att det var nätverket — se Ta reda på varför en anslutning blockeras.

Databaser

En PostgreSQL-databas har en inställning, Brandvägg, i sin nätverkskonfiguration som ändrar boundary-regeln för den:

• Boundary-åtkomst — boundary-regeln ovan gäller. Det här är standardvalet.
• Endast samma resursgrupp — databasen utbyter trafik bara med sin egen resursgrupp, i stället för med hela boundaryn. Plattformens egna regler gäller fortfarande.
• Valda nätverk — utöver boundary-regeln släpper databasen in TCP 5432 från varje arbetslast på klustret. Arbetslaster i andra boundaries kan ändå inte ansluta, eftersom deras egna regler inte öppnar utgående TCP 5432; i praktiken släpper inställningen in arbetslaster på klustret som inte ligger i någon boundary.

SQL Server visar samma inställning, men den har ingen effekt på SQL Server i dag: boundary-regeln gäller oavsett vilket val som sparas.

En databas eller containerinstans som publiceras via en lastbalanserare får dessutom en regel för sina publicerade portar. När resursen har en lista med tillåtna adresser släpps bara de adresserna in. Utan en sådan lista släpper regeln in vilken källa som helst, på klustret såväl som utanför det.

Mellan boundaries

En anslutning kräver att reglerna i båda ändar tillåter den: anroparens utgående regler och målets inkommande regler. Mellan två boundaries sker det på två sätt:

• Routad webbtrafik. Klustrets ingress-kontroller når arbetslaster i varje boundary. En apps routade adress betjänar den som når den, och det kan vara arbetslaster i andra boundaries.
• Slutpunkter bakom lastbalanserare. En databas eller containerinstans som publiceras via en lastbalanserare utan en lista med tillåtna adresser släpper in vilken källa som helst på sina publicerade portar. En arbetslast i en annan boundary kommer igenom på en port som dess egna utgående regler öppnar, till exempel TCP 443.

Det du publicerar publiceras alltså även för andra boundaries. En lista med tillåtna adresser på resursen begränsar en slutpunkt bakom lastbalanserare till de adresserna, och det som kommer igenom måste fortfarande klara målets egen inloggning.

Att nå är inte att få åtkomst

En regel som släpper igenom en anslutning betyder bara att den når fram. Målet avgör fortfarande om anroparen släpps in: en databas frågar fortfarande efter inloggningsuppgifter, och hemlighetstjänsten kontrollerar fortfarande arbetslastens identitet.

Reglerna kan inte ändras inifrån

Plattformen är den enda som skriver nätverksregler i en boundarys resursgrupper. En nätverkspolicy som någon skriver in i en av dem för hand tas bort vid plattformens nästa genomgång, så isoleringen kan inte luckras upp inifrån boundaryn.

Mellan kluster

Reglerna gäller kluster för kluster, och en arbetslasts adress inom klustret fungerar bara på dess eget kluster. För att anropa en tjänst i samma boundary på ett annat kluster med dess vanliga namn slår du på Crosslink.