В чем разница между темой ARN и целевой ARN AWS ​​SNS? - PullRequest
Новая
       55

В чем разница между темой ARN и целевой ARN AWS ​​SNS?

0 голосов
/ 10 октября 2019

Я пытался опубликовать сообщение в теме SNS, используя boto3 в Lambda следующим образом: 

def publish_msg(msg, bar):
    response = SNS.publish(
        TopicArn='blah_blah_arn',
        Message=msg,
        MessageAttributes={
            'foo': {
                'DataType': 'String',
                'StringValue': bar
            }
        }
    )

, который не работал, потому что продолжал выдавать мне ошибку аутентификации, которая выглядела примерно так: 

Error publishing message because lambda_fn_role doesn't have the permissions to invoke SNS:Publish on resource blah_blah_arn

Но я был уверен, что моя политика для этой функции была правильной, поэтому я изменил TopicARN на TargetARN, и это сработало!

Поэтому мой вопрос таков: В чем разница междутема и цель ARN? и когда один должен использоваться поверх другого?

Документы AWS для boto3 вообще не отвечают на этот вопрос.

Очень признателен!

1 Ответ

1 голос
/ 11 октября 2019

Как оказалось, проблема здесь не в том, как она появилась.

TopicArn и TargetArn на самом деле взаимозаменяемы, в этом случае. (Почему существует два возможных способа передачи темы ARN? Изначально SNS поддерживал только темы в качестве целей, но теперь поддерживает другие виды вещей, так что это, скорее всего, случай обратной совместимости API, в которой AWS обычно очень хорош.)

tl; dr: Иногда при изменении политики IAM, используемой ролью выполнения Lambda, функция Lambda не ведет себя так, как если бы изменение политики произошло.

Причина, по которой это работало только после перехода с одного на другое, была связана (на некотором уровне) с тем, что происходит, когда вы обновляете код для функции Lambda.

Служба Lambda управляет контейнерами, которые запускают вашкод, причем каждый контейнер выполняет не более одного одновременного вызова функции за раз. Последующие вызовы могут повторно использовать тот же контейнер ... но только когда код, связанный с функцией, идентичен, неизменен.

Обновите код функции и затем снова запустите функцию (впервые с новым кодом вместо), и вы гарантированно окажетесь в новом контейнере, который ранее не использовался.

Новый контейнер должен получить временные учетные данные для роли выполнения лямбда-выражений, используя AssumeRoleдействие в службе маркеров безопасности AWS, которая предоставляет временный идентификатор ключа доступа AWS и секретный ключ, а также токен сеанса. Lambda сохраняет их в переменных окружения как AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY и AWS_SESSION_TOKEN, где AWS-SDK в вашей функции (используется в этом примере для вызова других служб, таких как SNS)подбирает их и использует для подписи запросов.

То, с чем столкнулся ОП, было странностью где-то в этой настройке. Что-то в IAM или STS приводит к кешированию или устареванию данных в системах AWS - политика (или последняя версия политики), которая была необходима, чтобы разрешить роли выполнения Lambda выполнять действие SNS:Publish в отношении рассматриваемой темы, не былавидимый компоненту, который должен был его видеть, чтобы разрешить действие.

Неясно, где именно происходит это кэширование. Лямбда, конечно, кэширует временные учетные данные, как и служба метаданных EC2, и любой другой клиент с хорошим поведением, так как не имеет смысла постоянно делать запросы к STS, когда временные учетные данные все еще действительны. Я не уверен, что причиной является кеширование учетных данных (хотя и вносит свой вклад).

Учетные данные STS - это черный ящик, особенно этот «маркер сеанса». Содержит ли он зашифрованные данные? Или это просто большое случайное значение, буквально не более чем символический «токен» без внутреннего значения? На самом деле это не имеет значения, но дело в том, что он не задокументирован четко.

IAM - это массивная распределенная система, поэтому у нее, естественно, есть «возможная согласованность» проблем, которые могут возникнуть иногда.

Но, каким-то образом, создание нового Lambda-контейнера - который обязательно должен сделать новый вызов STS - похоже, имеет побочный эффект, приводящий к разрушению кэша, который делает текущие политики IAM дляРоль выполнения становится доступной в тех случаях, когда что-то не работает, в новом развертывании.

Кажется, что время от времени появляется после того, как вы пытаетесь выполнить заданное действие, происходит сбой, и вы понимаете, что вам нужно отредактировать IAMполитика, которую вы намеревались быть достаточным, чтобы разрешить действие. Таким образом, вы редактируете политику, но последующие попытки все равно терпят неудачу, но политика кажется действительной, поэтому вы не можете понять, почему она не работает, и бросаете руки в воздух, отправляете сообщение Джону Ротенштейну, что выв конце вашего ума ... затем, после того, как вы откажетесь от ночи в отчаянии, вы возвращаетесь на следующее утро, чтобы продолжить поиск неисправностей, и обнаруживаете, что это внезапно работает.

Предположительно, это связано со заменой временных учетных данных старой роли выполнения, либо из-за того, что контейнеры удаляются и заменяются из-за неактивности, либо просто потому, что временные учетные данные имеют конечный срок службы ... но неясно, обновляется ли STSтокены на самом деле являются необходимой частью решения, или просто исправляет неполадки в стороннем IAM как побочный эффект.

Повторное использование лямбда-функции для проверки изменения кода, вероятно, будет иметь тот же эффект, в любом случае,как здесь.

...