Kata

Kubernetes曝漏洞！可取得管理员权限 近期Kubernetes爆出信息安全漏洞，Kubernetes 产品安全团队表示，近日在 Kubernetes API Server 内存在权限扩张漏洞，发现此漏洞的开发者为 Rancher 共同创办人兼首席架构师 Darren Shepherd 。 目前 Kubernetes 开发团队已经发布 V1.10.11、V1.11.5 及 V1.12.3 ，以解决该漏洞带来的风险。参与 Kubernetes 安全团队的 Google 高级工程师 Jordan Liggitt 建议，在集群内执行先前版本 Kubernetes 的企业用户，得尽速择一版本进行更新。 此漏洞编号为 CVE-2018-1002105 ，让攻击者可以发送特殊的系统请求，经由 Kubernetes API Server ，与企业内部后端服务器进行连线，借由取得 Kubernetes API Server 的认证，攻击者就能利用既有连线，任意向后端服务器发送请求。 红帽云端平台副总裁 Ashesh Badani 表示，此权限扩张漏洞的影响非常重大，可让不法人士在任何运算节点、Kubernetes Pod 取得管理员权限，黑客可以盗取机密资料、注入恶意程序码，或者瘫痪企业正式环境内的应用程序。而红帽使用 Kubernetes 作为核心调度引擎的产品线，包含容器平台

⒈KataContainers？ 　　Kata Containers是新的虚拟机实现，可以实现和现在容器生态无缝连接，与时下最流行的容器编排工具k8s完美结合，提供容器的快速启动，和虚拟机的安全隔离，与Docker技术相比，容器之间不共用内核，使得隔离性更好。 　　Kata Containers 项目的主要目标是将虚拟化的安全隔离优势和容器的快速启动特点结合起来。 ⒉即生Docker，何来Kata Containers？ 　　Linux 容器轻巧，快速且易于集成到许多不同的应用程序工作流程中。但是，在运行容器时存在一些潜在的安全问题，特别是在单个操作系统中的多租户容器：最终，容器共享一个内核、 I / O 的一条路径、网络和内存等。 　　使用Docker轻量级的容器时，最大的问题就是会碰到安全性的问题，其中几个不同的容器可以互相的进行攻击，如果把这个内核给攻掉了，其他所有容器都会崩溃。如果使用KVM等虚拟化技术，会完美解决安全性的问题，但是会影响速度。 　　Kata旨在通过虚拟机管理程序来缓解这种安全问题——创建一个外观和感觉像容器的虚拟机。 　　Kata Containers项目通过整合Intel Clear Containers和Hyper runV技术，能够支持不同平台的硬件，并且兼容Open Container Initiative(OCI)和Kubernetes

html5新特性：利用history的pushState等方法来解决使用ajax导致页面后退和前进的问题 参考文章： （1）html5新特性：利用history的pushState等方法来解决使用ajax导致页面后退和前进的问题 （2）https://www.cnblogs.com/51kata/p/5144773.html 备忘一下。 来源： oschina 链接： https://my.oschina.net/u/4437974/blog/4716592

概述 云原生（Cloud Native）是一套技术体系和方法论，它由2个词组成，云（Cloud）和原生（Native）。云（Cloud）表示应用程序位于云中，而不是传统的数据中心；原生（Native）表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳状态运行，充分利用和发挥云平台的弹性和分布式优势。 云原生的代表技术包括容器、服务网格（Service Mesh）、微服务（Microservice）、不可变基础设施和声明式API。更多对于云原生的介绍请参考 CNCF/Foundation 。 笔者将“云原生安全”抽象成如上图所示的技术沙盘。自底向上看，底层从硬件安全（可信环境）到宿主机安全 。将容器编排技术（Kubernetes等）看作云上的“操作系统”，它负责自动化部署、扩缩容、管理应用等。在它之上由微服务、Service Mesh、容器技术（Docker等）、容器镜像（仓库）组成。它们之间相辅相成，以这些技术为基础构建云原生安全。 我们再对容器安全做一层抽象，又可以看作构建时安全（Build）、部署时安全（Deployment）、运行时安全（Runtime）。 在美团内部，镜像安全由容器镜像分析平台保障。它以规则引擎的形式运营监管容器镜像，默认规则支持对镜像中Dockerfile、可疑文件、敏感权限、敏感端口、基础软件漏洞

