A Lightsail egyik legnagyobb hátránya az EC2-vel szemben az, hogy nem lehet könnyen megváltoztatni a példány típusát. Jelenleg nincs egy kattintással elérhető lehetőség arra, hogy 512 MB memóriakészletről 1 GB memóriakészletre váltsunk. Az AWS tisztában van ezzel a problémával, és dolgozik egy olyan megoldáson, amely lehetővé teszi, hogy a jövőben nagyobb csomagra váltsunk. Addig is a nehezebb úton kell ezt megtennünk.

Hogyan kaphatok 1 vCPU-t ingyen?

Korábban az olcsóbb Lightsail csomagokat csak 1 vCPU-t kínálták. Ez azért volt így, mert az alapul szolgáló t2 példányok 1 vCPU-s opciókkal rendelkeztek. Most, hogy az AWS Lightsail áttért az új t3-as példánycsaládra, már nincs 1 vCPU-s opció, csak 2 vCPU-s. Bár a motorháztető alatt történt változás, az AWS megtartotta a Lightsail árazását, így a t3-as példánycsaládra való áttéréskor egy további ingyenes vCPU-t kaphatunk.

Lightsail példány frissítése

A Lightsail példány frissítéséhez manuális pillanatképet kell készíteni. A Snapshots (pillanatképek) menüpontban kattintsunk a Create Snapshot (pillanatkép létrehozása) gombra, és adjunk egy nevet a pillanatképnek. A pillanatkép létrehozása időbe telik, ezért legyünk türelmesek, amíg a pillanatkép elkészül.

A pillanatkép létrehozása közben lépjünk a Netowking (hálózat) fülre, és ha van IPv4-címünk, mindenképpen kattintsunk a Create static IP (statikus IP létrehozása) gombra. Ez lehetővé teszi, hogy megtartsuk jelenlegi nyilvános IPv4 címünket. Sajnos az IPv6 cím megtartására nincs lehetőség, így később frissítenünk kell a DNS-beállításainkat.

Az IPv4 Firewall (tűzfal) alatt jegyezzük fel vagy készítsünk képernyőképet a tűzfalszabályainkról, mivel ezek sem kerülnek átvitelre. Ha van IPv6-os hálózatunk, ugyanezt tegyük meg ezekkel a szabályokkal is, mivel előfordulhat, hogy különböző IPv4-es és IPv6-os tűzfalszabályaink vannak.

Mostanra valószínűleg már elkészült a pillanatfelvétel. Válasszuk a bal oldali menüben a Snapshots (pillanatképek) menüpontot, és látni fogjuk az újonnan létrehozott pillanatképet. Kattintsunk a három pontra, és válasszuk a Create New Instance (új példány létrehozása) lehetőséget. Itt kiválaszthatunk egy IPv6 csomagot, ha nincs szükségünk nyilvános IPv4 címre, vagy az új 2vCPU opciókat. Csak egy korlátozás van. Nem választhatunk alacsonyabb csomagot mint, amellyel rendelkezünk.

Ne feledjük, hogy a Lightsail példányok nevei egyediek, így nem nevezhetjük el az új példányt ugyanúgy, mint az előző példányt (és nincs lehetőség a példány nevének jövőbeli megváltoztatására sem). Én www. címet adtam a példányom elé.

Most, hogy az új példány már működik, először válasszuk le az IPv4-címét a régi példányáról, és csatoljuk az újhoz. Adjuk meg a korábban elmentett tűzfalszabályait is.

Ne felejtsük el frissíteni a DNS beállításokat az új nyilvános IPv6 címmel. Állítsuk le a régi példányt, és teszteljük az újat.

Tisztogatás

Miután meggyőződtünk arról, hogy az új példány teljesen működőképes, elvégezhetjük a manuális tisztítást. Először menjünk a Snapshots (pillanatképek) menüpontba, és töröljük a frissítéshez létrehozott pillanatképet. Az AWS 0,05 USD GB/hónap díjat számít fel a pillanatképekért, így ha nincs rá szükségünk, egyszerűen töröljük. A régi példányt is manuálisan törölnünk kell.

Az Amazon Lightsail a legegyszerűbb módja az AWS-sel való kezdésnek, a példányok bővítése ugyanakkor nem az. Amíg az AWS lefejleszti ezt a funkciót, addig a Lightsail példányainkat manuálisan tudjuk csak bővíteni.

A Amazon Lightsail példányok bővítése – további vCPU-t kaphatunk ingyen bejegyzés először Road to AWS-én jelent meg.

Láttam egy videót a YouTube-on arról, hogyan lehet a névjegykártyát egy egyszerű NFC matricával intelligenssé tenni. A probléma az, hogy bár a matricára be lehet programozni egy vCard-ot, az iOS készülékek még nem támogatják ezt a funkciót. Az egyetlen módja annak, hogy egy iPhone olvassa az NFC vCard-ot, hogy a vCard fájlt a weben tároljuk. Ekkor jutott eszembe. Miért ne lehetne a vCard-ot az AWS-en hosztolni, kizárólag ingyenes erőforrásokat használva.

A nyilvánvaló megoldás a Lambda és Lambda Function URL-ek voltak, mivel ezek teljesen ingyenesek. Ráadásul biztos lehetsz benne, hogy az AWS még 5 vagy 10 év múlva is létezni fog, így a digitális névjegykártyád még mindig működni fog.
Emellett nagyon könnyen frissíthetjük adatainkat, ha valami megváltozik, nem kell újat vásárolnunk. Ami a környezetnek is jót tesz!

A fejlesztés során olyan problémákba ütköztem, amelyek miatt extra házirendeket kellett létrehoznom, hogy működjön. Mivel a lehető legegyszerűbbé akartam tenni, hogy mindenki használhassa, létrehoztam egy CloudFormation sablont, amely létrehozza az összes erőforrást .
Ha pedig már nincs rá szükség, a CloudFormation képes törölni az összes felhasznált erőforrást. De miért is tennéd ezt, amikor ez teljesen ingyenes.

A kódot Node.js 18.x-ben írtam, és egy v. 3.0 vCardot készít. Megkérdezheted, hogy miért nem v. 4.0, és a válasz egyszerű. Az Apple nem támogatja, és én a lehető legkompatibilisebbé akartam tenni.
A másik probléma, amivel szembesültem, hogy a vCard specifikáció szerint egy kép URL-címét is összekapcsolhatjuk a fotónkkal, de az Apple készülékek ezt sem támogatják. A fényképnek Base64 kódolva kell lennie a vCard-ban.
Ezért a CloudFormation létrehoz egy S3 Bucket-et (tárolót), ahol tárolhatjuk a fényképet (avatar.jpeg), a Lambda függvény pedig Base64-be konvertálja, és beépíti a kártyájába.

Nem csak az Apple-nek, az AWS-nek is vannak furcsa dolgai. Például, amikor létrehozol egy FunctionURL-t a Lambda függvényhez, ez az URL nincs definiálva a Lambda környezeti változójában. Ahhoz, hogy megkapd a FunctionURL-t, a GetFunctionUrlConfig szerepkört kell engedélyezned a függvény URL-jének olvasásához. Mivel a vCard lehetővé teszi a vCard forrásának meghatározását, ahonnan mindig a legfrissebb verziót kapja meg, létre kellett hoznom egy házirendet, és azt a Lambda szerepkörhöz csatolnom, hogy a FunctionURL-t a vCard-ban szerepeltessem.

