前文的示例中,Eureka Server都是允许匿名访问的,该方式一般无法满足公司在安全性上的诉求。
本节来构建一个需要登录才能访问的Eureka Server。Eureka本身不具备安全认证的能力,Spring Cloud使用Spring Security为Eureka Server进行了增强。
1 加依赖
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
2 加配置
spring:
security:
user:
name: user # 配置登录的账号是user
password: password123 # 配置登录的密码是password123
如不设置这段内容,账号默认是user,密码是一个随机值,该值会在启动时打印出来。
3 改配置
将Eureka Server中的 eureka.client.service-url.defaultZone
修改为为 http://{user}:{password}@EUREKA_HOST:EUREKA_PORT/eureka/
的形式:
eureka:
client:
service-url:
defaultZone: http://user:password123@localhost:8761/eureka/
4 写代码
/**
* Spring Cloud Finchley及更高版本,必须添加如下代码,部分关闭掉Spring Security
* 的CSRF保护功能,否则应用无法正常注册!
* ref: http://cloud.spring.io/spring-cloud-netflix/single/spring-cloud-netflix.html#_securing_the_eureka_server
* @author zhouli
*/
@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http.csrf().ignoringAntMatchers("/eureka/**");
super.configure(http);
}
}
Spring Cloud Finchley及更高版本必须添加这一段,在Edgware以及更早的版本中无需这一步骤。
http://localhost:8761
,可跳转至类似如下的登录页面:
user
,密码 password123
后,即可正常访问Eureka Server首页。
如何将微服务注册到需认证的Eureka Server上呢——和Eureka Server端一样,只须将 eureka.client.service-url.defaultZone
配置为 http://{user}:{password}@EUREKA_HOST:EUREKA_PORT/eureka/
的形式即可:
eureka:
client:
serviceUrl:
defaultZone: http://user:password123@localhost:8761/eureka/
实际项目中,出于安全考虑,往往还需实现数据权限。
举个例子:
从安全的角度,我们希望:
此时该怎么办呢?
TIPS 有人可能会想:Eureka Server上哪有什么操作啊!整个Eureka Server的界面上,明明只有查看的能力! 如果只是查看,那当然没有问题,但要知道Eureka Server是有RESTful API的(详见 跟我学Spring Cloud(Finchley版)-06-服务注册与服务发现-Eureka深入 一节 )——举个例子,只需发送DELETE请求到
http://{username}:{password}@EUREKA_HOST:EUREKA_PORT/eureka/apps/{appId}/{instanceID}
,即可下线服务。如果线上微服务被恶意下线,那后果是不堪设想的。君不见,前两年携程删库事件造成股票大跌?
Spring Cloud抑或原生Eureka Server并未提供这一功能,只能由开发人员基于Spring Security或其他权限框架自行扩展。
这个扩展的成本还是比较高的,于是目前业界大多企业都放弃了扩展,转而采用管理手段防止无数据权限带来的风险。例如,生产环境中:
TIPS 有人可能会想:这TM扯淡吧?我翻一下配置属性不知道账号密码了?后面会讲配置中心,配置中心可将账号密码等敏感数据加密存储。
但不管怎么样,以上方式都会增加运维成本,同时也会带来不少沟通问题。
在笔者看来,体验最好、最直观、最完美的做法如下:
思路已经给出,实现也就是工作量的事情了。
相信聪明的看官们,对是放弃扩展,抑或追求完美一事,心里一定有了一些计较。