本周有个插入的事项，就是说我们目前在使用某云服务商的API，对于其中的API鉴权，那边有更安全的方案。原先，我们应用调取云产品的功能时，是通过一个AccessKey和AccessSecret来的。在调用的时候，需要在SDK中提供这两个值，然后就可以在应用中使用SDK提供的云产品API了。原先的安全要求是不能在代码中存储这两个值，公司会有某种自动扫描机制，通过这个机制可以检测代码仓库中的敏感信息，这两个鉴权用的字段也当然囊括在内。所以，我们一般都会把这两个值写在配置文件中，安全性会更好一些，也方便更改。
而现在他们说这两个值是静态的，无法在泄露的情况下快速进行更换。毕竟我们服务一般都有几十上百个容器，而目前来说，启动配置虽然已经集中于各种配置中心里了，但是在技术上是无法实现秒级别的动态更改的，必须在修改配置后重新启动容器。而容器的启动是无法通过一次性重启所有容器来完成，必须进行分批重启以保证服务的平稳，没有十几分钟甚至几十分钟是搞不定的。
所以云提供商的技术团队提出了一个新的方案，通过向我们提供一些必要的而且泄露后不容易造成直接影响的凭据（好像是一个密钥文件），然后通过在线认证的机制下发动态的验证信息。这个过程比我上文提到的验证机制复杂许多，特别是我们需要在容器中纳入这样一个配置文件，或者直接在JAR包中纳入。然后我们需要引入一个SDK，来专门做这个动态验证信息的获取，然后将这个信息通过某种方式传递给云产品的SDK，最后才能实现云产品API的调用。
这个具体的过程并不是我来跟进，我把这些问题交给其他同事了，由他们来具体执行。我只是作为云账号权限的控制者，为他们提供密钥文件并给他们提供正确的方向即可。
