前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Ceph安全体系概览

Ceph安全体系概览

作者头像
用户1260683
发布2019-07-30 15:48:13
2.4K0
发布2019-07-30 15:48:13
举报
文章被收录于专栏:Ceph对象存储方案

Ceph安全体系概览

安全是整个存储必不可少的一环,但是很少有人能够比较全面的总结一下Ceph的安全体系,于是老司机在这里“鬼话连篇”。

CephX 认证体系

默认情况下整个ceph内部服务组件之间都是启用了cephx认证的,每个服务实例都会有一个keyring,各个服务之间进行通信会使用keyring进行消息内容签名,从而避免“中间人攻击”,这里需要注意的是传输的消息内容是不加密的(明文传输),传输的数据包内容仍然可以通过网络嗅探一类方式截获,官方也意到该问题,并且在新版本的消息通信模块上做了更新并堵上了这一块漏洞。

代码语言:javascript
复制
"auth_client_required": "cephx",
"auth_cluster_required": "cephx",
"auth_service_required": "cephx",

http://docs.ceph.com/docs/master/rados/configuration/auth-config-ref/ http://docs.ceph.com/docs/master/architecture/#high-availability-authentication

OSD数据存储加密

代码语言:javascript
复制
LUKS (Linux Unified Key Setup)是 Linux 硬盘加密的标准。 通过提供标准的磁盘格式,它不仅可以促进发行版之间的兼容性,还可以提供对多个用户密码的安全管理。 与现有解决方案相比,LUKS 将所有必要的设置信息存储在分区信息首部中,使用户能够无缝传输或迁移其数据。

OSD在filestore时代就已经通过LUKS支持磁盘级别的加密,之后Bluestore使用的LVM仍然沿用LUKS方案,但是有几个需要注意的细节

  • only LUKS (version 1) is used
  • Logical Volumes are encrypted, while their underlying PVs (physical volumes) aren’t
  • Non-LVM devices like partitions are also encrypted with the same OSD key

通过使用ceph-volume命令,在创建OSD的时候启动磁盘级的加密

代码语言:javascript
复制
ceph-volume lvm create --dmcrypt

参考资料:http://docs.ceph.com/docs/mimic/ceph-volume/lvm/encryption/

MGR模块的插件安全

MGR的出现带来了很多插件,极大降低了Ceph的运维与集成难度,但是同时默认启用的restful存在一定的安全隐患,一方面会泄露集群信息,另一方面一些危险性的操作还会容易被入侵滥用。

代码语言:javascript
复制
[root@demohost supdev]# ceph mgr module ls
{
    "enabled_modules": [

        "restful",
        "status"
    ],
    "disabled_modules": [
        "balancer",
        "dashboard",
        "influx",
        "localpool",
        "prometheus",
        "selftest",
        "zabbix"
    ]
}

restful模块功能列表

代码语言:javascript
复制
/config/cluster: GET
/config/osd: GET, PATCH
/crush/rule: GET
/mon: GET
/osd: GET
/pool: GET, POST
/pool/<arg>: DELETE, GET, PATCH
/request: DELETE, GET, POST
/request/<arg>: DELETE, GET
/server: GET

默认访问需要身份认证

代码语言:javascript
复制
[root@demohost supdev]# curl -k https://localhost:8003/
{
    "api_version": 1,
    "auth": "Use \"ceph restful create-key <key>\" to create a key pair, pass it as HTTP Basic auth to authenticate",
    "doc": "See /doc endpoint",
    "info": "Ceph Manager RESTful API server"
}
[root@demohost supdev]# curl -k https://localhost:8003/osd/1
{
    "message": "auth: No HTTP username/password"
}

创建用户,并使用指定用户访问restful接口

