Hogyan állíthatunk be SSH és Git konfigurációkat a biztonságos távoli eléréshez és verziókezeléshez?

A távoli rendszerek biztonságos elérésére és a fejlesztési projektek hatékony kezelésére elengedhetetlen a megfelelő SSH (Secure Shell) és Git konfigurációk alkalmazása. Az alábbiakban bemutatott lépések segítenek abban, hogy könnyedén navigálhassunk a hálózaton, távoli rendszerekhez csatlakozhassunk, valamint verziókezelési megoldásokat alkalmazhassunk fejlesztési munkafolyamataink során.

ruby
Copy code
$ ssh user@ip_address

Ebben az esetben a rendszer a megfelelő felhasználót fogja használni az SSH kapcsolathoz. Ha nem konfiguráltuk előre az SSH fájlt, akkor egy egyszerű parancs is működhet, például:

ruby
Copy code
$ ssh -i ~/.ssh/my_private_key user@192.168.2.20

Ezután az SSH kulcsokat és egyéb biztonsági beállításokat a konfigurációs fájlban kell meghatározni, hogy a távoli elérés mindig zökkenőmentesen történjen. A biztonsági alapelvek betartása elengedhetetlen: az SSH kulcsok alkalmazása, a távoli root belépés letiltása, valamint a kapcsolat próbálkozások számának korlátozása mind hozzájárulnak a rendszer védelméhez.

A Git működésének alapjai az alábbiak szerint alakulnak. Először is, a projektet egy távoli tárolóba helyezzük, amely bárhonnan elérhető. A helyi gépen a projekt másolatát a git clone parancs segítségével hozhatjuk létre. Ezután új ágat hozhatunk létre a helyi tárolóban, amelyen dolgozhatunk anélkül, hogy befolyásolnánk a fő ágat, az ún. main ágat.

Miután befejeztük a módosításokat, a következő lépés, hogy a fájlokat rögzítjük (commit), majd feltöltjük a távoli tárolóba a git push parancs segítségével. Ezáltal a módosításaink elérhetővé válnak a többi fejlesztő számára, akik szintén hozzáférhetnek a legfrissebb verziókhoz. Az új ágak kezelése és a pull requestek használata segít abban, hogy minden változtatás megfelelően átnézhető és validálható legyen.

A Git konfigurálása is kulcsfontosságú. Ehhez a következő globális beállításokat kell elvégezni:

csharp
Copy code
$ git config --global user.email "[email protected]"

$ git config --global user.name "your-username"
$ git config --global init.defaultBranch main

Ezután SSH kulcsot kell beállítani a GitHub vagy GitLab fiókhoz, hogy biztosítani tudjuk a biztonságos kommunikációt a távoli tárolóval. Ezt az SSH konfigurációs fájl módosításával érhetjük el, amely az alábbiakat tartalmazza:

bash
Copy code
Host github.com
    PreferredAuthentications publickey
    IdentityFile ~/.ssh/my_private_key
Host gitlab.com
    PreferredAuthentications publickey
    IdentityFile ~/.ssh/my_private_key

Ezekkel a beállításokkal egyszerűsíthetjük a parancsokat, mivel nem kell minden alkalommal megadnunk a felhasználónevet és jelszót.

A Git és SSH beállítások után érdemes egy projects könyvtárat létrehozni, hogy rendezetten tároljuk a fejlesztési projekteket. Ehhez használhatjuk a következő parancsokat:

shell
Copy code
$ mkdir ~/projects

$ cd ~/projects

Ezáltal biztosíthatjuk, hogy minden projekt egy központi helyen, könnyen elérhető módon lesz tárolva.

Fontos megjegyezni, hogy a verziókezelés és a biztonságos távoli elérés nem csupán az egyes fejlesztők számára hasznos. Egy jól konfigurált rendszer segíthet abban, hogy a csapatok együttműködése zökkenőmentes legyen, és hogy a munkafolyamatok biztonságosak és követhetőek maradjanak. Az SSH és Git megfelelő beállítása kulcsfontosságú lépése a hatékony fejlesztési és üzemeltetési munkák végzésének.

Hogyan kezeljük a divergens Git ágakat és a távoli repóval való szinkronizációt?

Tegyük fel, hogy dolgozol egy lokális Git ágban, és próbálkozol a változások feltöltésével a távoli repóba. Az alábbi parancsokat használva próbálkozol az összes változtatás feltöltésével:

pgsql
Copy code
$ git push
! [rejected]        main -> main (fetch first)

error: failed to push some refs to 'github.com:bonifield/test.git'