A másik probléma, amivel szembesültem, hogy bár a Lambda kódot a CloudFormation-be be lehet illeszteni, az index.mjs fájl helyett index.js fájlt hoz létre, ami Node.js 18.x-hez szükséges. Van megoldás arra, hogy a kódot egy S3 tárolóba helyezzük el, és a CloudFormation lekérdezi onnan a kódot, de akkor ottragadunk abban a régióban, ahol az S3 tároló van. Ezért létrehoztam két CloudFormation sablont .
Ha a legegyszerűbb telepítést szeretnénk, és nem akarjuk megváltoztatni a régiót, használjuk az alapértelmezett sablont. Ez az USA keleti részén (Észak-Virginia) fog futni. Ha a névjegykártyáját egy másik régióban szeretnénk elhelyezni, használjuk helyette a template-with-code.yaml-t, de a kód működéséhez az index.js állományt index.mjs-re kell átnevezni.

A teljes forráskód elérhető a GitHubon Apache 2.0 licenc alatt. Részletes telepítési információkért lásd a GitHub oldalt.
Használjuk a template.yaml fájlt, ha a legegyszerűbb telepítést szeretnénk.
Ha meg szeretnénk adni a régiót, amelyben az erőforrások létrejöjjenek, használjuk helyette a template-with-code.yaml, és nevezzeük át az index.js forrásfájlt index.mjs-re.

Remélem, hogy ez a kis kód olyan hasznos, mint amilyen szórakoztató volt megírni.

A Ingyenes és egyszerű csináld magad digitális névjegykártya bejegyzés először Road to AWS-én jelent meg.

A Mastodon-t választottam elsődleges platformnak, mert ez a legnépszerűbb az összes közül. Választhatsz mást is, mivel ezek a hálózatok zökkenőmentesen tudnak egymással kommunikálni, függetlenül attól, hogy milyen szervert futtatnak.

A Twitter (ma: X) kereskedelmi vállalatként jogosult korlátozni vagy kereskedelmi forgalomba hozni az API-ját, ami nehézséget jelenthet a startupok vagy kis fejlesztők számára. A Mastodon nemcsak ingyenes és nyílt forráskódú, hanem sokkal fejlesztőbarátabb is. Az egyik ilyen funkció a botfiókok támogatása. Ezek a fióktípusok nincsenek korlátozva, sőt, bátorítják a használatukat. A Mastodon-ban külön megjelölhetjük, hogy egy fiók bot-e, így mindenki számára átláthatóbbá válik.

Az első lépés mindig a legnehezebb, a Mastodon szerver kiválasztása. Rengeteg közül választhatunk, némelyik speciális közösségek számára van fenntartva, némelyik pedig földrajzilag korlátozott. Ha bizonytalan vagy, maradj a legrégebbi mellett: mastodon.social.

Hozzonunk létre egy fiókot itt, és jelöljük be a This is an automated account (ez egy automatizált fiók) négyzetet a profilunk alatt. Ez tudatja a többiekkel, hogy ez egy botfiók. Az Under Development (fejlesztés alatt) hozzunk létre egy új alkalmazást, és válasszuk ki a megfelelő jogosultságokat. Mivel az én botom csak publikálni fog, csak a write:statuses opciót választottam.

Egy korábbi blogbejegyzésemben létrehoztam egy honlapot a magyar techkonferenciáknak. Ezt fogom használni input forrásként. Jelenleg ez az oldal nem kínál egyszerű módot az információk exportálására, ezért módosítottam a Jekyll kódot, hogy CSV fájlt generáljon a közelgő eseményekről. Így könnyebben tudom felhasználni az adatokat.

A serverless megközelítés

A bejegyzés címéből valószínűleg kitaláltad, hogy serverless megközelítést fogok alkalmazni. Nem akarok biztonsági frissítésekkel és javításokkal foglalkozni. Csak azt szeretném, hogy ez a bot nagyon kevés karbantartással működjön.

Tipp: Válaszd az arm64-et Lambda architektúrát, mert annak olcsóbb a futtatása.

A Mastodonhoz egy maroknyi API kliens közül választhatunk. Mivel Node.js 18.x-et fogok használni, olyan klienst akartam találni, amely kompatibilis vele. A választásom a Masto.js-re esett, amelyet elég gyakran karbantartanak, és amely támogatja a Mastodon API legtöbb funkcióját.

A techconf.hu CSV-adatainak letöltéséhez az Axios-t fogom használni, mint a korábbi projektjeimben. A CSV adatok elemzésére a választásom a csv-pars-re esett (vigyázz, többféle CSV-parser létezik, egyes nevek csak kötőjellel különböznek egymástól). Ezután minden egyes funkcióhoz külön Layer-t hoztam létre, és csatoltam a Lambda függvényhez.

Az egészet működésre bírni

A kód nagyon egyszerű. Először letöltöm a CSV fájlt, és a csv-parse segítségével elemzem. Ezután beállítom a Tootot (a Mastodon kifejezése a Tweetre) és közzéteszem a Masto.js segítségével.

Az egyik probléma, amivel szembesültem, hogy a Mastodonban minden Tootnak van egy nyelvi változója. Ha nem állítod be külön, akkor a Mastodon fiókodban beállított nyelv lesz az alapértelmezett.

Tipp: Mivel a Fediverse annyira decentralizált, jó ötlet, ha minden hozzászólásodat megjelölöd.

import { parse } from 'csv-parse';
import { login } from 'masto';
import axios from 'axios';

export const handler = async(event) => {
    var tweet = "Upcoming Hungarian Tech Conferences 🇭🇺\n\n";
    var conferencesThisWeek = false;
    const currentDate = new Date();
    const endOfWeek = new Date(new Date().setDate(new Date().getDate() + 7));
    currentDate.setHours(0,0,0,0);
    endOfWeek.setHours(0,0,0,0);
    var conferenceDate;
    var csv;
    
    await axios({
        url: 'https://techconf.hu/conferences.csv',
        method: 'GET',
        responseType: 'blob'
    }).then((response) => {
        csv = response.data;
    });
    
    const parser = parse(csv, {
        delimiter: ",",
        from_line: 2
    });
    
    for await (const record of parser) {
        conferenceDate = new Date(record[3]);
        if (currentDate <= conferenceDate && conferenceDate <= endOfWeek) {
            tweet += '👉 ' +record[0] + ' (' + record[2] + ')\n📅 ' + record[3] + ' - ' + record[4] + '\n🔗 ' + record[1] + '\n\n';
            conferencesThisWeek = true;
        }
    }
    
    if (conferencesThisWeek) {
        tweet += '#Hungary #Technology #Conference';
        
        const masto = await login({
            url: 'https://mastodon.social/api/v1/',
            accessToken: ''
        });
    
        await masto.v1.statuses.create({
            status: tweet,
            visibility: 'public',
            language: 'en'
        });
    }
    
    // TODO implement
    const response = {
        statusCode: 200,
        body: JSON.stringify('Hello from Lambda!'),
    };
    return response;
};

Időzítés

