devops之gcp core infrastructure fundamental，开始动手前，用户、授权

devops之gcp core infrastructure fundamental，开始动手前，用户、授权

最后更新2022/02/02

gcp如果粗略参考着安全相关的内容，可以这么划分边界：

google负责和管理基础设施安全用户负责自身数据安全google为你提供各种最佳实践、模板、产品和解决方案

再进一步说，可以再详细切分一下：
图中黄色部分由google负责，篮色部分由用户负责，这算是个分工界面定义吧，最左侧，全是篮色，那就是传统的方案：用户自己全管，自己建数据中心、采购设备等等。右侧则依次根据用户使用gcp的程度，有不同的分工界面。当然，google不会忘记自我吹捧一下：由于哥的规模太大了，远超你们普通用户自己芝麻绿豆大的数据中心，所以我可以达到最高水准的安全，如果你们自己负担，可能是花不起这个钱的，但哥有的是钱！既要最好，不怕最贵。而且，只要你用了哥的gcp，直接就享受到这最顶级的安全保证，哪怕你只租一粒芝麻大的虚机，这便宜你占大了！

当然，尽管安全，哥也不能啥都帮你做，有些事还得你自己亲历亲为，但哥给你准备好了各种工具，例如IAM（identity access management），可以帮你快速部署并在特定层面实现你的安全要求。

万事安全第一，动手之前先讲安全（授权）

安全与资源分层有关，前面介绍过google的资源分为：

organize node组织节点，通常来说一个公司就是一个组织节点，它应该覆盖公司的所有资源，如果不考虑对外服务，那么把所有资源封闭在一起，对外面（互联网）不可见也是可能的；folders直译是抽屉、打包，对应的可能可以算是一个机构吧，就是能或者需要独立实现某些功能。同时，folder还能层级包容，就是一个floder下面包含几个floder。这样赋予某个floder的（安全）特性，就可以传递给下属folder；projects项目，这个有点阶段性、局部性的意味，但应该还是一个完整的功能整体；resources资源，这是具体资源了，脱离了相关性，单以IT视角查看，例如vm，storage等等；

有了以上分层，就可以制定安全策略了，指派策略的颗粒度就可以最小为单一resource，最大为organize node，并且可以向下继承。

从计量角度看，GCP的服务以project为单位进行统计，包括：

跟踪资源分配和使用情况计费管理必保或预留资源分配提供开启的服务或API

任何用户获得的资源一定属于某个GCP console project，控制资源使用、计费等等都是以project进行划分和统计，每个project可以有不同的所有者及用户（当然相同也没问题）。google提供了多种方案帮助你管理project，甚至可以通过API编程管理，例如：

显示归属一个账号下的所有项目创建新项目修改项目删除项目撤销删除、恢复被删除的项目（不知垃圾箱保留多久？）

编程访问方式包括RPC API或者REST API

项目有三个标识：项目ID，项目名字，项目号。项目ID和项目名都是用户自定义，最后一个项目号是google指派的。其中，项目名可以修改，其它两个都不能改，这也是由于项目名可以不唯一，只是个标记，其它两个是全局唯一，不能重复的，看起来是google在创建项目记录时，自动在表中生成的唯一索引。其实项目ID和项目号的用途相同，但项目ID可以更人性化一点，甚至可以是有实际含义的单词、字母组合，只要不重复就好，而项目号，更像是随机字串，不是给人看的。

folder比project大一级，一个folder可以包含一个或几个项目，甚至可以包含另一个folder，folder纯粹是为了便于管理而存在，因为授权策略是以folder为单位进行指派的。

从某种意义上，organization node更像一个包括所有的folder，其实也就是这个用途。例如，在最开始时，省缺情况下，gcp允许任何人（同组织内）创建项目、申请资源，但如果你想避免滥用授权（资源都是钱！），那么最好第一件事情就是收回相关的授权，将其归属于特定用户，特别是可以让只有拥有organization node策略授权的用户去进行类似 *** 作。如果使用了G套件的用户，google会帮用户做好类似的设置，如果没有使用G套件，则此步骤要用户自己完成。其实google完全可以让用户省缺就没权分配资源，但这种商业策略似乎不太容易帮google赚钱，留下足够诱惑，再加上一个象征性的锁才是赚钱的不二法门，且不留埋怨：虽然我把小吃摆得到处都是，但我已经告诉你要收费，你管不好自己的嘴，吃多了怪我？！你不提供，交钱才拿出来，不就不会被吃掉么！但如此一来，吃多掏钱得人当然少太多啦！

上图显示了一个典型（小型）的组织关系图，我们可以看到最底层，在资源之下有一些实际的实例，资源是抽象的类型，具体计量要以资源实际占用，也就是实例为依据。而对于每个组件的策略指派是从上到下继承关系，就是如果授权上一层，则对对应项目的下一层自动拥有授权。

IAM识别授权管理的定义

IAM其实就三条：

who谁can do what能干啥on which resource对什么资源

在GCP，who对应的就是account账号，一个账号就是一个可授权的who，账号又有几种：

