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.

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.

Lambda függvény létrehozása

Először is, hozzunk létre egy Lambda függvényt, mint az előző bejegyzésben, de ahelyett, hogy a Use a blueprint opciót választanánk, most az Author from scratch (Üres tervezet) opciót válasszuk. Adjunk egy nevet a függvényünknek. A Permissions alatt nem fogunk új szerepet létrehozni ehhez a függvényhez, hanem a meglévő szerepkörünket választjuk ki, amit a terveztünk hozott létre.

A Create function (Függvény létrehozása) gombra kattintás után a Lambda kódunk elkészül, és készen áll az API átjárónkkal való összekapcsolásra. Ehhez belépünk az API Gateway szolgáltatásba.

Szeretnénk ezt a funkciót új erőforrásként használni, ezért létrehozunk egy új erőforrást, és abban egy új módszert. A metódus beállításainál az előzőekhez hasonlóan kiválasztjuk az új Lambda függvényünket. Most már láthatjuk az API flow diagram-ot (folyamatábrázolási diagram) ahol szemléletesen láthatjuk, hogyan hajtódik végre az újonnan létrehozott Lambda függvényünk.

A Test gombra kattintva tesztelhetjük az új API-hívásunkat, és hogy minden rendben működik. Biztosak vagyunk benne?!

Minden rendben van?

Ne feledjük, hogy egy meglévő szerepet választottunk az új Lambda függvényünkhöz. A szerepkörünk rendelkezik az összes szükséges jogosultsággal?

Ha visszamegyünk a Lambda-hoz, és megnézzük a Monitor részt, nem látunk hibát.

A CloudWatch naplók megtekintése gombra kattintva viszont hibaüzenetet kapunk.

Ez azt jelenti, hogy a naplózás jelenleg nem működik az új Lambda függvényünkön. Manuálisan kell létrehoznunk egy naplócsoportot, és engedélyeznünk kell a szerepkörünknek, hogy ebbe a naplóba írjon.

A CloudWatch konzolban válasszuk a Log groups (naplócsoportok) menüpontot, majd kattintsunk a Create log group (naplócsoport létrehozása) gombra, és nevezzük el a naplócsoportunkat pontosan úgy, ahogy a hibaüzenetben szerepel. Esetünkben: /aws/lambda/simple-api-auth

A naplócsoport létrehozásakor ne felejtsük el feljegyezni az ARN-jét, mert később szükségünk lesz rá.

Most, hogy engedélyeztük a szerepkörünknek, hogy írjhasson ebbe a naplócsoportba, el kell mennünk az IAM-be, és módosítanunk kell a szerepkörünket. Látjuk, hogy a CloudWatch engedélyek az AWSLambdaBasicExecutionRole házirendben vannak.

Most kiválasztjuk ezt a házirendet, és az Edit policy (Házirend szerkesztése) gombra kattintunk. Az erőforrások szakaszban az Add ARN (ARN hozzáadása) gombra kattintunk, és hozzáadjuk az újonnan létrehozott naplócsoportok ARN-jét. Mentsük el a házirendet.

És kész is vagyunk! Hozzáadtunk egy új funkciót az API-átjárónkhoz, és beállítottuk a szükséges jogosultságokat.

Tanulságok:

• Tartsuk karban a jogosultságokat az IAM-ben. Adjuk meg a haznált erőforrásokat, és csak a szükséges házirendeket engedélyezzük.

A Lambda függvény hozzáadása API-átjáróhoz bejegyzés először Road to AWS-én jelent meg.

Az AWS azt ajánlja, hogy a legtöbb feladathoz használjunk API-t, mivel később könnyebb lesz skálázni a felhőinfrastruktúrát. Ebben a példában egy egyszerű API-t hozunk létre, amely egy Lambda függvényt hív meg.

Javaslom, hogy egy beépített tervezettel kezdjünk, így az összes szükséges erőforrás automatikusan létrejön és összekapcsolásra került. Később módosíthatjuk ezeket a beállításokat.

Kezdés beépített tervezettel

Kezdjük az AWS Management Console-lal. Válasszuk ki a Lambda-t a szolgáltatások közül, és kattintsunk a Create function (Funkció létrehozása) gombra.