A Lambda függvény ütemezésének legegyszerűbb módja az Amazon EventBridge Scheduler (ütemező) használata. Egyszerűen válasszuk ki az ütemezési mintát és a Lambda függvényt célként, és a megadott időpontban végrehajtja a kódot.

Végső gondolatok

Említettem már a legjobb részt? Mindez ingyen van. Az általam használt szolgáltatások mindegyike az AWS Free Tier (ingyenes) szolgáltatási körébe tartozik (jelen íráskor).

Nyugodtan hozzatok létre hasonló botokat, vagy segítsetek jobbá tenni a kódomat, vagy csak kövessétek a botomat a következő címen: https://mastodon.social/@techconf

A Serverless Mastodon bot bejegyzés először Road to AWS-én jelent meg.

Az alapok: S3 statikus weboldal hosting

Statikus webhely tárhelyet még soha nem volt ilyen egyszerű létrehozni. Az Amazon S3 statikus tárhelyszolgáltatással egyszerűen feltölthetjük statikus oldalainkat egy S3 tárolóba, és engedélyezhetjük a nyilvános hozzáférést (az S3 tárhelyet mindenképpen nevezzük el a domain nevének megfelelően). Az interneten rengeteg cikket találhatunk, amelyek elmagyarázzák, hogyan kell beállítani az S3 statikus tárhelyet, ezért itt nem fogok további részletekbe bocsátkozni.

De vannak korlátok: Az S3 nem támogatja a HTTPS-t, ami a weboldalak tárhelyének de facto minimum feltétele. A HTTPS használatához be kell állítani az Amazon CloudFrontot. Ez rengeteg extra funkcióval jár, mint például GeoIP-korlátozás, gyorsítótárazás és ingyenes SSL-tanúsítvány. Arról nem is beszélve, hogy végre letilthatjuk az S3 nyilvános hozzáférését (ami biztonsági kockázatot jelenthet), és korlátozott hozzáférést adhatunk csak a CloudFrontnak (egy S3 házirenddel).

Pro tipp: Adjuk hozzá a CloudFront ListBucket engedélyeket az S3 tároló házirendjéhez, különben az ügyfél nem fog HTTP státuszkódokat kapni, beleértve a 404-es kódot is, amikor nem létező tartalomhoz próbál hozzáférni:

Mishi

{
    "Version": "2008-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::roadtoaws.com",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::111111111111:distribution/AAAAAAAAAAAAA"
                }
            }
        },
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::roadtoaws.com/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::111111111111:distribution/AAAAAAAAAAAAA"
                }
            }
        }
    ]
}

A CloudFront gyorsítótárazása miatt nem ideális fejlesztéshez. Vagy helyben kell tesztelni a kódot, vagy a HTTPS engedélyezése nélkül. Ez a fő oka annak, hogy továbbra is jó lenne, ha az S3-ban is megjelenne a HTTPS-támogatás.

Legyen dinamikus

A statikus weboldalak már a múlté. Valószínűleg előbb-utóbb valamilyen dinamikus tartalomra lesz szükségünk. Bár sok olyan szolgáltatás létezik, amely olyan funkciókat biztosít, mint az e-mail küldés, a megjegyzések, amelyeket beilleszthetünk a statikus kódunkba, hogy dinamikussá tegye azt, valószínűleg saját kódot kell írniunk bizonyos funkciókhoz. Itt jönnek jól a Lambda Function URL-ek. Egy egyszerű Lambda függvénnyel kódot hajthatunk végre vagy más AWS-erőforrásokat használhatunk, amelyeket egy egyszerű HTTP-kérelemmel hívhatunk meg a böngésződben. De hogyan korlátozhatjuk ezt egy adott IP-re, tartományra vagy a CloudFrontra?

Az AWS az IAM-en keresztül történő hitelesítést ajánlja, és bár ez valóban biztonságos módszer, a fejlesztést kihívássá teszi. Az első dolog, amit láthatsz, az a CORS, ahol az eredetet egy tartományra állíthatod be. Sajnos ez nálam nem úgy működött, ahogy szerettem volna. Ez nem korlátozza a Lambdádat abban, hogy bármilyen IP-ről meg lehessen hívni. Itt beállíthatsz egy X-Custom fejlécet is, de ez sem igazán korlátozza a külső hozzáférést.

Ezután kerestem megfelelő IAM-engedélyeket, amelyeket a Lambda-funkciókhoz csatolhatok. A rendelkezésre álló házirendek között találtam az InvokeFunctionUrl-t, ahol hozzáadhatunk egy IP-címet, hogy a meghívást egy adott IP-re korlátozza. Ez remekül hangzik! Létrehozunk egy házirendet, és csatoljuk azt a Lambda Role-hoz. Sajnos ez sem korlátozza a Lambda hozzáférését.

Mi volt tehát a megoldásom?

1. Korlátozás kódban

Az első kézenfekvő megoldás a forrás IP-jének ellenőrzése a Lambda függvénnyel. Íme egy Node.js nyelvű mintakód (hasonló kódot más nyelvekhez is találhatsz az interneten):

const ipAddress = event.identity.sourceIP;

if (ipAddress === '52.84.106.111') {
  const error = {
      statusCode: 403,
      body: JSON.stringify('Access denied'),
  };
  
  return error;
} else {
  const hello = {
      statusCode: 200,
      body: JSON.stringify('Hello World!'),
  };
  
  return hello;
}

Bár ez nyilvánvalóan működik, extra kódot adsz hozzá egy olyan Lambda-funkcióhoz, amelynek elsődleges szerepe valami más elvégzése. Arról nem is beszélve, hogy ez növeli a futási időt és a Lambda által használt erőforrásokat. A legfontosabb, hogy hogyan lehetsz biztos abban, hogy a sourceIP változóban kapott IP valóban az az IP, ahonnan az ügyfél érkezik.

A legnagyobb gondom ezzel a megoldással az volt, hogy nem csak egy adott IP-re akartam korlátozni a funkcióimat, hanem az egész CloudFront disztribúcióra, így biztos lehetek benne, hogy az egyik statikus oldalamról hívják meg. Ezzel a módszerrel nagy gondot jelentene az összes CloudFront szerver naprakész listájának karbantartása.

2. reCAPTCHA

Igen, jól hallottad, Google reCAPTCHA. Ez elsőre furcsán hangozhat, de ez az a megoldás, amit én a munkám során megvalósítottam, és megoldást nyújt a fenti kihívásokra.

A reCAPTCHA kód beágyazása statikus weboldalakba jó ötlet. Valójában a Google azt javasolja, hogy a kódot minden oldalra építsük be – nem csak azokra, amelyeken szükség van rá, például az űrlapok érvényesítésére -, mert így az algoritmus hatékonyabban tudja felismerni a csalárd használatot. A lambda függvényen belül most már validálhatom, hogy a felhasználó valóban meghívta-e a statikus weboldalamról a lambda függvényem URL-címét. Íme a kód, amelyet a reCAPTCHA-kérés ellenőrzésére használok:

const gRecaptchaResponse = event.queryStringParameters["g-recaptcha-response"];
    
    var verificationUrl = "https://www.google.com/recaptcha/api/siteverify?secret=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA&response=" + gRecaptchaResponse;
    const recaptchaResult = await getRequest(verificationUrl);
    
    if (false == recaptchaResult.success || 0.5 > recaptchaResult.score) {
      return error;
    }