Ez a hibaüzenet azt jelzi, hogy a távoli ágon már vannak olyan változások, amelyek még nem szerepelnek a lokális másolatban. Ez azt jelenti, hogy a helyi fő ág (main) elavult, és tartalmaz olyan fájlokat, amelyek még nem kerültek szinkronizálásra a távoli repóval. Ezt a problémát az okozhatja, hogy valaki más változtatásokat végzett a repóban, és azok nincsenek jelen a te lokális verziódban.

Az ilyen hibák elkerülése érdekében mindig érdemes először a távoli repó legfrissebb verzióját letölteni a következő paranccsal:

ruby
Copy code
$ git pull origin main

Ez a parancs letölti a távoli repó legfrissebb változásait, de előfordulhat, hogy újabb hibaüzenetet kapunk, amely arra figyelmeztet, hogy a helyi és távoli ágak eltérnek egymástól:

vbnet
Copy code
fatal: Need to specify how to reconcile divergent branches.

Ez azt jelenti, hogy a Git nem tudja automatikusan egyesíteni a két ágat, mivel azok már eltértek. Ebben az esetben két lehetséges megoldás van:

1. Rebase alkalmazása: A rebase lehetővé teszi, hogy az új változtatásokat a meglévő változtatások alá rendezd. Ezzel biztosítható, hogy az új kódok a legfrissebb állapotban maradnak. A következő parancsot használhatod:

lua
Copy code
$ git pull --rebase

Ez a parancs letölti a távoli változásokat, és egyesíti azokat a helyi ágaddal úgy, hogy a helyi módosításokat nem írja felül. Miután a rebase sikeresen befejeződött, ellenőrizheted a státuszt a következő paranccsal:

lua
Copy code
$ git status

Ha minden rendben van, akkor a következő paranccsal feltöltheted a változtatásokat a távoli repóba:

perl
Copy code
$ git push

2. Hard reset alkalmazása: Ha biztos vagy benne, hogy a helyi változtatások nem szükségesek, és szeretnéd, hogy a távoli repó teljesen felülírja a helyi változatot, használhatsz hard resetet. Ez a művelet visszaállítja a helyi repót a távoli verzióra, és törli az összes helyi változtatást.

shell
Copy code
$ git reset --hard origin/main

Ez a parancs törli az összes olyan változtatást, amelyet a helyi gépen végeztél, és szinkronizálja a repót a távoli verzióval.

Ezek után a kódot újra feltöltheted a következő parancsokkal:

shell
Copy code
$ git merge test
$ git push

A merge parancs összefűzi a tesztág változtatásait a fő ágba, és végül sikeresen feltöltheted a módosításokat a távoli repóba.

A változások ideiglenes eltárolása

Ha például hozzáadsz egy új fájlt a projektedhez, de nem akarod azt commitolni, használhatod a következő parancsokat:

ruby
Copy code
$ git stash

Ez ideiglenesen eltárolja a változtatásokat, és lehetővé teszi, hogy más módosításokat végezz anélkül, hogy a félbehagyott munkát el kellene dobni. Miután elvégezted a szükséges javításokat és feltöltötted őket, a változtatásokat visszaállíthatod a következő paranccsal:

perl
Copy code
$ git stash pop

Ezzel visszaállíthatod az eltárolt fájlokat, és folytathatod a munkát ott, ahol abbahagytad.

A tesztág törlése

Miután a módosításokat sikeresen feltöltötted a fő ágba, a tesztágat törölheted, ha már nincs rá szükség. A következő parancs törli a tesztágat:

shell
Copy code
$ git branch -D test

Ez a művelet nem befolyásolja a már feltöltött változtatásokat, de tisztítja a helyi környezetet. A fejlesztés befejeződött, de mindig tartsd észben, hogy bármikor újra változtathat valaki a repón, így a következő szinkronizáció már új problémákat hozhat.

Mi még fontos, amit érdemes megérteni?

Emellett mindig fontos a git status és a git log használata, hogy tisztában legyünk a változtatásokkal, és lássuk, milyen fájlok lettek módosítva vagy hozzáadva a verzióba. A rendszeres mentés és a helyes szinkronizáció megakadályozza a nagyobb problémákat, így a munka folyamatos és zökkenőmentes maradhat.

Hogyan telepíthetjük és konfigurálhatjuk az Elastic Agent-et és a Fleet-et a Kibana segítségével?

css
Copy code
[ ] Szolgáltatás elindítva
[7s] Elastic Agent sikeresen telepítve, regisztráció elindítva.
--snip--
Sikeres regisztráció az Elastic Agent-en.
--snip--
[=== ] Kész
[17s] Az Elastic Agent sikeresen telepítve.