概述 云原生（Cloud Native）是一套技术体系和方法论，它由2个词组成，云（Cloud）和原生（Native）。云（Cloud）表示应用程序位于云中，而不是传统的数据中心；原生（Native）表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳状态运行，充分利用和发挥云平台的弹性和分布式优势。 云原生的代表技术包括容器、服务网格（Service Mesh）、微服务（Microservice）、不可变基础设施和声明式API。更多对于云原生的介绍请参考 CNCF/Foundation 。 笔者将“云原生安全”抽象成如上图所示的技术沙盘。自底向上看，底层从硬件安全（可信环境）到宿主机安全 。将容器编排技术（Kubernetes等）看作云上的“操作系统”，它负责自动化部署、扩缩容、管理应用等。在它之上由微服务、Service Mesh、容器技术（Docker等）、容器镜像（仓库）组成。它们之间相辅相成，以这些技术为基础构建云原生安全。 我们再对容器安全做一层抽象，又可以看作构建时安全（Build）、部署时安全（Deployment）、运行时安全（Runtime）。 在美团内部，镜像安全由容器镜像分析平台保障。它以规则引擎的形式运营监管容器镜像，默认规则支持对镜像中Dockerfile、可疑文件、敏感权限、敏感端口、基础软件漏洞

概述 云原生（Cloud Native）是一套技术体系和方法论，它由2个词组成，云（Cloud）和原生（Native）。云（Cloud）表示应用程序位于云中，而不是传统的数据中心；原生（Native）表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳状态运行，充分利用和发挥云平台的弹性和分布式优势。 云原生的代表技术包括容器、服务网格（Service Mesh）、微服务（Microservice）、不可变基础设施和声明式API。更多对于云原生的介绍请参考 CNCF/Foundation 。 笔者将“云原生安全”抽象成如上图所示的技术沙盘。自底向上看，底层从硬件安全（可信环境）到宿主机安全 。将容器编排技术（Kubernetes等）看作云上的“操作系统”，它负责自动化部署、扩缩容、管理应用等。在它之上由微服务、Service Mesh、容器技术（Docker等）、容器镜像（仓库）组成。它们之间相辅相成，以这些技术为基础构建云原生安全。 我们再对容器安全做一层抽象，又可以看作构建时安全（Build）、部署时安全（Deployment）、运行时安全（Runtime）。 在美团内部，镜像安全由容器镜像分析平台保障。它以规则引擎的形式运营监管容器镜像，默认规则支持对镜像中Dockerfile、可疑文件、敏感权限、敏感端口、基础软件漏洞

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 编程如何节省更多的时间，犯更少的错误？ 最近，这样一份「心得」火了。这位名叫Kesk Noren的软件工程师在Medium上分享了一篇博文——「40 Tips that will change your coding skills forever」，获得3.5k点赞。 40个将永久改变你编程技能的小技巧，你值得拥有～ 除了软件工程师以外，Kesk Noren还是一位全栈工程师。他用15年的工作经验，总结出来一些对职业生涯有帮助的东西。 还提到， 这篇文章虽然读起来很快，但是真正能够应用好它，就需要一生的时间。 话不多说，我们就来一睹为快！ 40个改变编程技能的小技巧 1、将大块代码分解成小函数 2、今日事今日毕，如果没毕，就留到明天。 如果下班之前还没有解决的问题，那么你需要做的，就是关闭电脑，把它留到明天。 中途不要再想着问题了！ 3、YAGNI原则 「You aren’t gonna need it！」 你自以为有用的功能，实际上是用不到的。除了要求的核心功能，其他功能一概不要部署。 这一原则的核心思想是，尽可能快、尽可能简单的将软件运行起来。 4、不必全知全能，但基础一定要扎实 比如学习一些基础知识，SOLID原则，如何写干净的代码等等。 5、KISS原则 「Keep