Végezetül

Az S3 statikus weboldal hosting a legegyszerűbb módja a serverless utazás megkezdésének. Bár vannak akadályok, mindig találhatsz serverless megoldást.

A AWS Lambda Function URL-ek korlátozása CloudFronthoz bejegyzés először Road to AWS-én jelent meg.

Az AWS Well-Architected Framework hat pillérből áll:

• Operational excellence (üzemletetés)
• Security (biztonság)
• Reliability (megbízhatóság)
• Performance efficiency (teljesítményhatékonyság)
• Cost optimization (költségoptimalizálás)
• Sustainability (fenntarthatóság)

Az AWS nemcsak képzést és dokumentációt biztosít az AWS Well-Architected Framework-höz, hanem a felhőinfrastruktúra felügyeletéhez szükséges eszközöket is biztosítja.

Ebben a blogbejegyzésben bemutatok egy módszert arra, hogyan tesztelhetjük felhőkörnyezetünket az AWS Well-Architected Framework biztonsági és megbízhatósági pilléreivel szemben.

A Security pillar (biztonsági pillér) az információk, rendszerek és eszközök védelmére összpontosít, miközben kockázatértékelések és migrációs stratégiák révén üzleti értéket teremt.
A Reliability pillar (megbízhatóság pillér) a meghibásodásokból való helyreállítási képességre és az igények kielégítésére összpontosít az alapokban, a munkaterhelés architektúrájában, a változások és a hibák kezelésében.

Beállítás

Az AWS Systems Manager a legjobb hely az AWS fiókunk működésének betekintéséhez. Itt a Quick Setup (gyorsbeállítás) oldalon kiválaszthatjuk a Conformance Packs (megfelelőségi csomagokat). De ne szaladjunk ennyire előre, hiszen előbb elő kell készítenünk a környezetünket. Enélkül a tesztek egy nem túl hasznos hibaüzenettel fognak elbukni.

A környezetünk előkészítéséhez engedélyeznünk kell a Config Recordingot. Ezt az AWS Config menüpontban és a 1-click setup kiválasztásával tudjuk engedélyezni. Ez az összes erőforrást rögzíti (kivéve a globális erőforrásokat), beállít egy AWS Config szerepet és létrehoz egy S3 tárolót. Ha finomhangolni szeretnénk, hogy mely erőforrásokat szeretnénk rögzíteni, válasszunk vagy hozzunk létre egy adott szerepet, vagy válasszunk egy adott S3 tárolót és válasszuk helyette a Get started (kezdjük el) lehetőséget. Miután engedélyeztük a rögzítést, visszatérhetünk a Systems Manager-be.

A Conformance Packs konfigurációs képernyőn kiválaszthatjuk, hogy az AWS Well-Architected Framework Reliability vagy Security pillérének vagy mindkettőnek a legjobb üzemeltetési gyakorlatai szerint szeretnénk-e ellenőrizni. Beütemezhetjük a konfiguráció futtatásának időpontját, és kiválaszthatjuk a régiót. A csomag telepítése után a tesztek futtatása általában néhány percet vesz igénybe.

Eredmények

Az AWS Config az AWS-szolgáltatások szerint csoportosítva mutatja az eredményeket.

Egy problémára kattintva részletes magyarázat jelenik meg.

Árazás

Az árképzés a megfelelőségi csomagok értékelésének számától függ. Bár az AWS jelenleg nem mutatja, hogy hány értékelés van az egyes pillérekben, nehéz pontos számot kapni futtatás nélkül a tényleges árra. Jó lenne, ha az AWS fix árazással rendelkezne az Operational Best Practices megfelelőségi csomagok esetében. Az AWS Config honlapján van egy árképzési példa, amely a teljes konfigurációs számlát mutatja be.

Összegzés

Az AWS Well-Architected Framework az AWS nagyszerű és egyedi terméke, amely megkülönbözteti magát más felhőszolgáltatóktól, és nem értem, miért nem szerepel még mindig az AWS Free Tier-ben. Egy egészséges felhőkörnyezet az AWS-nek és az ügyfélnek is jót tesz.

A Bevált módszerek az AWS jól architektúrált keretrendszerének megfelelően bejegyzés először Road to AWS-én jelent meg.

Az Apple viszonylag egyszerűvé tette a végfelhasználók számára az Intelről az Apple silicon-ra való átállást. A Rosetta 2 csodálatos munkát végez a kizárólag x86-64-alapú processzorokra fordított alkalmazások Apple silicon-on történő futtatásához. Mivel az Apple silicon már egy ideje forgalomban van, sok fejlesztő Apple silicon-ra fordított bináris programokat biztosít. Valójában egyre kevesebb olyan nagy cég van, amelyik nem kínál Apple silicon-os verziót az alkalmazásából. Ez az oka annak, hogy néhányan – köztük én is – soha nem telepítik a Rosettát. Így garantálhatom, hogy minden alkalmazásom az új processzorra van optimalizálva.

Az AWS dokumentációja szerint a CLI háromféleképpen telepíthető Mac számítógépre:

• GUI Installer (grafikus telepítő)
• Command line installer – All users (parancssori telepítő – minden felhasználó)
• Command line – Current user (parancssor – aktuális felhasználó)

A szomorú hír az, hogy ezek a módszerek mind ugyanazt a macOS pkg fájlt használják. Ez a telepítő ebben a fájlban még nincs optimalizálva az Apple silicon-ra, de a mellékelt binárisok igen. Ez azt jelenti, hogy a Rosettát kell telepíteni csak azért, hogy telepíteni tudjuk egy Apple silicon-os alkalmazást. Valóban furcsa. Szerencsére van egy másik megoldás, amit a hivatalos dokumentáció nem említ, Brew.

A Homebrew a macOS hiányzó csomagkezelője. Valószínűleg már használod, ha olyan alkalmazásokat szeretnél telepíteni, mint a wget vagy az mc. A telepítés egyszerű és egyszerű, csak futtasd a következő parancsot a terminálban.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Ezután futtasd ezt a két parancsot, hogy a Brew-t hozzáadd a PATH-hoz:

echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile
eval "$(/opt/homebrew/bin/brew shellenv)"

Az egyetlen hátránya a Brew-nak az, hogy adatokat küld a Google-nak. Erre figyelmeztet is, de nem mondja meg, hogyan lehet ezt kikapcsolni. Bár a Homebrew karbantartói azt mondják, hogy ezek az elemzések segítenek nekik a jövőbeli funkciókról való döntésben és a jelenlegi feladatok rangsorolásában – és azt ajánlják, hogy tartsuk bekapcsolva -, én még mindig nem vagyok a személyes adatok gyűjtésének híve, még ha névtelenül történik is ez. Ennek kikapcsolásához egyszerűen futtasd a következő parancsot:

brew analytics off

Most, hogy a Brew telepítve van, egyszerűen telepíthetjük az AWS CLI-t a következő parancs végrehajtásával:

brew install awscli

Voilá, az AWS CLI most már Rosetta nélkül telepítve van.

Meg kell jegyeznem, hogy ez a megoldás a cikk írásának idején volt szükséges, és az AWS valószínűleg javítani fogja a telepítőt, de addig csak használd a Brew-t.

A AWS CLI telepítése Apple silicon-ra bejegyzés először Road to AWS-én jelent meg.