Amennyiben a telepítés valami oknál fogva meghiúsul, az ügynök telepítője eltávolítja az összes fájlt az /opt/Elastic/ könyvtárból, így újra létre kell hozni a certs almappát, és újra le kell tölteni a TLS fájlokat.

A Kibana felületén a 6. lépésnél a státusz zöldre vált, és „Fleet Server connected” üzenetet kell látnunk. Ha frissítjük a Fleet oldalt, az új szerver is megjelenik, valamint annak CPU- és memóriahasználata is láthatóvá válik.

shell
Copy code
$ mkdir -p /opt/Elastic/Agent/certs/
$ cd /opt/Elastic/Agent/certs/
$ wget 192.168.8.133:8080/tls/certs/wildcard.local.flex.cert.pem
$ wget 192.168.8.133:8080/tls/keys/wildcard.local.flex.key.nopass.pem
$ wget 192.168.8.133:8080/tls/certs/ca-chain.cert.pem
$ chmod 0640 *

Ezután a Kibana felületén navigáljunk a Fleet menübe, és kattintsunk az "Add agent" gombra. Az első lépésnél hagyjuk az "Agent policy 1" beállítást, és kattintsunk a „Create policy” gombra. A második lépésnél az "Enroll in Fleet" opciót hagyjuk engedélyezve, majd folytassuk a telepítést. A harmadik lépésben további telepítési parancsokat láthatunk az Elastic Agenthez, és ami még fontosabb, az ügynök regisztrációs tokenjét, amely engedélyezi az ügynök számára a Fleet-be való csatlakozást; ezt ideiglenesen másoljuk el.

A telepítéshez töltsük le és csomagoljuk ki az Elastic Agent tarball fájlt, majd az alábbi parancsokat futtassuk:

ruby
Copy code
$ curl -L -O https://artifacts.elastic.co/downloads/beats/elastic-agent/elastic-agent-X.YY.Z-linux-x86_64.tar.gz

$ tar xzvf elastic-agent-X.YY.Z-linux-x86_64.tar.gz
$ cd elastic-agent-X.YY.Z-linux-x86_64

A root terminálban vagy sudo használatával futtassuk az alábbi parancsot az ügynök telepítéséhez:

shell
Copy code
$ ./elastic-agent install \
   --force \
   --url=https://fleet.local:8220 \
   --enrollment-token=ZUVrVWt... \
   --elastic-agent-cert=/opt/Elastic/Agent/certs/wildcard.local.flex.cert.pem \
   --elastic-agent-cert-key=/opt/Elastic/Agent/certs/wildcard.local.flex.key.nopass.pem \
   --certificate-authorities=/opt/Elastic/Agent/certs/ca-chain.cert.pem

A sikeres telepítést követően a Kibana felületén a negyedik lépés zöldre vált, és az „Agent enrollment confirmed” üzenet jelenik meg. Ezzel most egy teljes Elasticsearch, Kibana, Fleet és Elastic Agent szoftvercsomagot telepítettünk.

A Kibana Discover funkcióján keresztül az események megtekintése egyszerű: itt láthatjuk az egyes hostok és hálózati eszközök eseményeit. Az Elasticsearch rendszeres eseményei és az Elastic Agent-ek által generált események fognak megjelenni.

A Kibana-ban történő kereséshez használjuk a field:value szintaxist. Például, ha a source.ip:192.168.8.130 keresőt használjuk, az összes olyan eseményt találhatjuk, amelyek a megadott IP címről származnak.

Integrációk használata is elérhető az Elastic Agent-ben, amelyek segítségével adatokat gyűjthetünk a különböző technológiákból, mint például felhőszolgáltatások, routerek, kapcsolók és host szintű hálózati metadokumentációk. A különböző integrációk lehetővé teszik, hogy az ügynökök számos technológiához csatlakozzanak, például a Packetbeat használatával a hálózati forgalmat is figyelhetjük.

Az integrációs lehetőségek bővítése és az egyéni konfigurációk alkalmazása révén az Elastic Agent képes egyedi adatgyűjtési igények kielégítésére is.

Hogyan állítsunk be TLS-t és konfiguráljuk a Kafka-t biztonságos környezetben

A Kafka telepítése és konfigurálása számos lépést igényel, különösen akkor, ha biztonságos kapcsolatokra van szükség a broker-ek és a kliensek között. A következőkben bemutatjuk a TLS (Transport Layer Security) alkalmazásának folyamatát és annak beállítását Kafka környezetben, hogy a rendszer megfelelően titkosítva és védve legyen.

