2.识别、最小化及加固攻击面

3.降低作用域和访问权限

4.分层的保护与防御整体应用安全(AppSec)的好处包括其构建和维护的易于理解及“已知的已知”。这种架构往往相对简单，并且在开发、业务、合规等过程中通常有着根深蒂固的现有习惯(及相关责任分工)。整体应用安全的劣势包括向单点的妥协，往往也意味着对整个应用及网络的妥协、全局的认证需求以及安全机制往往很难协调。微服务应用安全的好处包括：广为接受的Unix单一职责原则、普遍减少的公开暴露的攻击面、服务可以被单独打补丁、应用(和相关的运行时容器)更方便地应用最小权限和适应服务特性的安全机制，并且这通常可以更方便地建立可信计算基(TCB)。相应地，劣势包含：微服务安全是一种“已知的未知”，成功的维护会需要习惯上的改变(如DevOps和DevOpsSec)、需要对整个系统的功能有一个很好的理解、遗留项目很难适用、复杂性(伸缩性方面)所带来的不安全。Grattafiori接下来深入分析了微服务系统各个区域的安全影响，首先是在网络安全方面。虽然大部分软件系统在OSI模型7层(应用层)提供身份认证，这点常被争论为只能提供有限的优势，最好是通过在4/5层的TLS来实现，如果需要额外的网络安全那么可以实现3层的IPSEC。许多组织使用Linux容器如Docker、rkt或LXC来包装微服务，这两者之间在安全方面有明显的相似之处：

减少应用和容器的威胁模型攻击树很有必要。这包括通过利用防御性代码和容器安全(如能力(capabilities)、用户命名空间、只读根文件目录(rootfs)、不可变文件、mount标记(mount flags)和强制访问控制(MAC))来限制由应用弱点所造成的危害。容器逃逸所造成的伤害可以被用户命名空间限制，它可以让容器中的root用户对应到容器外的非root(uid-0)用户。虽然Docker守护进程支持Docker 1.10用户命名空间，但是默认是没有开启的。seccomp、kernel加固和MAC可以限制kernel和syscall的调用。受限的kernel或主机操作所造成的破坏能进一步被网络加固、信任隔离、最低权限、最小访问、日志和报警所限制。Grattafiori表示容器安全始于宿主机的操作系统，并极力推荐使用最小的Linux发行版如CoreOS、alpine Linux、Project Atomic或RancherOS。对操作员来说理解发行版如何升级、二进制包编译、默认安全配置(如MAC)和默认kernel参数及sysctl配置也是非常重要的。容器镜像也应该保持最小化，典型的如“FROM debian:jessie”或“FROM debian:wheezy”来创建镜像。然而这可能还不够小，就算在用apt-get安装应用所需软件之前，已有许多应用用不到的类库、可执行文件和语言文件，这意味着更多的补丁、更多的磁盘空间、更多的攻击面以及更多的攻击方法。演讲中演示了使用Docker和runC来构建最小容器的例子，以及几个使用scratch容器来运行静态编译的二进制程序(如Golang构建的应用)。

Grattafiori强烈建议使用强制访问控制(MAC)，从操作系统角度应用最小访问原则。MAC引用一种操作系统限制主体(特别是进程或线程)访问或操作对象(如文件、TCP/UDP端口、共享内存段)的访问控制。MAC作为一种Linux安全组件(LSM)是由AppArmor和SELinux(还推荐使用grsecurity，它内部包含了一套MAC解决方案，是一组强调安全增强的Linux kernel补丁)实现的。在Mac OSX上MAC通过TrustedBSD实现，微软平台有强制完整性控制(MIC)。默认的Docker AppArmor策略已经非常好了，但是鉴于这个策略是通用的，它一定包含了大量的文件、权限授权和复杂性。微服务更适合使用自定义安全描述文件的实践。基于Docker的应用的自定义AppArmor的描述文件可以通过aa-genprof或Jessie Frazelle的Bane项目来生成。然而这需要分析目标应用(因为需要理解和使用这个应用)、常见错误如提供过多权限、通配符的使用和基于路径的访问控制列表(ACLs)。Grattafiori提醒应该避免使用AppArmor的拒绝列表(黑名单)，因为它们只能提供有限的值。其他的易混淆的地方包括描述文件必须先被AppArmor加载，在描述文件中太过大量地运用抽象，这导致很难在生产环境中充分验证所有的功能是有效的(虽然单元测试和回归测试会有帮助)。虽然MAC很有价值，但是它还是无法避免kernel攻击，不巧kernel攻击的攻击面是巨大的。“安全计算模式(seccomp)”是一个计算机安全设备，它在Linux kernel提供应用的沙箱机制(虽然seccomp本质上不是沙箱)。seccomp允许进程单向转变进入“安全”态，在其中只能对已经打开的文件描述符使用exit、sigreturn、read、write这些系统调用。如果它尝试其他的系统调用，kernel会使用SIGKILL终止进程。seccomp-bpf是seccomp的一个扩展，它使用伯克利封包过滤器允许使用一个配置的策略来过滤系统调用。

Docker引擎1.10后seccomp默认过滤器默认启用，但是由于通用需求，内部启用了304个系统调用(占所有系统调用大约75%)。最小权限原则建议微服务应用只应该拥有最小的系统调用集，相应地可以创建自定义描述文件。创建seccomp描述文件的方法包括strace/ltrace、kernel帮助(sysdig或systemtap)、auditd/auditctl或seccomp自己通过SECCOMP_RET_TRACE和PTRACE_O_TRACESECCOMP。在Docker中可以通过使用“--security-opt seccomp=”标记来指定自定义的seccomp描述文件。Grattafiori强调seccomp配置文件是对架构依赖的，所以会限制移植性。Grattafiori开始总结演讲时，陈述了运行安全的基于Docker的微服务的高层次建议：启用用户命名空间