encrypted EBS caused AWS EC2 failed to start by Lambda

    前不久因为安全方面的考虑，把AWS EC2挂载的EBS硬盘做了加密处理，具体就是先给未加密non-encrypted的EBS硬盘创建一个snapshot，然后在KMS里创建了一个新的key，再从那个未加密的snapshot来copy一个新的snapshot，copy的时候选KMS里的key来做加密，这样就得到了一个加密过的snapshot，最后再用这个加密过的snapshot创建一个新的EBS，来替换原先EC2挂载的未加密的EBS硬盘，这样就完成了对EC2硬盘的加密。

    当时做的很顺利，做完看看貌似EC2一切正常，也就放那儿用了。

    但是最近发现，用来定时启动这些EC2的Lambda function貌似失效了，具体表现为可以被Lambda停机，但不能被Lambda启动了。

    查了一下，发现Lambda自己是执行成功了的，打印Lambda的instance.start()的response，可以看到Lambda的确已经成功发出了启动的event：

 [{'StartingInstances': [ {'CurrentState': {'Code': 0, 'Name': 'pending'}, 'InstanceId': 'i-aaaaa', 'PreviousState': {'Code': 80, 'Name': 'stopped'}}, {'CurrentState': {'Code': 0, 'Name': 'pending'}, 'InstanceId': 'i-bbbbbb', 'PreviousState': {'Code': 80, 'Name': 'stopped'}}], 'ResponseMetadata': {'RequestId': 'a15ff429-06ae-4214-b29a-982e7958e8e9', 'HTTPStatusCode': 200, 'HTTPHeaders': {'x-amzn-requestid': 'a15ff429-06ae-4214-b29a-982e7958e8e9', 'cache-control': 'no-cache, no-store', 'strict-transport-security': 'max-age=31536000; includeSubDomains', 'content-type': 'text/xml;charset=UTF-8', 'content-length': '916', 'date': 'Tue, 04 Jun 2024 05:39:06 GMT', 'server': 'AmazonEC2'}, 'RetryAttempts': 0} }]

    可以看到，Lambda已经发出了让EC2从stopped启动到pending的event，按理说EC2从pending就会转到start状态。但问题是EC2并没有变成started，而是一直保持stopped状态。

    被这个问题困扰了两周多，搜了AWS自己Lambda的文档，也搜了stack overflow上的相关问题，大多给出的回答都是检查Lambda是否被正确配置、是否被触发这些。

    走了很多弯路，最后在AWS re:Post上发帖提问，得到了AWS技术专家Didier Durand的回答，他建议去查一下CloudTrail里API调用是否成功。

    于是按照建议去查了CloudTrail，Lambda的event记录倒是没啥问题，但是紧挨着lambda event，有一条同样发给这个account的CreateGrant的记录，里面报了一个access denied的错：

{ ... "errorCode": "AccessDenied", "errorMessage": "User: arn:aws:sts::1111111:assumed-role/aaaaaa-lambda-start-instance-service-role/aaaaaa-start-ec2-on-monday-morning is not authorized to perform: kms:CreateGrant on resource: arn:aws:kms:us-east-1:1111111:key/8f702ef1-61cb-4ddc-a369-bb71c004955d because no identity-based policy allows the kms:CreateGrant action", } 

    这个KMS key一下子让我想起来了之前做的EBS硬盘加密的操作，当时用的key就是这个key。于是打开KMS页面，把Lambda的IAM role加到了这个KMS key的policy里面。再去试lambda，果然这次CloudTail的CreateGrant不报错了，EC2也启动起来了。

评论

发表评论

此博客中的热门博文

Windows上调试C/C++程序时自动产生coredump的设置方法