SOFA:Channel/ ，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 30315793，不错过每场直播。 本文根据 SOFAChannel#16 直播分享整理，主题：不得不说的云原生隔离性。 大家好，我是今天的讲师巴德，来自蚂蚁金服，主要从事 Kata 容器相关的开发，也是 Kata Containers 项目的维护者之一。今天我和大家分享一下云原生场景下容器隔离性的需求以及我们如何运用 Kata Containers 来提升容器的隔离性。 从 Kubernetes Pod 说起 在讲云原生隔离性之前，我们先来回顾一下历史。这张图是生产环境应用部署形态的变迁过程。从最左边的物理机上直接部署，到后来的虚拟化兴起，大家把应用部署在虚拟机里，再到 Docker 兴起，大家都把应用部署到容器里面，到现在 Kubernetes 成为主流，大家都把应用部署在 Pod 里面。 我们看一下 Kubernetes 的一个基本架构，它本身是一个容器的编排系统，主要角色是管理和调度 Pod 以及相关的资源。今天我们主要关注的就是在节点上部署的 Pod，这也是 Kubernetes 资源调度的基本单位。 Kubernetes 官方对 Pod 的定义是一个应用的逻辑主机，其中包含了一个或者多个应用容器，这些容器在资源上是相对紧密的耦合在一起的。Pod

从2015年5月初开始创业开发 HyperContainer (runV) 到现在，也快五年了，在这个时候还来写一篇什么是安全容器，显得略有尴尬。不过，也正是经过这五年，越来越多到人开始感到，我需要它却说不清它，这个时候来给大家重新解释 “ 安全容器 ” 也正是时候。 缘起：安全容器的命名 Phil Karlton 有一句名言—— 计算机科学界只有两个真正的难题——缓存失效和命名。 就容器圈而言，我相信命名绝对配得上这句话，这毫无疑问是一件让老开发者沉默，让新人落泪的事情。 仅就系统软件而言，我们当今比较通行地称为 Linux 容器（LinuxContainer）的这个概念，曾经用过的名字大概还有——jail, zone, virtualserver, sandbox... 而同样，在早期的虚拟化技术栈里，也曾经把一个虚拟机环境叫做容器。毕竟这个词本身就指代着那些用来包容、封装和隔离的器物，实在是太过常见。以至于，以严谨著称的 Wikipedia 里，这类技术的词条叫做“系统级虚拟化”，从而回避了“什么是容器”这个问题。 当2013年 Docker 问世之后，容器这个概念伴随着“不可变基础设施”、“云原生”这一系列概念，在随后的几年间，以摧枯拉朽之势颠覆了基于“软件包+配置”的细粒度组合的应用部署困境，用简单地声明式策略+不可变容器就清爽地描述了软件栈。应用怎么部署似乎离题了

地址： https://www.codewars.com/kata/5739174624fc28e188000465/java 总结：不好写，各种牌的可能的情况都要考虑到，同种牌型之间还需要比较牌的大小。 package codewar; import java.util.*; import java.util.stream.Collectors; // https://www.codewars.com/kata/5739174624fc28e188000465/train/java public class PokerHand { static char[] CARDS = new char[]{'2', '3', '4', '5', '6', '7', '8', '9', 'T', 'J', 'Q', 'K', 'A'}; static Map<Character, Integer> VALUES = new HashMap<>(); static { int i = 0; for (char c : CARDS) { VALUES.put(c, i++); } } static char[] SUITS = new char[]{'S', 'H', 'D', 'C'}; public enum Result {TIE, WIN, LOSS} Set<String> cards