google登录账号或者google用户，这是实实在在的每个具体用户，对应一个email地址，如果你注册两个（不同）的email地址，则名义上，就是两个用户service账号，除了实实在在的人，还有一些自动 *** 作也可能要完成一些“类人” *** 作，例如定时备份、爬虫等等，这就是服务账号，也可以授权group账号，没啥说的，把一组单独账号组合起来，就是了google identity or G suite domain这个不太好翻译，但其含义与service账号有点类似又不太一样，可以说是与CA或者DNS有关吧。每个domain id或者CA授权的一组key，都可以被想象成一个可以独立完成某种 *** 作的人，而且GCP也需要这个虚拟人能定期去做一些 *** 作，因此需要授权。而这个人又不同于service账号，service账号与真人账号是一样的，任何人或者机器拿到对应的账号名、密码就可以 *** 作，而这个账号只能被限定为由持有特定IP或者key的访问请求进行 *** 作；

can do what，能干什么？也要具体到特定的服务、资源（类型，对不同的资源可 *** 作的动作显然不完全相同），以及动作。这三者组合的整体列表，可以由某个role来概括，这样在授权时，不用每项授权都依次选择，而通过role，立刻就把一组常用的授权动作都指派过去了。

on which resource，最后是具体到某个特定的资源类型或实例。

IAM体系的role有3大类：

primitive，这个么，怎么说呢，叫天性或者本性吧，是个非常抽象化的几种动作，它自动包含了GCP项目中的所有服务，包括：所有者（自动赋予邀请成员、删除成员、删除项目及编辑者所有能力；编辑者（自动赋予部署、修改代码、配置服务及观察者所有能力；观察者（只读访问）；计费管理者（管理计费及增删其它计费管理者）。有了这一类role的能力，就可以毫无压力完成 *** 作了，除了有时可能会觉得不太精细。predefined，预定义的，一些最常用的，google帮助进行了一些规划，比primitive精细一些，特别是针对特定的资源，有了特别的定义，例如实例管理者role，可以启停、显示实例等等。customized ，如果还觉得不够，那么你还可以自己任意定义，此处就不过多展开了，具体使用时再看。

再回过来说服务account，由于服务account的 *** 作者不会是人（不知道google是否强制要求service account无法直接登录），它只是完成服务器到服务器之间的交互 *** 作，使用的授权方式也是服务器自身用户授权，标识也是email账号：
project_number-compute@developer.gserviceaccount.com
project_id@appspot.gserviceaccount.com
它一般是用来授权某台虚拟机，例如要让某个应用写存储，而又不想让别的用户随便看存储数据，那么就可以把此存储读写访问授权给一个服务账号，并赋给这个应用。虽然服务account也是email地址，但通常不会使用密码进行认证，而是使用key（不确定是否允许密码认证，待确定）

用户管理

什么样的用户可以被GCP认证登录？

直接赋予了用户权力的google账号用户或者组用户在G suit domain中的用户在Cloud identity domain中的用户或者组用户

由于大部分用户都使用自己的google 用户（账号）登录，所以可以对此单独用户、组授权；尽管用组方式可以快速控制一组用户，但如果某个用户离开了本公司，而还在此组中怎么办？那就需要另外两个方案：G suite domain或者cloud identity domain。

G suite domain和微软企业office365类似，提供了一整套办公套件，同时也包含一个企业用户登录账号，这个账号就可以用来控制用户授权，而且和企业挂钩。如果这个人离开了公司，也就失去了G suite domain账号，自然就失去了授权；

cloud identity domain则直接就是一个独立的，与企业domain挂钩的邮箱地址（其实可能没有邮箱），这是另一个可以用来授权的账号。

如果企业自己有自己的授权管理，是否可以借用？可以，但不是借用，这需要一个定期同步 *** 作，将企业自身的用户目录LDAP定期单向同步到google的cloud identity domain。

*** 作GCP

有了用户，就可以管理GCP了，GCP提供了四种登录方案：

GCP console，这是哥web网站，BS方式访问，优点是图形化，web提供，有cloud source源代码，也提供shell，还能test 自己的管理应用（需要通过mobile app），能访问APICloud shell或Cloud SDK，这是命令行方式，可以通过docker image实现，对应为一组命令，如gcloud，gsutil，bq。你也可以自己下载下来命令可执行代码或者查看源代码；Cloud console mobile app，手机访问，要下载一个小程序，支持iOS和andriodREST API，和web类似，可以理解为web方式的命令行，格式是JSON，OAuth 2.0访问授权

还有一些工具帮助你实现管理，例如API explorer（gcp console中提供），可以帮你使用浏览器测试api。然后是各种语言的客户端及源代码，自己去下载学习。

cloud marketplace，据说要改名为cloud launcher，有点像成熟的软件解决方案模板，其中涉及到的产品有一些是google的，有些是别人的，但都是开源免费的，只有运行耗用资源需要收费，当然，再此基础之上，用户也可以搞一些商业软件同时配合运行，自然，要自己付费。以后再研究。

module 2学完，收工。