Status quo
As Nacos is in production use, users require a basic login system to verify user identity, thereby reducing security risks.
Claim
- I hope Nacos supports a simple admin account and password, and the password can be modified.
- I hope to support an SSO mechanism like LDAP/SAML
Discussion
- How does the Nacos login system need to do, support a simple username password, or need to get in touch with each company's SSO system?
- What login system is used by your company (LDAP/SAML/self own set of your own login system/each system has a set of account login system)
- I hope that Nacos will get through with each company's login system. What is the expected solution?
Associate issue
160 #350 #348 #327 #269 #232
现状
随着Nacos在生产使用，用户要求有基本登录系统验证用户身份，从而降低安全风险。
要求
- 希望Nacos支持一个简单的一个admin账号和密码，密码可修改
- 希望支持LDAP/SMAL这样的SSO机制
讨论
- Nacos登录系统需要做到哪个程度，支持一个简单用户名密码，还是需要跟每个公司的SSO系统打通
- 贵公司用的什么登录系统（LDAP/SMAL/自己又一套自己的登录系统/每个系统有一套账号登录系统）
- 期望Nacos怎么跟每个公司的登录系统打通，期望的方案是什么样的
关联issue
160 #350 #348 #327 #269 #232
yanlinly
All 26 comments
支持 LDAP 就已经可以了，类似 社区里面的 jenkins, gitlab, rancher 之类，都是优先支持 LDAP；
更重要的是，需要对 Nacos 现有的所有功能就行权限和角色的划分，是给到所有权限，让用户自己创建角色来划分，还是不开放权限，直接内置角色来划分的问题了。
gumutianqi
on 3 Dec 2018
个人觉得Nacos不要太臃肿了,简单高效就行,与Nacos之外的其他东西耦合越少越好, 所以简单的登录系统就行,甚至帐号密码就放配制文件,可以简单的配制下权限即可(权限配制文件复杂点没问题,毕竟Nacos用户都是技术人员)
在我眼中的Nacos 就是一个高效的配制中心/注册中心. 应该是其他使用它的系统是适应它,而不是它去适应其他
KeRan213539
on 3 Dec 2018
- 支持下钉钉扫码登录
- 可以配置用户与应用的关联
- 对应用；或者针对dataId，group配置规则进行权限的控制
irusist
on 3 Dec 2018
- Should support read role,write role for differen configuration item(dataId)
- As config platform,should support configure permissions for different configuration groups.
dtcui
on 3 Dec 2018
支持 LDAP ，类似 jenkins就行
jiangbin216
on 3 Dec 2018
先来个简单的用户、密码验证
chiangyn
on 3 Dec 2018
分权限这个事应该比账号更急切，一旦可以分权限了，就可以把编辑权限分出去，管理员只做审核。否则编辑和审核都只能管理员做。
anjia0532
on 3 Dec 2018
我觉得先来个简单的用户名、密码登陆就可以。默认一个admin管理用户，可以创建其他子用户，可以分配权限，毕竟有些配置的修改最好有权限。
heshouyou
on 3 Dec 2018
权限系统比账号更重要吧。这样配置中心里，敏感级别高的配置就只能运维人员修改，业务逻辑变动频繁等敏感级别低的配置可以由开发人员自行修改。
dntbeSris
on 3 Dec 2018
提供权限必要的数据结构，关于Id,Name等信息及验证方式，提供接口让各个公司实现；或者提供callback url 对接Http接口。
foamfish
on 3 Dec 2018
我也觉得简单的支持下LDAP就够了，目前很多开源产品都是加入对LDAP的支持，不需要啥单独定制，一些简单的配置就够了
wetsion
on 3 Dec 2018
- 个人觉得，权限比账号重要，意味着，如果没权限的话，账号很鸡肋，前期解决方案，可以由1个人运维或者用nginx的basic auth或黑白名单进行管控。
- 权限的话，最低应该支持到namespace级别，如果能控制到字段更佳(ACL)，甚至如果支持了密文功能，最好能支持，是否能够查看原始密文。
- 安全方案应该向后兼容，比如，通过https双向证书，或者安全模式可选择，避免破坏性更新，群内有说使用nginx做前置https卸载，会导致部分仍旧使用apache，iis等web server的对接问题。所以建议软件级安全加固，比如，使用dataId或者自定义key来做不对称加解密。
- 关键密文应该支持加解密，比如jce,但是jce需要向jdk的bin里加jce的包，会有运维方面的困难(比如，对于docker应用问题不大，但是对于传统的一些war发布的，可能较难)，并且对于非java的支持也不好，所以，最好还是nacos自己实现加解密
- 建议增加配置文件的继承功能，比如，我有10个项目，每个20个配置项，其中10个都一样的，理论上我只需要继承10个common的，每个单独配置10个不一样的就行了
- 建议nacos server 像SC config server似的，增加filesystem和git的读取配置文件的方式，一个好处是，支持多种datasource,另外一个好处是，可以配合gitlab/github的MR/PR的功能实现审核，配合CI/CD可以实现编辑和发布分离的目的。意味着账号和审核不再成为阻止nacos的最大的拦路虎了。可以预留到1.0时精心打磨权限和账号，防止出一个不成熟的半成品，被吐槽难用。
- 我们应该假设用户在安全方面的心智是小白水平，意味着开箱即用的默认配置，应该满足大多数安全场景，而不应该做类似，傻子都知道，不应该放公网，放公网最起码应该自己配置强口令等假设。
- 说句题外话，配置中心和注册中心，是否真的需要控制台、可视化配置？大多的运维工具都是优先完善功能，然后在稳定后再讲究易用性(UI)，因为很多人会习惯于将API或SDK集成到现有系统里，因为做了权限后，意味着普通开发人员，leader和运维人员都会用nacos进行配置，集成到现有的系统里肯定是最合适的，否则会导致学习和推广成本的上升，毕竟没人喜欢切换不同系统进行开发。
anjia0532
on 3 Dec 2018
- a simple admin account and password, and the password can be modified.
- support LDAP
small starter up companies doesn't have LDAP :)
jun1st
on 3 Dec 2018
- Nacos 本身只需要专注于配制中心/注册中心，简单的账号密码登录就可以。权限也不需要管理。
提供足够好用的OPEN API & SDK。更复杂的登录需求或者权限需求可以让用户自行扩展。
如果想进一步提升体验，减少重复造轮子，可以提供类似于Jenkins插件机制。鼓励社区贡献,一些通用好用的插件可以进入官方推荐。
tao1991123
on 3 Dec 2018
插件+1
anjia0532
on 3 Dec 2018
从源码上看到，openapi 有很多 ， 基本上分为3类， 一种是console使用， 一种是给外部接入方直接使用，例如sdk， 一种是集群内部使用， 例如raft相关的api， 初期如果能适当地进行分类， 有针对地提供权限控制扩展点会很有用
nanamikon
on 4 Dec 2018
eureka也没有权限，需要的就自己定制，毕竟权限管理说小可以小，说大可以很大，nacos只是一平台，但是权限往往设计到业务
kukukakiki
on 5 Dec 2018
翻了一下源码，nacos用的httpclient+httpurlconn混用的，不支持basic auth。意味着nginx basic自己玩的，需要改源码，并且这种工具类居然不通用，意味着，你得改好几个地方，还得确保没漏掉。而且源码里有个地方写死的isSSL=false,目测也不支持https双向认证。所以基于ssl的安全方案也没得整。意味着，千万别把nacos搞成公网可访问，即使局域网也需要注意局域网隔离。防止内网渗透
anjia0532
on 5 Dec 2018
Nacos本身就不需要登陆验证系统了吧，专注于目标。最多的话就是主页拦截，跳转到某个地方验证通过后回调回来，根据返回的用户、角色登陆进去即可。至于具体的权限就由各业务方自己去实现吧，如果真的需要。
universefeeler
on 5 Dec 2018
支持 LDAP & OAuth2，或者直接上 keycloak 的支持更加好
gumutianqi
on 6 Dec 2018
支持OpenID Connect，比如，Okta和keycloak
anjia0532
on 6 Dec 2018
肯定是要做权限的,建议可以分应用,分模块,分组织架构.
fireflyhoo
on 9 Dec 2018
我觉得最优先有一个登陆页面，用户密码就简单配置一下就行了。要不内网都不放心使用，万一谁使坏把数据都删除 了怎么办。
makeaaron
on 4 Jan 2019
我想请问一下，现在默认的登录账号密码是什么啊？
hide-out
on 16 Jan 2019
我想请问一下，现在默认的登录账号密码是什么啊？
makeaaron
on 28 Jan 2019
那问一下，啥时支持LDAP呀。
zzllkk2003
on 29 Dec 2020
Related issues
zscboy
·
4Comments
geffzhang
·
6Comments
mark-wk
·
7Comments
peggypig
·
4Comments
David-wu91
·
5Comments
Most helpful comment
支持 LDAP 就已经可以了，类似 社区里面的 jenkins, gitlab, rancher 之类，都是优先支持 LDAP；
更重要的是，需要对 Nacos 现有的所有功能就行权限和角色的划分，是给到所有权限，让用户自己创建角色来划分，还是不开放权限，直接内置角色来划分的问题了。