Előnyök

Milyen előnyei vannak az AWS-re való áttérésnek?

Először is, globális lábnyoma van! Egy nagy tárhelyszolgáltatónak csak körülbelül 2-3 szerverterme van, ahol elhelyezhetjük a weboldalunkat. (A kicsiknek csak egy van). És nem mellesleg ezt a regisztráció során kell eldöntened, így életed végéig ezen a helyszínen lesz a weboldalad. Ezzel szemben az AWS-nél több tucatnyi helyszín (úgynevezett régió) közül választhatsz, és nem kell ragaszkodnod egyikhez sem. Lehet egy WordPress-oldalad Tokióban, egy másik pedig Szingapúrban. Ez több okból is jó: közelebb kerülhetsz az ügyfeleidhez (így gyorsabban elérhetik az oldaladat), valamint megfelelsz a helyi előírásoknak.

A másik előny a tárhelyszolgáltatókkal szemben a biztonság. Az AWS a biztonság szem előtt tartásával épült, és számíthatsz arra, hogy ha a WordPress webhelyed megfelelően van beállítva, akkor megbízhatóan fog működni. Ráadásul más felhasználók nem fogják befolyásolni webhelyed teljesítményét.

Az AWS képes alkalmazkodni az aktuális igényeidhez, és szükség esetén könnyen hozzáadhatunk vagy eltávolíthatunk erőforrásokat. Mi csak a felhasznált erőforrásokért fizetünk.

Végül, minden weboldalhoz ingyenes statikus IP-t kapunk, szemben a megosztott tárhelyekkel, ahol ugyanazt az IP-t osztjuk meg másokkal. Ez kiváló webshopok számára.

Bevezető

A szolgáltatás, amelyen végigvezetlek, az Amazon Lightsail nevű szolgáltatás. Más AWS-szolgáltatásokhoz képest egyszerűsített felhasználói felülettel rendelkezik, és fix havi árazással. A cikk középpontjában az áll, hogyan tudunk megbízható weboldalt üzemeltetni, de az elérhető legolcsóbb módon. A Let’s Encrypt ingyenes SSL-tanúsítványát fogjuk használni a Lightsail CDN-hez képest, amely jelenleg az első évben ingyenes (50 GB-ig), de később 2,50 USD/hó kerül. Arról nem is beszélve, hogy ha a látogatóid száma megnő, akkor 35 USD/hó kell fizetned. Ezért csak olyan szolgáltatásokat fogunk használni, amelyeknek fix díja van, még akkor is, így a költségek nem növekednek, ha a látogatóid száma nő.

AWS-fiók létrehozása

Ha még nincs AWS-fiókod, akkor létrehozhatsz egyet, ha ellátogatsz az AWS weboldalára, és a jobb felső sarokban található Create an AWS Account (AWS-fiók létrehozása) gombra kattintasz. Meg kell adni az e-mail címedet, jelszavadat, felhasználónevedet, személyes adataidat, beleértve a telefonszámodat és a hitelkártya adataidat. A kártyádat csak az általad igénybe vett szolgáltatásokért fogják megterhelni. Jó ötlet, ha a fiókodat rögtön a létrehozás után bitztonságossá teszeed. Olvasd el az Első dolgok beállítása az újonnan létrehozott AWS-fiókon című bejegyzésemet arról, hogyan engedélyezhetjük a többfaktoros hitelesítést a fiókon.

Amazon Lightsail

Jelentkezzünk be az AWS-fiókunkba, és ugorjunk be az Amazon Lightsailbe. A felső sávba írjuk be a lightsail szót, és válasszuk ki a Lightsail szolgáltatást, vagy kattintsunk erre a linkre, ha közvetlenül szeretnénk elindítani. Ha ez az első alkalom, akkor kiválasztjuk a nyelvet (sajnos egyenlőre magyar nyelv nincs). Válasszuk ki az English-t (angolt), és kattintsunk a Let’s get started (kezdjük el) gombra. Azonnal észre fogjuk venni, hogy a Lightsail sokkal barátságosabb felülettel rendelkezik.

A WordPress beállítása

Kezdjük egy új példány (weboldal) létrehozásával. A Lightsail automatikusan elvisz a példány beállításához egy üdvözlő üzenettel, hogy létrehozhassunk egy példányt. Később az Instances fül alatt, a Create instance (példány létrehozása) gombbal hozhatunk létre újat.

Új példány létrehozása

A Select your instance location (válassza ki a példány helyét) menüpontban az előbb vázolt paraméterek alapján választjuk ki a fizikai helyszínt. Az Amazon Lightsail jó tulajdonsága a többi AWS szolgáltatáshoz képest, hogy az árak minden régióban azonosak. (Ez más AWS szolgáltatásokra nem igaz.) Szabadon választhatunk régiót, és az árak nem változnak. Én a GDPR miatt a frankfurti régiót választom.

Ezután kiválasztjuk az operációs rendszert vagy szofvert. Mivel ez a cikk a WordPressről szól, a WordPress-t fogjuk kiválasztani.

Most jön a trükkös rész, amelyről lehet, hogy elfeledkeznél, ha nem olvasnád ezt a cikket.
Mindig jelöld be az Enable Automatic Snapshots (automatikus pillanatfelvételek engedélyezése) opciót. Az AWS nem garantálja, hogy a példányod nem fog meghibásodni, és ha meghibásodik, akkor az adataid elveszhetnek. Ezért engedélyezzük az automatikus pillanatképeket, hogy vészhelyzet esetén könnyen vissza tudjuk állítani az adatainkat.

Válasszunk ki egy árképzési opciót. Válasszuk ki az igényeinknek megfelelő és a költségvetésünkbe illeszkedő opciót.

Azonosítsuk a példányunkat egy barátságos névvel. Ez csak megjelenítési célokat szolgál; nincs hatása a példányra, de később nem változtathatjuk meg.

Kattintsunk a Create instance (példány létrehozása) gombra. Várjunk néhány percet, amíg a háttérben létrejön a példány. A példány létrehozása után az Instances (példányok) lapján a „Running” állapot fog megjelenni. A WordPress oldalad most már működik, de van még néhány fontos dolog, amit be kell állítanunk, mielőtt kávészünetre megyünk.

Statikus IP-cím csatolása

Kattintsunk a példány nevére, és válasszuk ki a Networking (hálózat) lapot. Válasszuk a Create static IP (statikus IP létrehozása) lehetőséget. Adjunk egy nevet a statikus IP-nek, és kattintsunk a Create (létrehozás) gombra. Felvetődik a kérdés, hogy miért fontos ez, ha már van egy IP-cím a példányához társítva. A probléma az, hogy ez az IP egy dinamikus poolból származik. Ez azt jelenti, hogy amikor később újraindítjuk a példányt, az IP-címe meg fog változni, és ezt nem szeretnénk. Egy statikus IP csatlakoztatásával az IP-címünk mindig ugyanaz marad.

DNS beállítása

Most itt az ideje, hogy összekapcsoljuk a domainünket ezzel az IP-címmel. Ha még nincs domained, javaslom, hogy regisztrálj egy .hu domaint, mert az országkód-specifikus végződések mindig kedvezőek; de ha szeretnél az AWS-nél maradni, akkor használhatod a Route 53-at is erre, viszont ott egyenlőre nincs .hu domain regisztrálási lehetőség.