Első lépésként töltsük le a Kafka bináris csomagot az Apache hivatalos weboldaláról, a legfrissebb Scala verzióval. A csomag letöltése után kicsomagoljuk azt a /opt/kafka mappába. A letöltéshez használhatjuk a wget parancsot:

bash
Copy code
$ wget https://downloads.apache.org/kafka/VERSION/kafka_VERSION.tgz

$ tar -xzf kafka_X.XX-Y.Y.Y.tgz --strip 1 -C /opt/kafka/

A Kafka fájlok előkészítése után következik a TLS tanúsítványok létrehozása. Mivel a Kafka kliens kapcsolatok fogadását és közvetítését végzi a broker-ek között, szükség van TLS titkosításra, hogy biztosítsuk a kommunikáció biztonságát. Minden Kafka node-hoz létre kell hozni egy saját tanúsítványt és kulcsot.

A következő lépésben készítsünk egy PKCS#12 (P12) fájlt minden egyes node-hoz, amely tartalmazza a privát kulcsot és a tanúsítványt. Például:

bash
Copy code
$ openssl pkcs12 -export -inkey tls/keys/kafka01.local.flex.key.pem -in tls/certs/kafka01.local.flex.cert.pem -out tls/certs/kafka01.local.flex.pkcs12

Ezután a PKCS#12 fájlokat importáljuk egy új JKS fájlba:

bash
Copy code
$ keytool -importkeystore -srckeystore tls/certs/kafka01.local.flex.pkcs12 -srcstoretype pkcs12 -destkeystore tls/certs/kafka01.local.keystore.jks

Ezután a truststore fájlokat kell létrehozni, amelyek a CA (Certificate Authority) láncot tartalmazzák. Az egész Kafka cluster számára csak egy ilyen fájlra van szükség, amelyet minden egyes node-ra másolunk. A következő parancs segítségével importálhatjuk a CA láncot a truststore-ba:

bash
Copy code
$ keytool -keystore tls/certs/truststore.jks -alias CAChain -import -file tls/certs/ca-chain.cert.pem

A TLS fájlokat az összes node-ra másolhatjuk egy egyszerű Python web szerver segítségével:

bash
Copy code
$ python3 -m http.server 8000

Ezután a következő parancsokkal letölthetjük a fájlokat minden egyes broker node-ra:

bash
Copy code
$ wget 192.168.8.133:8000/certs/kafka01.local.keystore.jks -P /opt/kafka/certs/

$ wget 192.168.8.133:8000/certs/truststore.jks -P /opt/kafka/certs/

A Kafka konfigurálása során két fájlt kell módosítanunk: a server.properties fájlt, valamint szükség szerint a broker.properties és controller.properties fájlokat, amelyek a különböző szerepeket (broker és controller) konfigurálják a clusterben.

A server.properties fájlban kezdjük a következő alapbeállítások hozzáadásával:

properties
Copy code
node.id=211

process.roles=broker,controller
bootstrap.servers=SSL://kafka01:9094,SSL://kafka02:9094
log.dirs=/data/kafka

A node.id az egyes node-ok azonosítója, amelyet minden egyes node-ra egyedileg kell beállítani. A process.roles beállításban megadjuk, hogy a node egyszerre broker és controller szerepet is betölt. A bootstrap.servers sorban megadjuk a node-ok címét, amelyet a cluster csatlakozásakor használnak.

Ezután állítsuk be a Kafka listener-eket, amelyek meghatározzák, hogy mely portokon kommunikálnak a broker-ek és a kliensek. A következő beállításokkal biztosíthatjuk a TLS titkosítást:

properties
Copy code
listeners=CONTROLLER://kafka01.internal:9093,SSL://kafka01.local:9094

advertised.listeners=SSL://kafka01.local:9094
inter.broker.listener.name=SSL
listener.security.protocol.map=CONTROLLER:SSL,SSL:SSL

Az advertised.listeners beállítás biztosítja, hogy a kliensek és broker-ek is a megfelelő porton és titkosítással kapcsolódjanak egymáshoz. Az inter.broker.listener.name beállítja, hogy a broker-ek közötti kommunikáció is SSL-en keresztül történjen.

A TLS és SSL beállítások megfelelő alkalmazása kulcsfontosságú a Kafka környezet biztonságos működéséhez, és lehetővé teszi, hogy a rendszer minden egyes kommunikációja titkosítva legyen, ezzel biztosítva a magas szintű adatvédelmet.

Hogyan állítsuk be a Kafka TLS-kapcsolatait és konfiguráljuk a klustert

