Wie Berechtigungen in AWS Lambda funktionieren

Bei der Arbeit mit AWS Lambda haben viele Benutzer Probleme mit den Zugriffsrechten auf andere AWS-Services. Genauer gesagt, wie man auf Services wie S3, RDS, Transcribe oder andere zugreift.

Vonage API-Konto

Um dieses Tutorial durchzuführen, benötigen Sie ein Vonage API-Konto. Wenn Sie noch keines haben, können Sie sich noch heute anmelden und mit einem kostenlosen Guthaben beginnen. Sobald Sie ein Konto haben, finden Sie Ihren API-Schlüssel und Ihr API-Geheimnis oben auf dem Vonage-API-Dashboard.

In diesem Lernprogramm wird auch eine virtuelle Telefonnummer verwendet. Um eine zu erwerben, gehen Sie zu Rufnummern > Rufnummern kaufen und suchen Sie nach einer Nummer, die Ihren Anforderungen entspricht.

Sind Sie bereit, mit dem Bau zu beginnen?

Erleben Sie nahtlose Konnektivität, Echtzeit-Messaging und kristallklare Sprach- und Videoanrufe - alles auf Knopfdruck.

Viele erstellen einen neuen IAM-Benutzerund setzen AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY in Umgebungsvariablen. Das AWS SDK verwendet "automatisch" diese Schlüssel oder Werte aus einer AWS-Anmeldeinformationen-Datei. (Siehe die Dokumentation darüber, wie das SDK diese Werte verwendet). Es wäre jedoch ein Fehler, diese Anmeldeinformationen für einen Lambda hinzuzufügen.

Verwechslung der Identität

Der Versuch, die folgende .env Datei verhindert, dass eine Anwendung von Lambda aus auf AWS-Services zugreifen kann. Der Verbindungsfehler tritt unabhängig davon auf, wie Sie den IAM-Benutzer konfiguriert haben.

Wenn die Lambda-Funktion ausgeführt wird, werden die oben gezeigten Umgebungsvariablen von Lambda generiert. Das bedeutet, dass die Werte der Datei .env werden nicht wie erwartet gesetzt.

Wenn Sie mehr über die Bereitstellung mit Serverless lesen möchten, lesen Sie AWS Lambda mit PHP unter Verwendung von Bref und Serverless Framework oder Serverloses Python mit AWS Lambda.

Einstellung von Berechtigungen

Mit Umgebungsvariablen AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY die von Lambda festgelegt werden, müssen auch die Rollenberechtigungen während der Bereitstellung festgelegt werden. Alle AWS-Services werden auch direkt in der Lambda-Funktion anstelle eines IAM-Benutzers behandelt.

Nachfolgend finden Sie ein partielles yaml-Beispiel für die Verwendung des Serverless-Frameworks zur Bereitstellung einer AWS Lambda-Funktion.

provider:
    name: aws
    region: us-east-1
    runtime: provided
    iamRoleStatements:
        - Effect: Allow
          Action:
              - s3:PutObject
              - s3:GetObject
              - s3:DeleteObject
          Resource: 'arn:aws:s3:::bucket-name/*'
        - Effect: Allow
          Action: transcribe:*
          Resource: '*'

Beachten Sie den iamRoleStatements Block im obigen Beispiel. Darin wird das Lambda gewährt s3:PutObject, s3:GetObject, und s3:DeleteObject Berechtigungen für die Ressource bucket-name und alles darin. Außerdem hat die Funktion Zugriff auf transcribe:* Dienste.

Das obige Beispiel ähnelt sehr der Festlegung von IAM-Berechtigungen in den folgenden Beispielen:

AWS IAM S3 Policy Example

AWS IAM Transcribe Policy Example

Prüfung von Berechtigungen

Nach erfolgreicher Bereitstellung in AWS Lambda können die aktiven Berechtigungen der Funktion in der AWS-Konsole angezeigt werden. Navigieren Sie dazu zur Registerkarte "Permissions" in der Funktionskonsole.

AWS Lambda Function Permissions

Von dort aus können Sie auf die Berechtigungen der einzelnen Dienste klicken, um eine detailliertere Aufschlüsselung der Einstellungen zu erhalten.

Was nun?

Dokumentation über mögliche Berechtigungen für verschiedene AWS-Services finden Sie in der AWS-Dokumentation zur Identitäts- und Zugriffsverwaltung. Achten Sie auch auf zukünftige Beiträge mit Beispielen für die Verwendung dieser Berechtigungen in der Praxis.