A domain nevet a korábban létrehozott statikus IP címre kell irányítani. Ezt úgy tehetjük meg, hogy frissítjük az A rekordot ezzel az IP-vel.

Ha minden helyesen van beállítva, a böngészőbe beírva a domain nevet, megjelenik egy friss, új WordPress oldal.

SSL beállítása

Az SSL-tanúsítvány megléte manapság kötelező, és ezt többféleképpen is el lehet érni. Megmutatom, hogyan kell beállítani a Let’s Encryptet, amely ingyenes SSL tanúsítványt biztosít. Ehhez készítettem egy egyszerű szkriptet, amely elvégzi a nehéz munkát helyetted. Ezt a szkriptet a GitHubon találod. Az SSL beállításához először jelentkezz be a példányodba SSH-n keresztül. Ezt úgy teheted meg, hogy kiválasztod a Connect (kapcsolódás) fület a példányodon, és rákattintasz a Connect using SSH (SSH-n történő csatlakozás) gombra. Egy terminál ablakba fogsz kerülni, de ne aggódj, nem fogunk itt sok időt tölteni .

Egy új felugró ablak jelenik meg egy terminállal. A terminálba beillesztünk egy egyszerű szkriptet, vagy kézzel is beírhatjuk. Bármelyiket is szeretnénk.

A szkript beillesztéséhez az ablak jobb alsó sarkában találunk egy vágólap ikont. Kattintsunk rá, és illesszük be a következő szkriptet, majd kattintsunk a terminálra, és írjuk be a CONTROL + SHIFT + V (vagy COMMAND + V, ha Macen van) billentyűkombinációt.

wget -O - https://raw.githubusercontent.com/suhajda3/lightsail-ssl/main/lightsail-ssl.sh | sudo bash

A szkript megkérdezi a domain nevét és az e-mail címedet. Ha minden helyesen van beállítva, a szkript frissíti a rendszert, beállítja a Let’s Encryptet, és 90 naponként automatikusan megújítja azt, valamint megjeleníti a WordPress hitelesítő adataidat. Minden, amire szükségünk van.

Ezt a szkriptet bármikor futtathatod, amikor frissíteni szeretnéd a rendszert.

Jegyezzük fel a felhasználónevünket és jelszavunkat, mert később szükségünk lesz rá.

Írjuk be az exit-et a terminálból való kilépéshez és az ablak bezárásához.

A példány védelme (opcionális)

Mivel nincs szükségünk állandó terminál-hozzáférésre a példányhoz, érdemes letiltani az SSH-hozzáférést. Ehhez lépjünk át a Networking (hálózat) fülre, és kattintsunk az SSH sor mellett lévő szemetes ikonra. Győződjünk meg róla, hogy a HTTP és a HTTPS még mindig ott van, mert ezek nélkül nem tudnánk elérni az oldalunkat. Ha újra szeretnénk futtatni a szkriptet, vagy terminálhozzáférést szeretnénk, adjuk hozzá újra az SSH szabályt.

WordPress telepítés véglegesítése

A WordPress példányunk most már helyesen van beállítva. Jelentkezzünk be a WordPress oldalunkra úgy, hogy az URL-címünk végéhez hozzáadjuk a /wp-login.php címet. Itt bejelentkezhetünk az oldaladra azokkal a hitelesítő adatokkal, amelyeket a szkript korábban megjelenített.

Mielőtt elmész, még egy utolsó dolgot meg kell változtatnunk. A WordPress-ben a Settings, General, Site Language alatt válaszd ki a Magyar nyelvet.
Add hozzá az e-mail címedet arra az esetre, ha elveszítenéd a jelszavadat. A jobb felső sarokban válasszuk az Edit Profile (profil szerkesztése) lehetőséget, és változtassuk meg az Email címünket, majd kattintsunk a Update Profile (profil frissítése) gombra az oldal alján. Ezután kattintsunk a bal oldalon a Beállítások, Általános menüpontra, és változtassuk meg az Adminisztrációs e-mail címet is.

A WordPress webhelyed most már működik. Gratulálok!

A WordPress futtatása AWS-en – olcsón és egyszerűen bejegyzés először Road to AWS-én jelent meg.

CloudWatch beállítások

Az egyes API stádiumokhoz különböző naplózási beállítások alkalmazhatók. Ezért találjuk a CloudWatch beállításokat a Stages -> [stage name] -> Logs/Tracing alatt.

A CloudWatch naplók esetében két naplózási szint közül választhatunk: INFO az összes kérés végrehajtási naplójának generálásához, vagy ERROR csak a hibát eredményező kérések végrehajtási naplójának generálásához.

Lehetőségünk van a teljes kérés/válasz adatainak naplózására a megfelelő jelölőnégyzet bejelölésével.

Itt is engedélyezhetjük a részletes CloudWatch metrikákat.

Tegyük fel, hogy még soha nem engedélyeztük az API-naplózást. Ebben az esetben, amikor megpróbáljuk elmenteni a módosításainkat, a következő hibát kapjuk:

CloudWatch Logs role ARN must be set in account settings to enable logging

CloudWatch jogosultságok

A fenti hiba azért jelent meg, mert még nem állítottuk be a CloudWatch napló szerepkör ARN-jét a Beállítások alatt.

Ne feledjük, hogy az API-beállítások globálisak. Minden átjárónkra vonatkoznak. Ha megváltoztatjuk a CloudWatch naplószerep ARN-jét az egyik API átjárónkban, akkor az az összes átjárónkban meg fog változni, feltéve, hogy ugyanazt a régiót használjuk!

Próbáljuk meg hozzáadni a korábban létrehozott szerepkörünket: simple-api-role ARN. Az ARN-t az IAM konzol -> Roles, majd a simple-api-role kiválasztásával kapjuk meg.

Az ARN-ünk hozzáadásakor egy másik hibát kapunk:

The role ARN does not have required permissions configured. Please grant trust permission for API Gateway and add the required role policy.

A szerepkörünk még nincs beállítva a CloudWatchba való írásra. Menjünk vissza az IAM-be, és frissítsük a simple-api-szerepünket a megfelelő jogosultságokkal.

Először az AmazonAPIGatewayPushToCloudWatchLogs házirendet kell csatolnunk a szerepkörünkhöz. A házirendek szerepekhez való hozzáadását már korábban is elvégeztük. Ha elakadtál, menj vissza az Új Lambda funkció hozzáadása egy API Gateway-hez bejegyzéshez, ahol leírtam, hogyan csatolhatunk új házirendet egy meglévő szerepkörhöz. De még nem végeztünk…

A Trust relationships (izalmi kapcsolatok) lapon kattintson a Bizalmi kapcsolat szerkesztése gombra, és adja hozzá az apigateway.amazon.aws.com címet. Ha csak a Lambda-t használta ezzel a szereppel, akkor ez a példaházirend-dokumentum fog működni:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
            "lambda.amazonaws.com",
            "apigateway.amazonaws.com"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Most, hogy a jogosultságok megfelelően konfigurálva vannak, visszamehetünk az API-átjáróhoz, és hiba nélkül hozzáadhatjuk a szerepet.

Befejezés

