EB Worker cron.yaml - 无权执行：dynamodb:UpdateItem

Posted 2023-03-04

【中文标题】EB Worker cron.yaml - 无权执行：dynamodb:UpdateItem

【英文标题】：EB Worker cron.yaml - is not authorized to perform: dynamodb:UpdateItem

【发布时间】：2015-08-19 22:17:56

【问题描述】：

我一直在尝试在我的 EB 工作人员上实施一项 cron 作业。

部署时我的 EB CLI 显示“错误：更新环境操作已完成，但出现错误。”

我的 yaml 似乎解析得很好，在我的 EB 事件列表中，我看到“从 cron.yaml 成功加载 1 个计划任务”这一行。

version: 1
cron:
 - name: "cron"
   url: "/cron"
   schedule: "* * * * *"

我查看了 eb-activity.log 并且有这个问题：

Activity execution failed, because: User: arn:aws:sts::550612933446:assumed-role/WorkerTierRole_KK/i-5fe79aa0 is not authorized to perform: dynamodb:UpdateItem on resource: arn:aws:dynamodb:us-east-1:550612933446:table/awseb-e-jcrjmidtsu-stack-AWSEBWorkerCronLeaderRegistry-1GVA6A4AV0YDW - (Aws::DynamoDB::Errors::AccessDeniedException) (ElasticBeanstalk::ExternalInvocationError)
caused by: User: arn:aws:sts::550612933446:assumed-role/WorkerTierRole_KK/i-5fe79aa0 is not authorized to perform: dynamodb:UpdateItem on resource: arn:aws:dynamodb:us-east-1:550612933446:table/awseb-e-jcrjmidtsu-stack-AWSEBWorkerCronLeaderRegistry-1GVA6A4AV0YDW - (Aws::DynamoDB::Errors::AccessDeniedException) (Executor::NonZeroExitStatus)

这也是我在日志中发现的：

2015-06-04T02:17:19Z schedule-parser: Successfully loaded 1 scheduled tasks from file /opt/python/current/app/cron.yaml .
2015-06-04T02:17:19Z init: User: arn:aws:sts::550612933446:assumed-role/WorkerTierRole_KK/i-254d00f5 is not authorized to perform: dynamodb:UpdateItem on resource: arn:aws:dynamodb:us-east-1:550612933446:table/awseb-e-jcrjmidtsu-stack-AWSEBWorkerCronLeaderRegistry-1KMJ9BLOVIUSJ (Aws::DynamoDB::Errors::AccessDeniedException)
    at /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.1.0/gems/aws-sdk-core-2.0.10/lib/seahorse/client/plugins/raise_response_errors.rb:15:in `call'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.1.0/gems/aws-sdk-core-2.0.10/lib/aws-sdk-core/plugins/dynamodb_simple_attributes.rb:112:in `call'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.1.0/gems/aws-sdk-core-2.0.10/lib/seahorse/client/plugins/param_conversion.rb:22:in `call'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.1.0/gems/aws-sdk-core-2.0.10/lib/aws-sdk-core/plugins/response_paging.rb:10:in `call'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.1.0/gems/aws-sdk-core-2.0.10/lib/seahorse/client/request.rb:70:in `send_request'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.1.0/gems/aws-sdk-core-2.0.10/lib/seahorse/client/base.rb:215:in `block (2 levels) in define_operation_methods'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.1.0/gems/aws-sqsd-2.0/vendor/AWSMACLE/lib/leader_election/storage_manager.rb:81:in `update_registration'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.1.0/gems/aws-sqsd-2.0/vendor/AWSMACLE/lib/leader_election/storage_manager.rb:19:in `verify_table'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.1.0/gems/aws-sqsd-2.0/vendor/AWSMACLE/lib/leader_election/daemon.rb:37:in `initialize'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.1.0/gems/aws-sqsd-2.0/vendor/AWSMACLE/lib/leader_election.rb:8:in `new'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.1.0/gems/aws-sqsd-2.0/vendor/AWSMACLE/lib/leader_election.rb:8:in `create'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.1.0/gems/aws-sqsd-2.0/lib/aws-sqsd/cron.rb:241:in `leader_election_daemon'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.1.0/gems/aws-sqsd-2.0/lib/aws-sqsd/cron.rb:30:in `initialize'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.1.0/gems/aws-sqsd-2.0/lib/aws-sqsd/daemon.rb:44:in `new'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.1.0/gems/aws-sqsd-2.0/lib/aws-sqsd/daemon.rb:44:in `initialize'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.1.0/gems/aws-sqsd-2.0/bin/aws-sqsd:34:in `new'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.1.0/gems/aws-sqsd-2.0/bin/aws-sqsd:34:in `start'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.1.0/gems/aws-sqsd-2.0/bin/aws-sqsd:83:in `launch'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.1.0/gems/aws-sqsd-2.0/bin/aws-sqsd:111:in `<top (required)>'
    from /opt/elasticbeanstalk/lib/ruby/bin/aws-sqsd:23:in `load'
    from /opt/elasticbeanstalk/lib/ruby/bin/aws-sqsd:23:in `<main>'

我已经尝试重建我的环境，但没有任何区别。

似乎这个错误超出了我的控制（希望不是这种情况，我犯了一个简单的错误），并且是一个关于它如何处理 cron 作业的 EB 问题。我没有任何 dynamodb 的 :)

非常感谢您的帮助， 菲尔

【参考方案1】：

cron worker 在后台使用一个小的 dynamo db 表来确保您的 Auto Scaling 组中只有一个实例执行 cron 任务。因此，您需要更新您的角色策略以包含相关的 dynamo db 权限。

【讨论】：

权限需要在与您用于环境的 IAM 实例配置文件相关联的角色上。您是说您拥有 IAM 用户或 IAM 实例配置文件的权限吗？实例配置文件角色通常命名为“aws-elasticbeanstalk-ec2-role”（如果您创建了具有不同名称的角色，可能会有所不同）。在此处检查 IAM 实例配置文件所需的权限：docs.aws.amazon.com/elasticbeanstalk/latest/dg/…

很高兴它成功了！您的环境的健康状况非常严重，因为正如您的 HTTP POST 消息所示，您的应用程序正在返回 HTTP 500 响应代码。严重健康可能还有其他原因，但鉴于数据，这似乎是事实。您需要查看您的应用程序日志以找出 delete_expired_files 失败的原因。您可以向您的应用程序添加额外的日志记录，以查看它在哪里失败。可能它会引发未捕获的异常，这就是您在代理日志中收到内部服务器错误的原因。您可以 SSH 到您的实例并查看您的应用程序日志吗？

实际上，这只是工作层守护进程记录它从您的应用程序获得 HTTP 500 响应的日志。您需要将日志记录添加到您实施 delete_expired_files 的应用程序中，以查看它失败的原因。您是否在源代码中配置了日志记录？你在哪里记录东西？

您使用的是哪个解决方案堆栈？您需要在应用程序中记录一些内容，然后配置 beanstalk 以捕获您的日志。您可以在应用程序源代码的 /var/log 中创建日志文件，然后从环境仪表板获取完整日志（不仅仅是快照）

是的，您应该从您的 delete_expired_files 函数创建日志以查看它是否正在执行。如果它正在执行，日志将告诉您它失败的错误。我会跟进另一个问题。