RGW 服务端加密爬坑记

RGW 服务端加密爬坑记

参考了官方文档,决定采用 Customer-Provided Keys(Amazon SSE-C)方式进行加密

官网地址: http://docs.ceph.com/docs/master/radosgw/encryption/

使用boto3,测试用例如下

import boto3
import os

BUCKET = 'test-bucket'
KEY = os.urandom(32)
s3 = boto3.client('s3',
                  endpoint_url='http://xx.xx.xx.xx',
                  aws_access_key_id='xxxx',
                  aws_secret_access_key='xxxx')

print("Uploading S3 object with SSE-C")

s3.put_object(Bucket=BUCKET,
              Key='encrypt-key',
              Body=b'foobar',
              SSECustomerKey=KEY,
              SSECustomerAlgorithm='AES256')
print "Done"

print("Getting S3 object...")

response = s3.get_object(Bucket=BUCKET,
                         Key='encrypt-key',
                         SSECustomerKey=KEY,
                         SSECustomerAlgorithm='AES256')
print("Done, response body:")
print(response['Body'].read())

第一轮尝试

发现报错提示如下

botocore.exceptions.ClientError: An error occurred (InvalidRequest) when calling the PutObject operation: Unknown

InvalidRequest 也就是说提交的参数不对,于是抓包对比,截图如下

Response 的内容如下

<?xml version="1.0" encoding="UTF-8"?><Error><Code>InvalidRequest</Code><BucketName>test-bucket</BucketName><RequestId>tx00000000000000000000c-005b3ae2a0-62db-default</RequestId><HostId>62db-default-default</HostId></Error>

同时参考官网的文档https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerSideEncryptionCustomerKeys.html,发现请求Request Header内容已经符合了AWS Using SSE-C的标准,所以很费解!

第二轮尝试

由于使用的是12.2.4做测试,有朋友用12.2.5同样的测试用例通过,怀疑可能是RGW的bug,于是就着手升级测试环境到12.2.5,但是升级完成以后仍然无法报400错误。

第三轮尝试

考虑到朋友那边可能boto3的版本和我不一样,于是又调整了boto3的版本,最终还是400报错。

第四轮尝试

于是在朋友建议下打开debug_rgw=20,发现日志有异常

...
2018-07-03 10:51:09.975043 7efc1642a700  2 req 2:0.001484:s3:PUT /test-bucket/encrypt-key:put_obj:recalculating target
2018-07-03 10:51:09.975047 7efc1642a700  2 req 2:0.001488:s3:PUT /test-bucket/encrypt-key:put_obj:reading permissions
2018-07-03 10:51:09.975049 7efc1642a700  2 req 2:0.001490:s3:PUT /test-bucket/encrypt-key:put_obj:init op
2018-07-03 10:51:09.975050 7efc1642a700  2 req 2:0.001492:s3:PUT /test-bucket/encrypt-key:put_obj:verifying op mask
2018-07-03 10:51:09.975052 7efc1642a700 20 required_mask= 2 user.op_mask=7
2018-07-03 10:51:09.975053 7efc1642a700  2 req 2:0.001495:s3:PUT /test-bucket/encrypt-key:put_obj:verifying op permissions
2018-07-03 10:51:09.975056 7efc1642a700 20 -- Getting permissions begin with perm_mask=50
2018-07-03 10:51:09.975057 7efc1642a700  5 Searching permissions for identity=rgw::auth::SysReqApplier -> rgw::auth::LocalApplier(acct_user=s3test, acct_name=s3test, subuser=, perm_mask=15, is_admin=0) mask=50
2018-07-03 10:51:09.975063 7efc1642a700  5 Searching permissions for uid=s3test
2018-07-03 10:51:09.975063 7efc1642a700  5 Found permission: 15
2018-07-03 10:51:09.975064 7efc1642a700  5 Searching permissions for group=1 mask=50
2018-07-03 10:51:09.975065 7efc1642a700  5 Permissions for group not found
2018-07-03 10:51:09.975066 7efc1642a700  5 Searching permissions for group=2 mask=50
2018-07-03 10:51:09.975066 7efc1642a700  5 Permissions for group not found
2018-07-03 10:51:09.975069 7efc1642a700  5 -- Getting permissions done for identity=rgw::auth::SysReqApplier -> rgw::auth::LocalApplier(acct_user=s3test, acct_name=s3test, subuser=, perm_mask=15, is_admin=0), owner=s3test, perm=2
2018-07-03 10:51:09.975071 7efc1642a700 10  identity=rgw::auth::SysReqApplier -> rgw::auth::LocalApplier(acct_user=s3test, acct_name=s3test, subuser=, perm_mask=15, is_admin=0) requested perm (type)=2, policy perm=2, user_perm_mask=2, acl perm=2
2018-07-03 10:51:09.975074 7efc1642a700  2 req 2:0.001514:s3:PUT /test-bucket/encrypt-key:put_obj:verifying op params
2018-07-03 10:51:09.975076 7efc1642a700  2 req 2:0.001518:s3:PUT /test-bucket/encrypt-key:put_obj:pre-executing
2018-07-03 10:51:09.975093 7efc1642a700  2 req 2:0.001534:s3:PUT /test-bucket/encrypt-key:put_obj:executing
2018-07-03 10:51:09.975112 7efc1642a700 15 supplied_md5_b64=bIEkMCj45FX6YX3V8CMs4Q==
2018-07-03 10:51:09.975117 7efc1642a700 15 ceph_armor ret=16
2018-07-03 10:51:09.975122 7efc1642a700 15 supplied_md5=6c81243028f8e455fa617dd5f0232ce1
2018-07-03 10:51:09.975176 7efc1642a700  5 ERROR: Insecure request, rgw_crypt_require_ssl is set
2018-07-03 10:51:09.975197 7efc1642a700  2 req 2:0.001638:s3:PUT /test-bucket/encrypt-key:put_obj:completing
2018-07-03 10:51:09.975247 7efc1642a700  2 req 2:0.001688:s3:PUT /test-bucket/encrypt-key:put_obj:op status=-2021
2018-07-03 10:51:09.975252 7efc1642a700  2 req 2:0.001693:s3:PUT /test-bucket/encrypt-key:put_obj:http status=400
2018-07-03 10:51:09.975275 7efc1642a700  1 ====== req done req=0x7efc16424110 op status=-2021 http_status=400 ======
2018-07-03 10:51:09.975286 7efc1642a700 20 process_request() returned -2021
2018-07-03 10:51:10.045566 7efc1642a700  1 civetweb: 0x7efc49de4000: 10.13.70.5 - - [03/Jul/2018:10:51:09 +0800] "PUT /test-bucket/encrypt-key HTTP/1.1" 400 0 - Boto3/1.7.24 Python/2.7.10 Darwin/17.6.0 Botocore/1.10.24