Beállítottuk a CloudWatch napló szerepkör ARN-jét, most itt az ideje, hogy engedélyezzük a naplózást az API átjárónkban.

Amikor engedélyezzük a naplózást a /aws/apigateway/welcome log csoportban, egy új naplóbejegyzést fogunk látni: Cloudwatch naplók engedélyezve az API Gateway számára. Ez azt jelenti, hogy nagyszerű munkát végeztünk! Sajnos a naplóüzenetből nem derül ki, hogy melyik átjáróhoz, de az időbélyegző alapján duplán ellenőrizhetjük, hogy ez a mi átjárónk.

Az Amazon API Gateway új naplócsoportot hoz létre a következő formátum alapján: API-Gateway-Execution-Logs_apiId/stageName. Itt találjuk az API Gateway-ünk naplóbejegyzéseit.

Majdnem befejeztük API Gateway sorozatunkat. De a legfontosabb feladatunk még hátravan: Dokumentáció.

A Naplózás engedélyezése API Gateway-ben bejegyzés először Road to AWS-én jelent meg.

A lambda környezeti változók olyan karakterláncok kulcspárjai, amelyek a függvény verzió-specifikus konfigurációjában tárolódnak. Ez utóbbi akkor fontos, ha verziókezelést használunk a Lambdában. Egyelőre a kulcspáros részre koncentrálunk, a Lambda verziókról később beszélünk.

Környezeti változók definiálása

A környezeti változókat a Configuration (konfiguráció) fül, Environment variables (környezeti változók) szakaszában adhatjuk meg.

Az Edit (szerkesztés) gombra kattintva beállíthatjuk a környezeti változó kulcsát és értékét. Ehhez a bemutatóhoz hozzunk létre két változót: egyet a felhasználónév, egyet pedig a jelszó tárolására.

A Mentés gombra kattintás után a környezeti változók létrejönnek és elérhetővé válnak a Lambda futtatási időn keresztül. A folyamat környezetével érhetjük el őket, így:

const username = process.env.username;
const password = process.env.password;

Kulcs létrehozása titkosításhoz

A jelszavunk egy nagyon érzékeny információ, és szeretnénk úgy módosítani a kódunkat, hogy csak a Lambda kódunk tudja visszafejteni. A környezeti változók támogatják a titkosítást az AWS Key Management Service (KMS) segítségével.

Menjünk a KMS konzolra, és hozzunk létre egy új kulcsot. A Customer managed keys (ügyfél által kezelt kulcsok) alatt kattintsunk a Create key (kulcs létrehozása) gombra.

Ezután a kulcs típusát szimmetrikusra állítjuk be, és a kulcsunkat „simple-api-key”-nek nevezzük el az Alias alatt. Az alias bármikor megváltoztatható. Oktatási célokból egyelőre ne határozzuk meg a kulcs adminisztrációs és kulcshasználati jogosultságait.

Lambda környezeti változók titkosítása KMS segítségével

Most, amikor visszamegyünk a Lambdába, jelöljük be a Enable helpers for encryption in transit opciót. Minden változó mellett megjelenik egy új Encrypt (titkosítás) gomb. Az Encrypt gombra kattintva most már kiválaszthatjuk az újonnan létrehozott kulcsunkat.

A változó dekódolása

Ha megnézzük a változót, vagy kiíratjuk az értékét a Lambdából, akkor valami ilyesmit látunk:
AQICAHhc385PwJyf/tV5ZOhskZFcr5b6NMe/u3YFxJEWOhlnxQG776g/ozncvTV1p5KoSQucAAAAZzBlBgkqhkiG9w0BBwagWDBWAgEAMFEGCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQMGdpuISr9cRZoNj8TAgEQgCTHd1A1f6zmXa7cCbt8Q9UJqSetCvZ6m/I8VZuLC54k/0934ZE=

A dekódoláshoz két dologra van szükségünk:

1. a változó visszafejtése a KMS Decrypt művelettel
2. engedélyezzük a függvényünknek a KMS Decrypt művelet meghívását.

Először is módosítsuk a kódunkat a változó dekódolásához. Íme egy mintakód:

const plainUsername = process.env.username;
const encryptedPassword = process.env.password;
let decryptedPassword;

if (!decryptedPassword) {
    const kms = new AWS.KMS();
    try {
        const req = {
            CiphertextBlob: Buffer.from(encryptedPassword, 'base64'),
            EncryptionContext: {
                LambdaFunctionName: process.env.AWS_LAMBDA_FUNCTION_NAME
            },
        };
        const data = await kms.decrypt(req).promise();
        decryptedPassword = data.Plaintext.toString('ascii');
    } catch (err) {
        console.log('Decrypt error:', err);
        throw err;
    }
}

A kód végrehajtásakor hibát kapunk a CloudWatch-ban:

„errorType”:”AccessDeniedException”,”errorMessage”:”The ciphertext refers to a customer master key that does not exist, does not exist in this region, or you are not allowed to access.”

A környezeti változó visszafejtéséhez a függvényünknek hozzáférésre van szüksége a titkosításhoz használt kulcshoz. Menjünk vissza még egyszer a KMS konzolhoz, és módosítsuk a Kulcsfelhasználókat. Most hozzáadjuk a Lambda végrehajtó szerepkörünket a kulcsfelhasználókhoz. A mi esetünkben a simple-api-role-t.

És kész! Sikeresen létrehoztuk a Lambda környezeti változókat, amelyeket most már több forrásfájlban is használhatunk, és biztosítottuk a jelszavunkat a KMS-szel!

A Lambda környezeti változók használata bejegyzés először Road to AWS-én jelent meg.

Cognito User Pools (felhasználói csoportok)

Az Amazon Cognito egy egyszerű és biztonságos felhasználói regisztrációs, bejelentkezési és hozzáférés-szabályozási eszköz. Képes a felhasználói és az azonossági poolok kezelésére. A felhasználói poolok olyan felhasználói könyvtárak, amelyek regisztrálási és bejelentkezési lehetőségeket biztosítanak az alkalmazás felhasználói számára. Az Identity poolok AWS hitelesítő adatokat biztosítanak, amelyekkel a felhasználók hozzáférhetnek más AWS-szolgáltatásokhoz.

Az API-átjárónkhoz létrehozunk egy Cognito felhasználói csoportot, amely az összes engedélyezési feladatot, beleértve a felhasználónevek, jelszavak és hozzáférési tokenek kezelését is, kezeli.

Kezdjük a Cognitóval és válasszuk a Manage User Pools (felhasználói csoportok kezelése) lehetőséget. Itt válasszuk a Create a user pool-t (felhasználói csoport létrehozása). Nevezzük el a poolunkat simple-api-AUTH-nak, és tekintsük át a Step through settings-et (lépésről lépésre beállításokat), ahogy testre szabjuk a poolunkat. Ne feledjük, hogy ezeket az attribútumokat nem tudjuk megváltoztatni, miután létrehoztuk a pool-t. A házirendek és egyéb pool-beállítások később is módosíthatók, de az attribútumok nem. Amikor az „Alkalmazás-ügyfél” beállításoknál vagyunk, létrehozunk egy új alkalmazás-ügyfelet az API-átjárónkhoz.

Itt állítjuk be az App kliensünket. Az egyszerűség kedvéért kikapcsoljuk a Generate client secret opciót, és engedélyezzük az ALLOW_ADMIN_USER_USER_PASSWORD_AUTH opciót, amelyre szükségünk lesz a Lambda függvényünk eléréséhez.

