Spot the difference: Schnelle Ressourcenübersicht

Lambda: Node 6.10 End of Lifetime - welche Funktionen sind betroffen?

Heute kam eine Abkündigung für die Unterstützung von node 6.10 per Mail von AWS.

“AWS Lambda: Node.js 6.10 will soon be EOL, please migrate your functions to a newer runtime version [AWS Account: 123456789012] "

Da stellt sich mir doch die Frage: “Was ist die effektivste Methode die Runtime von Lambda Ressourcen herauszufinden?”

Dazu will ich mal ein paar Methoden vorstellen. Es sind auch ein paar (noch) unbekannte dabei… Aber lest selbst

Der schnelle Weg: cli Ninja

Wer sich mit der aws CLI viel beschäftigt, kann gerade mit der Nutzung von “query” schnell Ergebnisse erzielen. Die Query wertet die JSON Antwort aus. Der lambda Service liefert ein Array von functions aus, welches alle Attribute enthält, unter anderem auch die Runtime.

Diese Auswertung müsste immer wieder ausgeführt werden, wenn eine Lambda Konfigurationsänderung durchgeführt wird.

aws lambda list-functions --query "Functions[?Runtime == 'nodejs6.10']"

Aber dazu benötigt man immer eine Workstation. Kann man das auch "workstationless” ausführen?

Ja, und zwar mit der neuen Funktion Config Query über die AWS Console.

Der neue Service: Config Advanced Query

In AWS Config werden die Konfigurationen von AWS Ressourcen geprüft und ausgewertet. Eine neue Funktion macht es möglich die gespeicherten Ressourcen in einer SQL Syntax abzufragen. Dabei fragt man nicht direkt die Ressourcenkonfiguration ab, wie es list-function macht, sondern die Konfigurationsdatenbank. Daher gibt es auch die Informationen wie configuration.lastModified.

Die Syntax für dieses Abfrage ist auch in den Beispielabfragen enthalten und sieht so aus:

SELECT
resourceId,
resourceType,
configuration.runtime,
configuration.lastModified,
configuration.description
WHERE
resourceType = 'AWS::Lambda::Function'
AND configuration.runtime = 'nodejs6.10'

Natürlich kann ich auch alle Funktionen suchen, die nicht einem bestimmten Wert entsprechen:

SELECT
*
WHERE
resourceType = 'AWS::Lambda::Function'
AND configuration.runtime != 'nodejs8.10'

In der Konsole findet man die Abfragen unter “AWS-Config, Ressourcen”

Console

Config führt regelmäßigem Compliance Check durch. Aber auch mit der query habe ich nur eine Momentaufnahme.

Will ich regelmäßig, bzw. immer, wenn eine Lambda Konfiguration geändert wurde, eine automatische Prüfung durchführen, so kann das auch mit “AWS Config” Rules erreicht werden.

Dazu wird eine Regel erstellt:

Regel

Für Lambda gibt es zwei vorkonfigurierte Regeln. Regeln können auch selber als Lambda Funktionen erstellt werden. Die richtige Regel heißt lambda-functions-setting-check:

preconfigured

Hier kann man nun bei “Rule parameters” unter runtime, z.B. den Wert “nodejs8.10” eintragen. Dann werden alle Lambda Konfigurationen, die nicht “nodejs8.10” als Runtime eingetragen haben als non-Compliant gemeldet.

Problematisch ist es hier, dass alle Lambda geprüft werden, auch z.B. die Funktionen die “Python” oder “go” als runtime haben. Bei mir sind dass dann 22 Lambdas, von denen die meisten aber in go geschrieben sind :) :

Aber auch hierfür gibt es eine Lösung: Die Config Regeln können entweder auf Resource Typen (Wie “Lambda:Function”) oder Tags im Sope eingeschränkt werden. Will man nun nur alle Ressourcen prüfen, die man vorher z.B. mit dem Tag “Type: nodeLambda” getaggt hat, so schränkte man den Sope auf Tags ein:

Dann prüft der Trigger für die Regel nicht den Ressourcentyp, sondern, ob diese Ressource gettagt ist.

In allen Lambda Funktionen, die node als Basis haben, trägt man diesen Tag ein:

Im Beispiel habe ich den Tag bei einer Funktion eingetragen und erhalte bei der Config-Regel-Prüfung auch nur noch eine non-compliant Resource:

Fazit AWS Config ist ein sehr nützlicher Dienst, wenn es um Überprüfung von Compliance oder Sicherheitslücken in fast allen AWS Ressourcen geht. Die Abfragefunktion ist eine seht nützliche Ergänzung, die man sich genau anschauen sollte.

Photo by Mehrshad Rajabi on Unsplash

Similar Posts You Might Enjoy

Dissecting Serverless Stacks (IV)

Dissecting Serverless Stacks (IV) After we figured out how to implement a sls command line option to switch between the usual behaviour and a way to conditionally omit IAM in our deployments, we will get deeper into it and build a small hack on how we could hand over all artefacts of our project to somebody who does not even know SLS at all. - by Thomas Heinen

R can not be pushed in Production - deprecated!

Running Shiny on Fargate Some guys still thinking R cannot be used at scale or only in a limited way. I still do not understand the reason why people are like this. Since my last post about AWS Batch, which is a Docker-based service within AWS, which enables you to work with R, I spend a lot of time with Fargate, another Docker-based service on AWS. This time my boss wanted a BI app. - by Malte Walkowiak

Dissecting Serverless Stacks (III)

Dissecting Serverless Stacks (III) The third post of this series showed how to make IAM statements an external file, so we can deploy that one but still work with the sls command. It still involved commenting out things in the configuration, so this post will show how to solve that issue. - by Thomas Heinen