1. 安装Windows debug tool，全部使用默认安装选项即可 搜索 Windbgx86_v6.12.2.633.1395371577.msi 并下载 或者也可到微软官网上下载windows调试工具，windbg也在其中： https://developer.microsoft.com/zh-cn/windows/hardware/download-windbg 注：此版本为32位版，但在32位和64位操作系统上均能使用 2. 将windbg.exe设置为默认debugger工具： 起一个cmd，进入windbg的安装目录，默认是C:\Program Files (x86)\Debugging Tools for Windows (x86)\ 然后执行C:> windbg.exe -I 注意-I必须大写 然后windbg的程序主窗口会自动打开，并且弹出一条信息windbg已经被成功设置为默认的debugger云云... 点确定后窗口会自动关闭，至此设置成功 3. 创建一个存放coredump文件的目录 D:\Dump 4. 修改系统注册表，捕获异常崩溃时自动产生Coredump文件：   1) regedit打开注册表，找到注册表项，先备份：      64位系统： HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug      32位系统： HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug   2) 修改Auto的值，原来的默认值为0不启动debugger，修改为1默认启动debugger   3) 修改Debugger的值，如果上述第2步执行成功，那么此处的值应该已经被改为了"C:\Program Files (x86)\Debugging Tools for Windows (x86)\windbg.exe" -p %ld -e %ld -g      现在需要将其修改为导出并保存co...
阅读全文

利用Gitlab的Jira issue tracker实现Jira issue自动根据Gitlab commit/merge更新状态

图片
  首先一个参考文档： http://git.jd.com/help/user/project/integrations/jira   其次此文档中与我的jira版本和gitlab版本实际差异还是较大，记一下趟过的坑吧： 1. jira上的配置：   我用的是jira7.3.8，配置用户组权限处和上文不一样，设置group权限是从管理->系统->安全->全局权限进去设置，而且没有显示有jira-core的，于是将gitlab-developers设成了[JIRA 管理员]的权限 2. Gitlab上的配置：    1) Gitlab配置需有repo的master权限    2) 配置的时候从integration进去，是点击Jira转进link，而不是点前面的电源开关的符号，本废在这上面竟然被block了一下-_-b    3) JIRA API URL直接填与上面的Web URL一样就行    4) Transition ID这个解释起来比较复杂。首先，用上文的方法去取，我得到的是这样的输出： $  curl -s http://gitlab:gitlab@cloudjira.jd.com/rest/api/2/issue/TEST-3/transitions { "expand":"transitions", "transitions": [ {"id":"191", "name":"on-going", "to": {"self":"http://cloudjira.jd.com/rest/api/2/status/10301", "description":"", "iconUrl":"http://cloudjira.jd.com/images/icons/statuses/generic.png", "name":"Develope...
阅读全文

go用xorm去update数据库的一个坑

    最近写API服务比较多，一般试验性质的用python flask简单又快，需要稍微考虑点儿并发性能的，那还是用go来写咯。API服务一般都要落盘写库，随便选了个xorm来写mysql数据库。     但是最近碰到一个有点儿奇怪的现象，调用端报告偶有数据没有更新的现象。回头去查代码，写库这段逻辑如下：  if _, err = session.Where("col1 = ?", d.col1).Update(d); err != nil {     glog.Infof("has result col1:%s updated!", d.col1)     return }     一眼就能看明白的一个调用，看不出有啥毛病啊-_-b     试图重现也没能重现，于是只能加debug log以图能保存下次发生时的事发现场。结果过了一个月果然又出现了。确实是这段代码更新表中数据时出错了。     后来搜xorm文档时发现了这么一个Q&A: https://www.kancloud.cn/kancloud/xorm-manual-zh-cn/56018 我的struct里面包含bool类型，为什么它不能作为条件也没法用Update更新？ 答：默认bool类型因为无法判断是否为空，所以不会自动作为条件也不会作为Update的内容。可以使用UseBool函数，也可以使用Cols函数 engine . Cols ( "bool_field" ) . Update ( & Struct { BoolField : true } ) // UPDATE struct SET bool_field = true       深受启发啊！我出问题的数据虽然不是bool，但是0！于是又去查了下文档，发现xorm的帮助文档在一个角落里果然提到了bool false, int 0, 空nil都 默认不会更新 ！好坑啊！这种update默认方式的设计简直是反人类啊！    ...
阅读全文