Ceph安全体系概览

用户1260683

发布于 2019-07-30 15:48:13

2.3K0

发布于 2019-07-30 15:48:13

文章被收录于专栏：Ceph对象存储方案Ceph对象存储方案

Ceph安全体系概览

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

CephX 认证体系

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

"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数据存储加密

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的时候启动磁盘级的加密

ceph-volume lvm create --dmcrypt

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

MGR模块的插件安全

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

[root@demohost supdev]# ceph mgr module ls
{
    "enabled_modules": [

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

restful模块功能列表

/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

默认访问需要身份认证

[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接口

[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

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

[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发送写入请求。针对整个写入过程，大概有下面几种攻击方式

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

用户数据安全

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