Лямбда-функция не может получить доступ к диспетчеру секретов

Question

Я написал лямбда-функцию для доступа к базе данных, поэтому первым делом нужно получить секреты от AWS Secrets Manager. У меня есть частный VPC, а также подсети, шлюз NAT и группа безопасности, связанная с лямбда-функцией. у меня тоже естьsecretsmanager.Secret.grantRead(lambda_exec_role) поэтому лямбда должна иметь доступ к диспетчеру секретов.

По какой-то причине, когда я тестировал его в API Gateway, я получил "errno": "ETIMEDOUT" и "code": "NetworkingError" в CloudWatch. И из распечатанного журнала, который у меня был в API, получить секреты не удалось.

Я также попытался добавить конечную точку VPC для Secrets Manager, как здесь, но все равно получил ту же ошибку.

Был бы признателен, если бы кто-нибудь здесь мог помочь мне с этим или дать несколько советов.

Большое спасибо!

Answer 1

У меня тоже была проблема с лямбдой, получающей секретный контент.

Вот несколько вещей, которые вы можете попробовать:

# 1 Убедитесь, что у вас есть разрешение на получение секретного значения, я дам вам свое для рабочей конфигурации:

• Разрешить:secretsmanager:GetSecretValue для вашего секрета
• Разрешить:secretsmanager: ОпишитеСекретите свой секрет
• Разрешить:secretsmanager: ListSecrets на всех ресурсах

#2 У меня тоже были проблемы с моим VPC и подсетями. В случае неправильной настройки вы не сможете вызвать API диспетчера секретов.

• Переключитесь на режим без VPC для лямбда-выражения и проверьте, можно ли получить свой секрет в порядке. Если он работает, значит, у вас проблема с конфигурацией VPC / подсети.
• Проверьте конфигурацию вашей подсети:
  • В общедоступной подсети вы можете настроить конкретную конечную точку для секретного менеджера, хотя я не мог заставить его работать, не знаю почему.
  • В частной подсети вы должны настроить шлюз NAT, чтобы иметь возможность вызывать API секретного менеджера.

Надеюсь, когда-нибудь это кому-нибудь поможет. :)

Answer 2

На случай, если кто-то еще задаст этот вопрос при устранении неполадок с лямбда-расширением Secrets Manager, я хотел бы поделиться своим опытом реализации с использованием среды выполнения Nodejs18.x (совершенно новой на данный момент). Я воспользовался новым ожиданием верхнего уровня из этой новой среды выполнения и надеялся получить свой секрет от SM при инициализации (вне обработчика). Все мои попытки не увенчались успехом, и я получал ответ от расширения

не готов обслуживать трафик, пожалуйста, подождите

Перемещение вызова http (на порт расширения) внутри моей функции-обработчика немедленно устранило проблему.

Answer 3

У меня также была аналогичная проблема, и мне помогло добавитьkms:Decryptк IAM-политике. Потому что согласно официальной документации AWS:

Если секрет зашифрован с помощью ключа, управляемого клиентом, а не управляемого ключа Amazon Web Services aws/secretsmanager , вам также потребуются разрешения kms:Decrypt для этого ключа. https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/secretsmanager.html#SecretsManager.Client.get_secret_value

Политика IAM, прикрепленная к Lambda, должна выглядеть примерно так:

      {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kms:Decrypt",
                "secretsmanager:GetSecretValue",
                "secretsmanager:DescribeSecret",
                "secretsmanager:ListSecrets"
            ],
            "Resource": "*"
        }
    ]
}

Возможно, вы захотите ограничитьResourcesна что-то более конкретное в зависимости от ваших требований. Надеюсь, это также работает для вас.

Answer 4

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

Поскольку вы имеете дело с Lambda внутри VPC, обратите внимание, что существует два способа размещения вашей Lambda в VPC:

• в общедоступной подсети: в этом случае ваша Lambda НЕ МОЖЕТ иметь доступ к Интернету, поэтому единственным вариантом будет настроить конечную точку VPC для диспетчера секретов или
• в частной подсети: в этом случае ваша частная подсеть может иметь маршрут0.0.0.0/0трафик к шлюзу NAT, а затем к интернет-шлюзу (через общедоступную подсеть). Это дает вам возможность получить доступ к Secrets Manager через его общедоступную конечную точку (т. е. через Интернет) или, опять же, через конечную точку VPC.

Answer 5

Чтобы принять участие в этом, моему решению потребовалось два шага

• Создайте конечную точку VPC для Secrets Manager (я следовал этому процессу здесь: https://aws.amazon.com/blogs/security/how-to-connect-to-aws-secrets-manager-service-within-a-virtual- частное облако/ )
• Прикрепите политику к роли Исполнителя, как отметил ранее @frida-schenker.

Answer 6

Вот как у меня это работает serverless.yml.

Ссылка AWS: https://docs.aws.amazon.com/secretsmanager/latest/userguide/vpc-endpoint-overview.html#vpc-endpoint

Следующий yml появляется под путем resources.Resources.YourVPCEndpointNameHere:

      # Provides access from the VPC to Secrets Manager
# See https://docs.aws.amazon.com/secretsmanager/latest/userguide/vpc-endpoint-overview.html#vpc-endpoint
Type: AWS::EC2::VPCEndpoint
Properties:
  VpcEndpointType: Interface
  ServiceName: com.amazonaws.#{AWS::Region}.secretsmanager
  PrivateDnsEnabled: true

  # Reference your VPC here
  VpcId: !Ref EC2VPC

  # Reference your subnet ids here
  SubnetIds:
    - !Ref EC2SubnetA
    - !Ref EC2SubnetB
    - !Ref EC2SubnetC

  # Reference your security group(s) here
  SecurityGroupIds:
    - !Ref EC2SecurityGroup

Совет: вам понадобится плагин serverless-pseudo-parameters делать #{AWS::Region} Работа.