A felhasználói csoportunk most már készen áll. Ilyen egyszerű .

Felhasználó hozzáadása Cognito felhasználói csoporthoz

Több lehetőségünk is van arra, hogy felhasználókat hozzunk létre a felhasználói készletünkben. Az alapértelmezett beállítások lehetővé teszik a felhasználók számára, hogy saját magukat regisztrálják. Létrehozhatunk egy egyszerű felhasználói felületet, vagy engedélyezhetünk más személyazonosság-szolgáltatókat, mint például a Facebook vagy a „Sign in with Apple”. Az egyszerűség kedvéért a felhasználót manuálisan hozzuk létre a Users and groups (felhasználók és csoportok) alatt.

Miután létrehoztuk a felhasználót, a felhasználó kap egy e-mailt a következő információkkal:

Your username is misi and temporary password is 00eEhtI;.

Úgy tűnik, hogy minden készen áll a Cognito-ban, de ha jobban megnézzük, akkor láthatjuk, hogy a felhasználó még nincs aktiválva. A fiók státusza a következő: FORCE_CHANGE_PASSWORD .

Ezt nem tudjuk megváltoztatni a Cognito felhasználói felületen, ezért ezt inkább a Lambda-ban fogjuk megtenni.

API átjáró csatlakoztatása Cognito-hoz

Most visszamegyünk az API-átjárónkhoz, és kiválasztjuk az Authorizers lehetőséget. Itt válasszuk a Create new authorizer -t (új engedélyező létrehozása).

Kiválasztjuk, hogy a típus Cognito legyen, és kiválasztjuk a korábban létrehozott Cognito felhasználói csoportunkat. A token forrását elnevezheted, ahogyan csak akarod, de a következő szabványok miatt Authorization-nek nevezzük el.

API-metódus biztosítása Cognitóval

Kezdjük el a metódusaink biztosítását a Cognito engedélyezésével. A korábban létrehozott hello erőforráson belül a GET metódust fogom kiválasztani. Ehhez a metódushoz már korábban beállítottuk az API kulcsokat, ezért eltávolítom a szükséges API kulcs opciót, és a Cognito-t választom az engedélyezésünkhöz.

Ha megnézzük a módszerünket, akkor láthatjuk, hogy a Cognito az Authorizer.

Auth függvény előkészítése hitelesítéshez

Amikor egy új Lambda függvényt adtunk hozzá az API átjárónkhoz, létrehoztunk egy auth módszert az átjárónkhoz. Ezt fogjuk használni a hitelesítéshez. Érdemes az Amazon API Gateway már meglévő funkcióira támaszkodni, beleértve a kérések érvényesítését is. Az API Gateway képes validálni a lekérdezési karakterláncot, a fejléceket és a testet. Ez utóbbit egy későbbi bejegyzésben tárgyaljuk, mert ehhez egy modell létrehozása szükséges. A lekérdezési karakterlánc paramétereinek beállítása sokkal egyszerűbb.

Adjuk meg a felhasználónevet és a jelszót URL-lekérdezési karakterlánc paraméterként, és jelöljük meg őket Kötelezőnek. A Request Validator alatt válasszuk a Validate query string parameters and headers lehetőséget.

Az AWS API Gateway mostantól ellenőrzi ezeket a paramétereket, és ha nem léteznek, az átjáró hibát jelez a felhasználónak.

Ne felejtsük el Deploy-olni (közzétenni) az API-t.

Szükséges engedélyek beállítása a Lambda számára

A Lambda függvényünknek hozzá kell férnie a Cognito felhasználói készletünkhöz. Igen, jól sejted, hogy az IAM-et fogjuk használni.

Nincs alapértelmezett házirend a kiadni kívánt engedélyekhez, ezért létrehozunk egy új házirendet. Szükségünk van az AdminInitiateAuth és az AdminSetUserPassword engedélyekre a Lambda függvényünkhöz, hogy kezelni tudjuk a Cognito felhasználói állományunkat.

A Házirendek alatt a „Házirend létrehozása”, a szolgáltatásoknál pedig a Cognito User Pools lehetőséget választjuk. A Művelet alatt kiválasztjuk a két engedélyt, az Erőforrások alatt pedig hozzáadjuk a Cognito User Pool ARN-jét.

Ezután létrehozzuk ezt a házirendet, és csatoljuk a simple-api-Role-hoz, ahogy azt az előző bejegyzésben megtanultuk.

Felhasználó megerősítése

Menjünk vissza a Lambdához, és szabaduljunk meg a bosszantó „FORCE_CHANGE_PASSWORD” állapottól. Ehhez írjunk egy egyszerű Lambda függvényt, amely megváltoztatja a felhasználó jelszavát.

Ezt a kódot használtam a felhasználó megerősítésére:

const params = {
    Password: 'password',
    UserPoolId: 'Pool Id',
    Username: 'username',
    Permanent: true
};
    
await cognito.adminSetUserPassword(params).promise();

Futtassa a kódot, és ha mindent helyesen állítottunk be, a Cognito azt fogja mutatni, hogy a számla státusza mostantól CONFIRMED (megerősített).

Utolsó simítások

Már majdnem kész vagyunk! Már csak egy kis kódot kell írnunk, amely a Cognitót hívja az engedélyezéshez. Szerencsére már van egy minta Lambda függvényünk, amit módosíthatunk: simple-api-auth

Cseréljük ki a korábbi kódot erre a minta kódra:

const aws = require('aws-sdk');
const cognito = new aws.CognitoIdentityServiceProvider();

exports.handler = async (event) => {
    const params = {
        AuthFlow: 'ADMIN_NO_SRP_AUTH',
        ClientId: 'App client id',
        UserPoolId: 'Pool Id',
        AuthParameters: {
            USERNAME: event.queryStringParameters.username,
            PASSWORD: event.queryStringParameters.password
        }
    };
    
    var authResponse = await cognito.adminInitiateAuth(params).promise();
    
    const response = {
        statusCode: 200,
        body: JSON.stringify(authResponse),
    };
    return response;
};

Deploy-ojuk (tegyük közzé) és kész is vagyunk!

API Gateway hitelesítés tesztelése

Menjünk a Postman-be, és nézzük meg, hogy minden az elvárásoknak megfelelően működik-e.

Ha meghívjuk a /hello metódusunkat, a következő hibát kapjuk:

„message”: „Unauthorized”

Nagyszerű! Szükségünk van egy IdTokenre a módszer eléréséhez. Hívjuk meg az auth metódusunkat, hogy megkapjuk a tokent. Az API Gateway ellenőrizni fogja, hogy megvan-e a felhasználónév és a jelszó paraméter. Ha nem, akkor hibát fogunk kapni.

Megkaptuk a token-ünket. Ha most visszamegyünk a /hello metódushoz és beállítjuk az Authorization fejlécet, akkor hozzáférünk a függvényhez. Ügyeljünk arra, hogy az IdToken-t használjuk az Authorization-hez.

És voilá! Az API átjárónk mostantól a Cognito-t használja hitelesítésre.

A API Gateway hozzáférés vezérlése Cognito-val bejegyzés először Road to AWS-én jelent meg.