Instansadgang

Åbn en interaktiv terminal på din egen compute-instans med fm shell. Instansens agent ringer ud til Frostmoln, og terminalen rider med på den forbindelse, så denne vej kræver ingen offentlig IP-adresse, ingen åben port, intet der lytter på instansen og ingen nøgle fra dig — og den åbner ingen indgående rute at nå ind ad.

Det er ikke SSH: den bruger ikke port 22, ingen nøgle er involveret, og der er ikke noget for dig at åbne i en sikkerhedsgruppe — og derfor hedder kommandoen fm shell og ikke fm ssh (både fm ssh og fm session virker stadig som aliasser). Det ændrer ikke noget ved selve instansen: hvad den lytter på, lytter den stadig på, og SSH til din egen instans er uændret og fuldt understøttet; instansadgang er en yderligere vej ind, nyttig netop når SSH ikke er det: en instans uden offentlig IP-adresse, en sikkerhedsgruppe der lukker dig ude, en nøgle du ikke længere har.

Det vælges, når instansen oprettes

Det kan ikke tilføjes til en eksisterende instans

En instans kan kun nås på denne måde, hvis den blev oprettet med instansadgang slået til. Agenten henter sin identitet fra instansen ved første boot, og der findes ingen vej til at tilmelde en instans, der allerede kører. Vil du give en eksisterende instans en shell, skal du oprette den på ny.

Slå det til ved oprettelsen, fra CLI'en eller fra Terraform. Portalens opret-formular tilbyder det endnu ikke.

fm compute instance create \
  --name web-1 \
  --image <image-id> \
  --flavor gp1.small \
  --instance-access

resource "frostmoln_instance" "web" {
  name            = "web-1"
  instance_access = true
  # ...
}

I Terraform kan instance_access kun sættes ved oprettelsen. Ændrer du, om agenten er installeret, tvinger det en udskiftning (false og uangivet betyder begge ingen agent, så at flytte mellem de to gør det ikke). API'et returnerer den ikke, og terraform import efterlader den uangivet, så instance_access = true på en importeret instans planlægger en udskiftning.

Imaget skal kunne køre agenten, og instansen skal blive ved med at nå Frostmoln udgående, så længe du vil have en shell. Platformens images gør allerede begge dele. Booter du dit eget image, så se Egne images for, hvad installationsprogrammet har brug for, og for de to måder, tilmeldingen fejler i stilhed på.

Instansadgang er kun til x86_64 Linux: agenten har brug for den arkitektur plus systemd og cloud-init, så Windows-instanser kan ikke bruge den. Dem når du i stedet via konsollen.

Åbn en shell

fm shell 9b6b2d0e-1f4c-4a7e-9c3d-2b8f5e6a1d04

Argumentet er instansens id, ikke dens navn. Skriv begyndelsen af et af dem, og tab-fuldførelse udfylder id'et.

Sæt en kommando efter -- for at køre den i stedet for at åbne en shell:

fm shell 9b6b2d0e-... -- systemctl is-active nginx

Den form er scriptsikker — output bliver ikke ødelagt af linjeskift, og kommandoens egen exitkode bliver fm's exitkode. En ting at vide, når du omdirigerer: kommandoens stdout og stderr ankommer sammenblandet på fm's stdout, så fm shell … -- cmd > out.txt fanger begge. Tilføj --tty, hvis du alligevel har brug for en tildelt terminal.

Hvilken bruger du får

Du lander som imagets standardbruger — debian på Debian, ubuntu på Ubuntu og så videre. På platformens images er det den samme bruger, som SSH giver dig. Log ind som en anden med --user:

fm shell 9b6b2d0e-... --user deploy

Et eget image uden en brugbar standardbruger giver dig en root-shell

Loginbrugeren udledes af imaget, når instansen oprettes, og hver eneste måde, den udledning kan fejle på, lander dig på root i stedet — i stilhed. Den fejler, når imaget ikke angiver nogen standardbruger, når dets distribution ikke er en, platformen genkender, og når det navn, det angiver, ikke kan bruges som en loginkonto. Det sidste er fælden: et navn med store bogstaver, f.eks. MyUser, accepteres, når du uploader imaget, og vises som loginbruger, men sessionen kører alligevel som root.

Vil du ikke have en root-shell, så giv imaget en standardbruger med et navn i små bogstaver, før du opretter instanser fra det, og kontrollér, hvilken bruger du rent faktisk lander som, første gang.

Sessioner er tidsbegrænsede

En session slutter efter 10 minutter uden aktivitet eller 1 time i alt, alt efter hvad der indtræffer først. Status 255 betyder, at sessionen døde — en grænse, en afbrudt forbindelse eller at fm selv blev dræbt. Kan fm slet ikke åbne sessionen, afslutter den med 1 og en besked på stderr. Enhver anden status er din egen kommandos.

Hvad der styrer adgangen