A Create function (Funkció létrehozása) alatt válasszuk a Use a blueprint (Tervezetek) lehetőséget, és a Blueprints (Tervezetek) alatt szűrjünk ki az „api” szóra. Válasszuk ki a microservice-http-endpoint blueprint-et, és kattintsunk a Configure (Konfigurálás) gombra.

A következő képernyőn konfiguráljuk a Lambda és az API átjárót. A Function name alatt adjunk nevet a függvénynek, a Role name alatt pedig állítsunk be egy szerepkört. Az API Gateway trigger alatt válasszuk a Create an API-t, és válasszuk a REST API-t API-típusként. Az AWS a HTTP API-t ajánlja a teljesítménye miatt, de jelenleg a REST API több funkcióval rendelkezik. A HTTP és a REST API teljes összehasonlítását ezen az oldalon tekinthető meg:
https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-vs-rest.html
Biztonsági okokból az API-kulcsot a Biztonság menüpont alatt választjuk ki. Egy későbbi szakaszban ezt Cognito-ra fogjuk változtatni, de egyelőre az API-kulcsok a legjobb megoldás, mert nagyon könnyen kezelhetőek és alapvető biztonságot nyújtanak.

A Lambda és az API-átjáró létrejött és összekapcsolódott. Nagyszerű munka!

Az API átjáró beállítása

Először kezdjük el az API átjáró konfigurálását. Válasszuk ki az AWS Management Console szolgáltatásai közül az API Gateway-t, majd az újonnan létrehozott API-t. Az API most már aktív és nyitott: bármilyen kapcsolatot elfogad, és nem igényel API-kulcsot. Mivel erre először nincs szükségünk, töröljük a GET metódust a minta API-nk alatt.

Hozzunk létre egy „hello” nevű erőforrást. Válasszuk ki az API gyökerét (esetünkben a simple-api-t), majd a Műveletek menüpontban válasszuk a Create Resource lehetőséget. Nevezzük el az erőforrásunkat „hello” névvel.

Ezen erőforrás alatt létrehozunk egy GET metódust. Mindenképpen jelöljük be a „Use Lambda Proxy Integration” opciót, mert így fogjuk beolvasni az erőforrás nevét a Lambda-ból. Továbbá válasszuk ki a Lambda Function-t, amelyet a beépített tervezet automatikusan létrehozott.

Most pedig alkalmazzunk némi biztonságot az API-nkra. Válasszuk ki az újonnan létrehozott GET metódust, és kattintsunk a Method Request gombra. Itt változtassuk meg az API Key Required értékét true-ra (igazra).

Már majdnem készen vagyunk az API átjáró konfigurációjával! De most jön a legfontosabb rész. Közzé tennünk az API-t. Az Action menüpont alatt válasszuk a Deploy API lehetőséget.
Mielőtt továbblépnénk, írjunk le néhány fontos információt: az Invoke URL-ünket és az API kulcsunkat. A Stages alatt válasszuk ki az alapértelmezett stage-et, ahol az invoke URL-t találjuk. Az API Keys alatt találjuk a simple-api-Key-t, ami az API kulcsunk. Most már visszamehetünk a Lambdához.

Configuring Lambda

A tervezet létrehozott egy Dynamo DB példát. Egyelőre nem fogjuk használni a Dynamo DB-t. Cseréljük ki az alapértelmezett kódot erre. És kattintsunk a Deploy gombra. Most már tesztelhetjük az API-nkat!

const AWS = require('aws-sdk');

exports.handler = async (event, context) => {
    
    var response_status, response_body; 
    
    if (event.resource.endsWith('hello')) {
        response_status = 200;
        response_body = "Hello from Lambda";
    }
    else {
        response_status = 200;
        response_body = "Unsupported resource";
    }

    const response = {
        statusCode: response_status,
        body: JSON.stringify(response_body),
    };
    return response;
};

Az API-k tesztelésére a legjobb eszköz a Postman. Ingyenesen létrehozhunk egy fiókot.

A postmanben teszteljük az újonnan elkészített API-t. Ügyeljjünk arra, hogy beállítsuk az API-kulcsot.

Szép munka! Most már van egy teljesen működő API-nk alapvető biztonsággal.

A Egyszerű API átjáró létrehozása AWS-en bejegyzés először Road to AWS-én jelent meg.