其中的ERROR: Insecure request, rgw_crypt_require_ssl is set 引起我的注意,于是检查线上配置

[root@demo]#ceph daemon /var/run/ceph/ceph-client.rgw.demo.asok config show|grep ssl
    "kinetic_use_ssl": "false",
    "rgw_crypt_require_ssl": "true", 
    "rgw_keystone_verify_ssl": "true",
    "rgw_verify_ssl": "true",

发现rgw_crypt_require_ssl为true,于是改到false重启,终于成功。

总结

rgw_crypt_require_ssl=true 是RGW的默认配置,默认配置下只有开启HTTPS才能使用Server-side Encryption,这也是为了安全起见,但是如果在HTTP下面使用Server-side Encryption,则会出现本文中的400错误,而按照400错误给出的提示,错误的原因应该在客户端提交的参数不对,这样就极大的误导了我们,所以才有了上面一轮又一轮的故事。而且最坑爹的是,朋友使用的是vstart脚本启动的测试,vstart环境默认在ceph.conf里面就加上了rgw_crypt_require_ssl=false,看样子社区开发者是知道这个问题,才在测试环境下关闭这个特性,在没有文档说明和仅靠400报错提示的情况下,很多人都容易发生像我这样的爬坑故事。

原文发布于微信公众号 - Ceph对象存储方案(cephbook)

原文发表时间:2018-07-03

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏c#开发者

数据驱动开发For Silverlight WCF RIA1.0 三步曲

数据驱动开发For Silverlight WCF RIA1.0 三步曲 WCF RIA 1.0的正式发布,让Silverlight开发业务应用系统变得更加简...

28040
来自专栏FreeBuf

ATBroker.exe:一个被病毒利用的微软进程

一般情况下,病毒会利用添加启动项、计划任务、服务的方式来实现开机启动,达到留存和活跃的目的。然而,利用atbroker.exe系统进程,实现病毒开机启动的方式并...

16530
来自专栏杨建荣的学习笔记

Data Guard实现故障自动切换(二)(r11笔记第40天)

今天下午我的一个朋友碰到了一个Data Guard的问题,大体是主备网络出现问题,因为环境中配置了自动切换,结果备库就自动切换为了主库,这样就成了“双主”...

440100
来自专栏FreeBuf

技术剖析:海莲花OceanLotus Encryptor样本分析

前言 上周,360发布了海莲花的报告,数据收集,分析,解释,加工方面很能让人折服,但是看了其对所谓OceanLotus Encryptor样本的分析,和我自己观...

22770
来自专栏杨建荣的学习笔记

Data Guard高级玩法:通过闪回恢复failover备库 (r10笔记第7天)

今天看到有一个网友提了一个问题,描述很简短 测试DG时,主库不能宕机,如何测试failover? 其实这个需求从业务层面来说是合理的,一...

36960
来自专栏魏艾斯博客www.vpsss.net

使用服务器安全狗的效果

32950
来自专栏Jerry的SAP技术分享

不同系统里同一Customizing activity的显示差异分析

比如SAP HANA Live Reporting这个Customizing Activity,在System AG3里不可见,但是在另一个系统QHD里却能使用...

18960
来自专栏FreeBuf

“奇幻熊”(APT28)组织最新攻击

近日腾讯御见威胁情报中心在监测Fancy Bear“奇幻熊”组织的攻击活动过程中,发现了其使用的最新攻击样本。下文将详细披露该组织的攻击手法,和各企业一起共同抵...

29180
来自专栏NetCore

微信公众平台快速开发框架 For Core 2.0 beta –JCSoft.WX.Core 5.2.0 beta发布

写在前面 最近比较忙,都没有好好维护博客,今天拿个半成品来交代吧。 记不清上次关于微信公众号快速开发框架(简称JCWX)的更新是什么时候了,自从更新到支持.Ne...

29380
来自专栏技术小黑屋

Gmail托管邮箱发邮件认证失败

Gmail是一款很优秀的邮件工具,我一直使用Gmail来托管公司的邮箱,利用最棒的过滤器进行过滤垃圾邮件。前段时间公司邮箱密码更换,使用了新的密码后导致了只能收...

20910

扫码关注云+社区

领取腾讯云代金券