云计算相关的技术差点儿都对传统网络架构和安全规则产生一定的冲击。Pivotal Cloud Foundry（PCF）也不例外，去年8月为了说服专业安全组织允许PaaS部署方案，特意为他们深入讲了下PCF的安全机制，尽管这种原理性的东西不符合开博的宗旨，可是为了防止大家也要说服这种组织，分享出来也算是云计算实务的一部分。只是说实话，个人以为既然我们開始拥抱云计算和大数据，那在安全上就应该有新的认识和实践。
本文是基于PCF1.2进行的说明，如今的版本号里Availability Zone和App Security Group都已经是存在的功能了。首先给出PCF的系统结构图，用于在下文进行说明时进行对比。然后将以条目的格式列举PCF安全原理的所有要点。
- 外部应用訪问PCF应用仅通过HAProxy的IP，PCF应用訪问外部应用通过DEA的IP或者DEA被SNAT之后的IP。要说明的是。PCF自带的负载均衡器为开源软件HAProxy，可是支持使用不论什么自由的负载均衡器，即下图中的Load Balancer的位置。
- warden与不论什么其它部分（同一host上的其它warden、不同host上的warden、PCF组件、service instance、PCF外部应用）均需先NAT成所在host的IP。
- warden们互相是不知道对方的存在，每一个warden都用255.255.255.252为掩码的网络与主机联系。主机们的iptables保证不会将一个warden连到还有一个warden。
- warden所在主机的iptables保证它仅仅能訪问特定的PCF组件。而不能訪问其它的组件。
- PCF的服务绑定机制通过主机iptables保证仅仅有合法应用才干訪问服务。
- Host的iptables保证了除了router谁也没法訪问warden。
- PCF通过ORG上的角色Manager/Auditor、SPACE上的角色Manager/Developer/Auditor保证了授权用户才干管理应用。
- HAProxy的作用是SSL和负载均衡http请求到router上，所有相应用訪问造成的数据通讯都须要通过router，在CC的帮助下，router将请求放到正确的应用实例上。假设应用指定了jseesionid，则router会尽量保证请求被路由到同一个应用实例上。
- PCF内部组件通讯均通过订阅公布式消息队列，互相之间不做网络通讯，其訪问控制均通过iptables实现。即使没有app security group功能，仍然能够通过登录到OS中。改动iptables来改变安全策略（默认的安全策略是all deny，东西向全不通）。Security group给了一个用户接口去改动这些策略。
- Availability Zone从资源池层面攻克了网络隔离，应用实例，各个服务实例均可依照原有的网络规划放置。可是弹性执行环境还是仅仅能在一个zone里。
- PCF可通过syslog的方式将组件日志和应用日志均公布出来。用于安全审计。
