Instanstilgang
Åpne en interaktiv terminal på din egen instans med fm shell. Instansens agent ringer ut til Frostmoln og terminalen går over den forbindelsen, så denne veien trenger ingen offentlig IP, ingen åpen port, ingenting som lytter på instansen og ingen nøkkel fra deg — og den åpner ingen inngående vei inn.
Det er ikke SSH: den bruker ikke port 22, ingen nøkkel er involvert, og det er ingenting for deg å åpne i en sikkerhetsgruppe — derfor heter kommandoen fm shell og ikke fm ssh (både fm ssh og fm session virker fortsatt som alias). Dette endrer ingenting ved selve instansen: det den lytter på, lytter den fortsatt på, og SSH til din egen instans er uendret og fullt støttet. Instanstilgang er en tilleggsvei inn, nyttig nettopp når SSH ikke er det: en instans uten offentlig IP, en sikkerhetsgruppe som stenger deg ute, en nøkkel du ikke har lenger.
Den velges når instansen opprettes
Den kan ikke legges til på en eksisterende instans
En instans kan bare nås på denne måten hvis den ble opprettet med instanstilgang slått på. Agenten henter identiteten sin fra instansen ved første oppstart, og det finnes ingen vei til å registrere en instans som allerede kjører. For å gi en eksisterende instans en terminal må du opprette den på nytt.
Slå det på når instansen opprettes, fra CLI eller fra Terraform. Portalens opprettelsesskjema tilbyr det ikke ennå.
fm compute instance create \
--name web-1 \
--image <image-id> \
--flavor gp1.small \
--instance-accessresource "frostmoln_instance" "web" {
name = "web-1"
instance_access = true
# ...
}I Terraform kan instance_access bare settes ved opprettelsen. Å endre hvorvidt agenten installeres tvinger fram en erstatning (false og usatt betyr begge ingen agent, så å gå mellom de to gjør det ikke). API-et returnerer det ikke og terraform import lar det stå usatt, så instance_access = true på en importert instans planlegger en erstatning.
Avbildet må kunne kjøre agenten, og instansen må fortsette å nå Frostmoln utgående så lenge du vil ha en terminal. Plattformens avbilder gjør allerede begge deler. Starter du ditt eget avbilde, se Egne avbilder for hva installasjonen trenger, og for de to måtene registreringen svikter stille på.
Instanstilgang finnes bare for x86_64-Linux: agenten trenger den arkitekturen samt systemd og cloud-init, så Windows-instanser kan ikke bruke den. Nå dem via konsollet i stedet.
Åpne en terminal
fm shell 9b6b2d0e-1f4c-4a7e-9c3d-2b8f5e6a1d04Argumentet er instansens id, ikke navnet. Skriv starten på en av delene, så fyller tab-fullføring inn id-en.
Legg en kommando etter -- for å kjøre den i stedet for å åpne en terminal:
fm shell 9b6b2d0e-... -- systemctl is-active nginxDen formen er skriptsikker — utdata linjeskiftmangles ikke, og kommandoens egen sluttkode blir sluttkoden til fm. Én ting å vite ved omdirigering: kommandoens stdout og stderr kommer sammenslått på fms stdout, så fm shell … -- cmd > out.txt fanger begge. Legg til --tty hvis du likevel trenger en terminal.
Hvilken bruker du blir
Du havner som avbildets standardbruker — debian på Debian, ubuntu på Ubuntu, og så videre. På plattformens avbilder er det den samme brukeren SSH gir deg. Logg inn som en annen med --user:
fm shell 9b6b2d0e-... --user deployEt eget avbilde uten brukbar standardbruker gir deg en root-terminal
Innloggingsbrukeren utledes fra avbildet når instansen opprettes, og hver måte den utledningen kan svikte på, lander deg på root i stedet — stille. Den svikter når avbildet ikke oppgir noen standardbruker, når distribusjonen ikke er en plattformen kjenner igjen, og når navnet det oppgir ikke kan brukes som innloggingskonto. Det siste er fella: et navn med store bokstaver, som MyUser, godtas når du laster opp avbildet og vises som innloggingsbruker, men økten kjører likevel som root.
Vil du ikke ha en root-terminal, gi avbildet en standardbruker skrevet med små bokstaver før du oppretter instanser fra det, og sjekk hvilken bruker du faktisk havner som første gang.
Økter er tidsbegrensede
En økt avsluttes etter 10 minutter uten aktivitet, eller 1 time totalt, det som inntreffer først. Status 255 betyr at økten døde — en grense, et brudd i forbindelsen, eller at fm selv ble drept. Klarer ikke fm å åpne økten i det hele tatt, avslutter det med 1 og en melding på stderr. Enhver annen sluttkode er din egen kommandos.
Hva som styrer tilgangen
- Din egen organisasjons instanser. Du kan åpne en terminal på instanser i de tenantene organisasjonen din eier. Alt annet er ikke funnet — samme svar enten instansen ikke finnes eller ikke er din.
- Bare der du slo det på. Instanstilgang gjelder per instans og velges ved opprettelsen. En instans som ble opprettet uten den, kan ikke nås på denne måten i det hele tatt, av noen.
- Tidsbegrenset. Ingen økt holdes åpen i det uendelige.
Ingen begrensning per medlem ennå — og en tenant er ikke et gjerde
Ethvert aktivt medlem av organisasjonen din kan åpne en terminal på enhver instans med instanstilgang slått på, uansett rolle, og i hvilken som helst av tenantene organisasjonen din eier — ikke bare den de vanligvis jobber i. Se derfor ikke på en egen tenant som en tilgangsgrense her: å legge en sensitiv arbeidslast i sin egen tenant holder ikke de andre medlemmene dine ute av den. Enhver API-nøkkel i den tenanten kan også åpne en økt.
Ingen innstilling snevrer dette inn til bestemte personer, og ingen tilgangspolicy gjerder det inne heller.
Inntil noe gjør det, er valget ved opprettelsen grensen: la instanstilgang være av på de instansene der det betyr noe, og nå dem over SSH, der du bestemmer hvem som har en nøkkel.
Spesielt for API-nøkler er sessions:pty tilgangen som kommer til å avgrense dette, og ingenting annet trer i stedet for den — verken compute:* eller et jokertegn, som en nøkkel ikke får ha. Gi den nå til nøkler som kjører fm shell, så de allerede er riktige. Men stol ikke på den som grense ennå: den sjekkes ikke når en økt åpnes, så i dag åpner en nøkkel uten den likevel en. Se API-nøkler.
Hva det legger på instansen
Verdt å vite før du slår det på, for det er din maskin:
- Agenten kjører som
root, og bevisst uten den sandkassingen plattformen bruker på sine egne administrerte instanser — den må kunne starte en terminal som hvilken som helst bruker du ber om. - Identitetsopplysningen dens er lesbar for enhver prosess på instansen, samme posisjon som en instansrolle-legitimasjon hos andre skyer.
- Et øyeblikksbilde eller avbilde av en registrert instans bærer med seg den identiteten, og noe gjenopprettet fra det kan opptre som originalen. Behandle et avbilde tatt fra en registrert instans som sensitivt, og bygg heller avbilder fra instanser som aldri har hatt instanstilgang slått på.
- Økter oppretter ingen innloggingspost, så
who,lastogutmpviser dem ikke. Revider inne i instansen hvis du trenger et spor.
Når det ikke virker
Hva fm sier til deg | Hva du gjør |
|---|---|
| instance not found or instance access not enabled | Id-en er feil, instansen hører ikke til denne tenanten, eller den ble opprettet uten instanstilgang. På en nyopprettet instans kan agenten fortsatt holde på å installeres. |
| this instance can't do terminal sessions | Instansen har en agent, men ikke en som betjener terminaler. fm foreslår også å oppdatere agenten; det finnes ennå ingen oppdateringsvei, så å opprette på nytt er eneste rute. |
| the instance's agent is offline | Instansen er stoppet, starter fortsatt, eller har mistet den utgående veien sin til Frostmoln. Prøv igjen om litt. |
| the instance agent is up and at its session limit | For mange økter er åpne på instansen samtidig. Lukk en — å bare prøve igjen hjelper ikke. Vedvarer det når du ikke har noen åpne, kontakt support. |
| session ended by the platform | Grensen for inaktivitet eller total tid gikk ut, eller forbindelsen falt. Åpne en ny økt. |
Hvis en helt ny instans aldri godtar en økt, sviktet registreringen: på instansen oppgir /var/log/frostmoln-managed-agent-install.log og /var/log/cloud-init-output.log årsaken. Virket det og sluttet så, sjekk at instansen fortsatt når Frostmoln utgående. Egne avbilder dekker begge i sin helhet, inkludert hva et nedstrippet avbilde vanligvis mangler.
Begrensninger
- Bare ved opprettelsen. Instanstilgang kan verken slås på eller av på en eksisterende instans.
- Bare CLI og Terraform. Portalen kan ikke slå det på og tilbyr ingen terminal.
- Bare
x86_64-Linux — agenten trenger den arkitekturen,systemdogcloud-init. - Ikke på oppstartsmaler eller skaleringsgrupper — ingen av dem har en innstilling for instanstilgang, så instanser de oppretter får aldri en terminal.
- 10 minutter inaktiv, 1 time totalt per økt, og et begrenset antall samtidige økter per instans.
- Ennå ingen begrensning per medlem eller per nøkkel (se over).