代码语言:javascript
复制
[root@demohost supdev]# ceph restful create-key admin
203b7fae-85ba-45a7-aaa7-d42593aa7307
[root@demohost supdev]# curl -k https://localhost:8003/osd/1 -u admin:203b7fae-85ba-45a7-aaa7-d42593aa7307
{
    "cluster_addr": "192.168.60.210:6806/507000",
    "down_at": 54,
    "heartbeat_back_addr": "192.168.60.210:6807/507000",
    "heartbeat_front_addr": "192.168.60.210:6808/507000",
    "in": 1,
    "last_clean_begin": 28,
    "last_clean_end": 53,
    "lost_at": 0,
    "osd": 1,
    "pools": [
        1,
        2,
        3,
        4,
        5,
        6,
        7,
        8,
        9,
        10,
        11
    ],
    "primary_affinity": 1.0,
    "public_addr": "192.168.60.210:6805/507000",
    "reweight": 1.0,
    "server": "demohost",
    "state": [
        "exists",
        "up"
    ],
    "up": 1,
    "up_from": 56,
    "up_thru": 169,
    "uuid": "d2eed5f8-fca6-595d-8e00-d20487e23307",
    "valid_commands": [
        "scrub",
        "deep-scrub",
        "repair"
    ],
    "weight": 1.0

生产上最好通过下面的方式关闭该插件

代码语言:javascript
复制
[root@demohost supdev]# ceph mgr module disable restful
[root@demohost supdev]# ceph mgr module ls
{
    "enabled_modules": [
        "status"
    ],
    "disabled_modules": [
        "balancer",
        "dashboard",
        "influx",
        "localpool",
        "prometheus",
        "restful",
        "selftest",
        "zabbix"
    ]
}

如果关闭不了,那么也要做到以下几点

  • 使用HTTPS方式认证,最好有正式的签名证书,不要用自签名那种。
  • 严格限制创建的用户数量,同时控制好相应的账号密码不要被泄露和滥用。
  • 对restful接口,比如默认的8003开启防火墙白名单限制,只允许指定IP的访问。

RGW安全防护

RGW默认情况下会直接与Client进行交互,走的也是HTTP,因此有条件的一定要用到HTTPS,并且不要使用自签名证书,如果暴露在公网或者其他安全性比较敏感的环境,最好在RGW前端架设一层防火墙或者其他安全设备对流量进行清洗过滤。

接下来再讲一讲对RGW的网络攻击类型,RGW的写入是一个非常值得关注的风险点,也是最容易遭受攻击的部分。简单一句话介绍,RGW在接收到客户端写入请求的时候,会开启内存buffer用于缓存数据,只有当整个request请求数据全部接收完成,才会往后端OSD发送写入请求。针对整个写入过程,大概有下面几种攻击方式

  1. "飞头"攻击 针对"100 continue"特性,整个客户端请求可以分为2部分进行,先发送header部分,之后再传输Body内容,如果客户端先发送header,之后再以极慢的速度传输Body内容,你会发现RGW的网络连接数会被极大的耗尽…
  2. "胖体"攻击 客户端传输一个极大的body(默认单request最大5G),然后开很多个并发,很快你就会发现你的buffer内存耗尽,最终RGW节点的内存被这些胖子们吃干耗尽…
  3. "垃圾回收风暴"攻击 客户端频繁覆盖写同一个object或者频繁大量删除object,最终导致RGW在执行GC的时候耗尽磁盘的IO,影响集群的正常数据访问。
  4. 其他 灵活组合上面几种攻击方式,对RGW进行惨无人道的蹂躏… 至于如何防护上面讲到的攻击,这里要结合具体的业务场景和硬件环境,限于篇幅就不详细展开。最后补充一句话,任何方式去提升系统安全都是有代价的。

用户数据安全

这里只讨论RGW场景,RBD和Cephfs就不再展开了。当用户将数据存储到Ceph的时候,就面临一些安全性问题,比如数据比较敏感,必须加密,但是限于客户端有限的条件,只能把加密放服务端。所以这个时候就需要在服务端启用加密特性,关于如何启用服务端加密就不再这里展开,之前有文档介绍这一块内容。另外一块安全的需求,就是用户需要对上传的数据进行安全扫描,比如用户上传进来的文档、软件包等需要经过病毒扫描,以确定其安全性。RGW原生是没有这块支持的,但是可以通过其他方式去实现,这里介绍一种通用解决方案。

安全扫描——异步方式

客户端通过启用PubSub 模块,采用兼容S3 Bucket Notifications API的方式完成异步通信,具体内容如下图。

参考:http://docs.ceph.com/docs/master/radosgw/s3-notification-compatibility/

最后

限于时间和能力有限,基本上Ceph安全相关的内容就总结到这里,后面有时间再慢慢补充。

欢迎订阅本公众号cephbook,干货满满,专业老司机教你搞"对象"存储

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-06-13,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 Ceph对象存储方案 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • Ceph安全体系概览
    • CephX 认证体系
      • OSD数据存储加密
        • MGR模块的插件安全
          • RGW安全防护
            • 用户数据安全
              • 最后
              相关产品与服务
              数据保险箱
              数据保险箱(Cloud Data Coffer Service,CDCS)为您提供更高安全系数的企业核心数据存储服务。您可以通过自定义过期天数的方法删除数据,避免误删带来的损害,还可以将数据跨地域存储,防止一些不可抗因素导致的数据丢失。数据保险箱支持通过控制台、API 等多样化方式快速简单接入,实现海量数据的存储管理。您可以使用数据保险箱对文件数据进行上传、下载,最终实现数据的安全存储和提取。
              领券
              问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档