【Free style】理解PaaS认证流程中的AK/SK和Token

先看看一般的认证是怎么做的？

Token认证

这种方式是Openstack中的KeyStone的认证方式。示意图如下：

原理：任何请求，都附带token。接收者根据token判断请求是否合法。

因为有token的加持，所以可以防止非法请求。而且token是有有效期的限制的。

缺点：如果报文在中途被劫持，那么token就泄露了，这时（token有效期内）黑客就可以构造任意的请求了。可以看出来，还是不那么的安全。

AK/SK的认证

这种方式是AWS上面S3的认证方式。示意图如下：

原理：把信息放到一个箱子里，然后贴个信物。中间不管什么被动了手脚，都会被发现。

可以看到，这比token认证的方式安全很多。

因为要求客户端也要保存一份AK/SK，所以你可以在AWS上面看到，有让用户下载AK/SK的页面。

（另：AK作为用户名的别称，是支持修改的）

缺点：虽然不能修改报文，但是可以截获报文后不停地重复发送该报文。（太机智了）

PaaS引入AK/SK

使用user/paaswd的方式，对于用户登录时界面操作还行。但是对于程序直接使用API调用场景，就不安全了。所以一般的云平台，例如google，aws都提供对AK/SK方式的支持。华为公有云也不例外。所以PaaS在上公有云的时候也加入了对ak/sk的支持。

PaaS中Docker镜像仓库

Docker下载镜像的时候，需要认证。docker原生的交互是使用token的，但是登陆的时候使用user/pw，所以原生的实现不符合安全要求。这里使用ak/sk对用户名/密码做了一次映射。保证login的安全，后续上传动作还是继续使用token方式。

k8s的imagePullSecret

因为k8s启动Pod要下载镜像，就需要imagePullSecret。而上个章节我们知道Docker下载的账号经过我们特殊处理的。所以这里我们就要给k8s创建对应的imagePullSecret，创建的方法同Docker登陆账号一样：

阶段总结，如有不对请指正 ：-）