A Kafka konfigurálása és működtetése több szintű technikai döntéseket igényel, különösen a biztonságos kommunikáció biztosítása érdekében. Az egyik legfontosabb aspektus ennek a beállításnak a TLS (Transport Layer Security) használata, amely lehetővé teszi a broker-ek közötti titkosított adatátvitelt, és biztosítja az adatok védelmét a különböző szerverek közötti hálózati kommunikáció során. Az alábbiakban részletesen bemutatjuk, hogyan kell konfigurálni és beállítani a TLS-t a Kafka környezetben, különös figyelmet fordítva a broker-ek és a kliensek közötti biztonságos kapcsolat létrehozására.

A konfigurálás első lépése, hogy biztosítsuk: minden broker számára rendelkezésre állnak a megfelelő hostname és hostname.local bejegyzések a megfelelő /etc/hosts fájlokban. Ahogy a könyvben eddig bemutattuk, minden tanúsítványban szerepelniük kell a hostname és hostname.local bejegyzéseknek, miközben a /etc/hosts vagy DNS bejegyzések a megfelelő 10.x IP-címekre kell hogy irányítsák a kafka01 és kafka02 broker-eket. Az egyes broker-ek frissítésekor fontos, hogy mindkét listener beállításban frissítsük a hostneveket. A controller lista vesszővel elválasztott formátumban szerepel, például: controller.quorum.voters=211@kafka01:9093,212@kafka02:9093. Ezt követően győződjünk meg arról, hogy minden controller rendelkezik a megfelelő TLS beállításokkal. Az inter.broker.listener.name beállítás használatával most már a controller-kapcsolók számára is szükséges megadni a megfelelő listener-t.

A TLS fájlok beállításának konfigurálása nem bonyolult, de pontosan kell eljárni. Az ssl.keystore.location és ssl.truststore.location bejegyzéseknél meg kell adni a kulcsok és a tanúsítványok elérési útját. Az ssl.keystore.password és ssl.key.password beállítások a titkos kulcsokhoz szükséges jelszavakat tartalmazzák, míg az ssl.truststore.password biztosítja a megbízható tanúsítványok elérését. Az ssl.client.auth=required beállítás biztosítja a kölcsönös TLS (mTLS) használatát, amely egy kritikus biztonsági elem, hiszen ez lehetővé teszi a kétoldalú hitelesítést a kliensek és broker-ek között.

A következő lépés a Kafka témák viselkedésének meghatározása. A log.message.timestamp.type=LogAppendTime beállítással lehetőségünk van arra, hogy a Kafka az üzeneteket ne az események dátuma és időpontja alapján, hanem annak alapján tartja meg, hogy mennyi ideje van egy üzenet a logban. Ez elengedhetetlen, mivel különben előfordulhatna, hogy Kafka automatikusan törli a régi adatokat, ha azok egy nem várt időpontból származnak. Ezen kívül fontos, hogy a topic-ok törlése engedélyezve legyen, miközben a dinamikus topic-képzés le van tiltva.

A Kafka konfigurációban számos további alapbeállítás szerepel, például a num.partitions=1, amely az új topic-ok esetében csak egy partíciót hoz létre alapértelmezettként. Ezen kívül beállítható a logok megtartásának időtartama is: a log.retention.hours=168 azt jelenti, hogy az üzenetek egy hétig lesznek megtartva. Ezen paraméterek finomhangolásával szabályozhatjuk, hogy a Kafka hogyan kezelje az adatokat és a logokat.

A következő lépés a csatlakozási beállítások megadása, különösen a TLS/SSL kapcsolatot biztosító fájlok létrehozása és konfigurálása. A /opt/kafka/config/client-ssl.properties fájl tartalmazza a minimum szükséges SSL beállításokat, például a bootstrap.servers=SSL://kafka01.local:9094,SSL://kafka02.local:9094 sort, ami biztosítja, hogy a Kafka kliensek a megfelelő TLS-kapcsolaton keresztül kommunikáljanak a broker-ekkel.

A Kafka cluster felállításának egyik alapvető lépése a szolgáltatás indítása. Az új szolgáltatást a systemd segítségével indítjuk el, amely biztosítja, hogy a Kafka folyamatok megfelelően futnak és leállnak, ha szükséges. A megfelelő rendszerkonfiguráció biztosítja, hogy a Kafka cluster folyamatosan működjön, amíg azt manuálisan le nem állítják.

Végül, ha a disk használat gyors növekedését tapasztaljuk, akkor számos konfigurációs beállítást kell finomhangolni, például a log.retention.hours értékét, hogy elkerüljük a nem kívánt adatvesztést. Emellett fontos a hálózati kapcsolat és a címek megfelelő ellenőrzése, hogy a broker-ek közötti kommunikáció biztonságosan működjön.