Terminalsessioner

Knappen Terminal på en containerinstans flik Komponenter öppnar ett interaktivt skal i en av dess poddar. Den här sidan är till för dem som driver plattformen: var sessionerna finns, vad som begränsar dem och vad som sparas om dem.

Var en session körs

Portalen håller sessionen öppen över en liveanslutning till plattformens API, /hubs/crates. Plattformens API kontrollerar kernel/crates/exec på boundaryn — en roll som bara är tilldelad på resursgruppen eller instansen räcker inte — sedan containerinstance/exec på instansen, kontrollerar att podden hör till den och startar /bin/sh i den valda containern via Kubernetes API, som plattformens eget tjänstekonto. Tangenttryckningar och utdata går genom plattformens API så länge sessionen varar.

Sessionerna hålls i plattforms-API:ets minne. En session avslutas när användaren stänger terminalen, när skalet avslutas, när användarens anslutning till plattformens API bryts eller när plattformens API startas om.

Gränser

• Fem öppna sessioner per användare, över alla instanser på plattformen. Ytterligare en session vägras med Unable to open terminal: User … is at the concurrent terminal session cap (5). Antalet är plattforms-API:ets inställning Crates:MaxConcurrentSessionsPerUser; installationsprogrammet sätter den inte, så standardvärdet fem gäller.
• Ingen tidsgräns för inaktivitet. En session stängs inte för att den är inaktiv. Inställningen Crates:IdleTimeout (fem minuter) läses bara av den separata Crates-tjänsten, som inte håller några terminalsessioner, så den påverkar dem inte.

Vad som registreras

I dag sparar plattformen inget om terminalsessioner:

• Att öppna och stänga en session skriver ingenting till instansens logg Aktivitet.
• Varje rad som skrivs passerar ett maskeringssteg som döljer lösenord och token, och slängs sedan. För varje slängd rad loggar plattformens API varningen Crate command audit row dropped (session …, seq …) — no durable writer configured in this host., utan kommandot.

Behandla containerinstance/exec därefter: ett skal i en podd läser allt som arbetslasten kan, valvhemligheter inräknade, och ingenting registrerar vad som gjordes med det. De inbyggda roller som har den är Owner, Contributor och Blueprints Operator, samt Platform Owner och Platform Contributor i alla boundaries. Ändringar av filer på beständiga volymer som görs via fliken Filer registreras däremot i loggen Aktivitet.

Se upp

Ett skal kräver inte portalens terminal. Owner, Contributor, Platform Owner, Platform Contributor, Blueprints Operator och Apps Operator har också Kubernetes pods/exec i resursgruppens namnrymd, där containerinstanser körs bredvid appar. Den som har någon av de rollerna och direkt åtkomst till klustret kan köra kubectl exec i en instans containrar — även Apps Operator, som saknar containerinstance/exec — och läsa valvhemligheterna i /secrets/env.json. En sådan session går via Kubernetes API:et med personens egna autentiseringsuppgifter, inte via plattformens API, så ingen av kontrollerna eller gränserna ovan gäller för den.