presto权限管理
官方文档-》https://prestodb.github.io/docs/current/security/built-in-system-access-control.html
presto的权限管理,分为catalog配置、schema配置、principal规则,分别管理着不同维度的权限设置。使用的前提是在etc目录下,创建access-control.properties
文件,并写入如下配置
# 权限控制配置方式,这个配置可以直接修改为对应的权限枚举值,但是造成的效果就是所有catalog使用同一个权限
access-control.name=file
# 文件路径
security.config-file=etc/rules.json
# 自动刷新权限配置的时间
security.refresh-period=10s
catalog配置
catalog配置,是用来管理不同用户能够访问那个catalog,你可以在rules.json
文件,写入如下内容。使得只允许用户admin访问mysql和system,允许所有用户访问hive目录,允许用户alice只读访问postgresql目录
{
"catalogs": [
{
"user": "admin",
"catalog": "(mysql|system)",
"allow": "all"
},
{
"user": "alice",
"catalog": "postgresql",
"allow": "read-only"
},
{
"catalog": "hive",
"allow": "all"
}
]
}
在该文件中配置项的含义如下:
catalog:当前规则生效在那个catalog上,可选配置,默认代表所有。选定某个或者⼏个catalog,可⽤正则匹配,默认为
.*
代表所有
user:代表⽤户,可选配置,也可以用正则,默认为.*
代表所有
allow:必选配置,默认为none,可选值有三个 all(所有权限),read-only(只可读),none(没有任何权限)
catalog配置使用时需要注意的是:
1. 开启权限控制后,如果你只放一个空的规则⽂件或者存在没有为它相应规则的catalog,presto将视为任何用户都没有对应的catalog访问权限
2. 一定要注意权限记录的唯一性,官网上说可以从上到下随着规则识别的顺序覆盖,但是实际操作后发现覆盖效果不明显,因此实际使用中最好是不要图省事,不同的catalog和不同的用户之间的权限需求都一条一条的写
3. 布尔true和false也可以作为allow的值,true映射到all,false映射到none。
schema配置
schema配置,按照官网的说法是用来规定,不同数据源对应的schema,或者说数据库,对于用户来说是否是owner。也就是说,是否在presto执行上来讲拥有对应schema的元数据操作权限(DROP SCHEMA、ALTER SCHEMA 、CREATE SCHEMA)
但是!!!
在实际使用上经过测试发现,这玩意然并卵,即使配置了也不起效,而且presto在业内通常被使用在即席查询上,不会用它来操作复杂的元数据,最多create table as select一下,并且presto的catalog配置用到的用户,既然存在,就一定被各数据源内部控制好了权限,就拿mysql来说,不可能用root做catalog访问用户,所以无论是从业务层面还是技术层面讲,这个东西可以忽略。
当然网上其他文献中,你可以找到table规则,用来和schema做配合达到细化的作用,这个我用本地测试环境试了一下,根据结果来开,网上提到的table规则大概率它的源头是某个二次开发后的产物,后续被无脑复制导致信息失真了,总之开源默认自带的权限控制类com.facebook.presto.security.FileBasedSystemAccessControlRules
中没有相关代码,而且就算有,还有一样的道理,商用场景让你用presto管理元数据的可能小到几乎不可能
言归正传,配置上,只需要在文件中加入如下的信息,即可达到让用户admin拥有所有schema的owner权限,将所有用户视为default的owner,并防止用户guest拥有任何schema的owner权限
{
"catalogs": [
{
"allow": true
}
],
"schemas": [
{
"owner": false
},
{
"user": "admin",
"schema": ".*",
"owner": true
},
{
"schema": "default",
"owner": true
}
]
}
配置项含义
1. user(可选):与用户名匹配的正则表示式。默认为.*。
2. schema(可选):与模式名称匹配的正则表示式。默认为.*。
3. owner(必填):布尔表示用户是否被视为schema的所有者,默认为false。
需要注意的点和catalog配置类似
principal规则
principal规则,一般不使用,它是用来与其他安全服务配合时,确保只有经过授权的安全主体才能访问特定的资源或执行特定的操作。Presto支持多种身份验证方式,如Kerberos、LDAP/AD等。通过配置principal规则,系统可以识别并验证这些安全主体(principal)的身份,并映射成对应的用户(user或者principal_to_user),并且可以按照需要关闭或允许授权(allow)。使用案例可以去看官网