• Din egen organisations instanser. Du kan åbne en shell på instanser i de tenants, din organisation ejer. Alt andet er not found — det samme svar, uanset om instansen ikke findes, eller ikke er din.
• Kun der, hvor du slog det til. Instansadgang er pr. instans og sættes ved oprettelsen. En instans, der er oprettet uden, kan slet ikke nås på denne måde, af nogen.
• Tidsbegrænset. Ingen session forbliver åben i det uendelige.

Der er endnu ingen begrænsning pr. medlem — og en tenant er ikke et hegn

Ethvert aktivt medlem af din organisation kan åbne en shell på enhver instans med instansadgang slået til, uanset rolle, og i enhver tenant, din organisation ejer — ikke kun den tenant, de normalt arbejder i. Så behandl ikke en separat tenant som en adgangsgrænse her: at lægge en følsom arbejdslast i sin egen tenant holder ikke dine øvrige medlemmer ude af den. Enhver af den tenants API-nøgler kan også åbne en session.

Ingen indstilling indsnævrer dette til bestemte personer, og ingen adgangspolitik hegner det heller ind.

Indtil en gør det, er kontakten ved oprettelsen grænsen: lad instansadgang være slået fra på de instanser, hvor det betyder noget, og nå dem via SSH, hvor du bestemmer, hvem der har en nøgle.

Særligt for API-nøgler er sessions:pty den adgang, der vil afgrænse dette, og intet andet træder i stedet for den — hverken compute:* eller et wildcard, som en nøgle ikke må have. Tildel den allerede nu til enhver nøgle, der kører fm shell, så dine nøgler er rigtige fra starten. Stol ikke på den som en grænse endnu: den kontrolleres ikke, når en session åbnes, så i dag åbner en nøgle uden den stadig en session. Se API-nøgler.

Hvad det lægger på instansen, når du slår det til

Værd at vide, før du slår det til, fordi det er din maskine:

• Agenten kører som root, og bevidst uden den sandboxing, platformen anvender på sine egne administrerede instanser — den skal kunne starte en shell som den bruger, du beder om.
• Dens identitetslegitimation kan læses af enhver proces på instansen, samme situation som en instansrolle-legitimation på andre clouds.
• Et snapshot eller image af en tilmeldt instans bærer den identitet med sig, og noget gendannet fra det kan handle som originalen. Behandl et image taget fra en tilmeldt instans som følsomt, og byg helst images fra instanser, der aldrig har haft instansadgang slået til.
• Sessioner opretter ingen login-registrering, så who, last og utmp viser dem ikke. Revidér inde i instansen, hvis du har brug for et spor.

Når det ikke virker

Hvad fm fortæller dig	Hvad du skal gøre
instance not found or instance access not enabled	Id'et er forkert, instansen er ikke i denne tenant, eller den blev oprettet uden instansadgang. På en netop oprettet instans er agenten måske stadig ved at blive installeret.
this instance can't do terminal sessions	Instansen har en agent, men ikke en der betjener terminaler. fm foreslår også at opdatere agenten; der findes endnu ingen vej til at opdatere agenten, så at oprette instansen på ny er den eneste udvej.
the instance's agent is offline	Instansen er stoppet, er stadig ved at boote, eller har mistet sin udgående vej til Frostmoln. Prøv igen om lidt.
the instance agent is up and at its session limit	Der er for mange sessioner åbne på den instans på én gang. Luk en — at prøve igen hjælper ikke i sig selv. Fortsætter det, når du ikke har nogen åbne, så kontakt supporten.
session ended by the platform	Grænsen for inaktivitet eller samlet tid løb ud, eller forbindelsen blev afbrudt. Åbn en ny session.

Hvis en helt ny instans aldrig accepterer en session, mislykkedes tilmeldingen: på instansen angiver /var/log/frostmoln-managed-agent-install.log og /var/log/cloud-init-output.log årsagen. Virkede det og holdt så op, så kontrollér, at instansen stadig kan nå Frostmoln udgående. Egne images dækker begge dele fuldt ud, herunder hvad et afmagret image typisk mangler.

Begrænsninger

• Kun ved oprettelsen. Instansadgang kan hverken slås til eller fra på en eksisterende instans.
• Kun CLI og Terraform. Portalen kan ikke slå det til og tilbyder ingen terminal.
• Kun x86_64 Linux — agenten har brug for den arkitektur, systemd og cloud-init.
• Ikke på startskabeloner eller skaleringsgrupper — ingen af dem bærer en indstilling for instansadgang, så instanser, de opretter, har aldrig en shell.
• 10 minutters inaktivitet, 1 time i alt pr. session, og et begrænset antal samtidige sessioner pr. instans.
• Ingen begrænsning pr. medlem eller pr. nøgle endnu (se ovenfor).

Relateret

• Compute / Instanser · Egne images
• API-nøgler · fm CLI · fm shell-reference