数据API 案例 开发者 关于
掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务
新闻动态 > 媒体报道

在OpenShift中运行容器

本文不是一篇关于如何在OpenShift中使用和部署容器的指导性文章,也没有具体介绍OpenShift的原理组成,关于如何使用OpenShift可以参考另一篇《OpenShift V3 应用发布部署的简单场景演示》。

本文的关注点在于OpenShift中的容器安全性问题,相信很多用过容器的读者都会遇到在容器里以root用户启动应用的情况,这篇文章着重介绍了OpenShift中我们如何处理这种情况,以及这样处理带来的副作用和其中的原因。

OpenShift 是Red Hat公司推出的一个基于Kubernetes的容器应用平台。并且很简捷,没错,它就是一个PaaS。新的V3版本的OpenShift做了一次重大的改变,所有的组件用go语言重新编写,并且和现在的Kubernetes有了很好的结合。当你使用OpenShift的时候,你其实得到了一个Red Hat推出的基于Kubernetes的分布式系统,OpenShift的功能是围绕着代码部署,自动化构建等等,是一个典型的PaaS平台。

OpenShift的优点是什么呢?Red Hat经常引以为豪的就是它的安全性。

我不是一个安全领域的专家,但是当你考虑使用Kubernetes并且如果你不想围绕secrets争论的时候,你会发现,Kubernetes有很多关于安全性的功能。RBAC就是一个当你用kubeadm去部署一个集群环境时默认的设置。可以通过强制的网络规则进行网络隔离,pod也可以用安全策略控制非常严格。加上身份验证机制,为所有组建间的通信提供TSL加密,权限控制,至少对我来说,这是一个非常强大和安全系统。

但是对早期的使用者来说这些安全设置是有代价的。在OpenShift中,使用Kubernetes默认的Pod安全策略,他们被SCC(Security Context Constraints)调用。默认使用SCC最明显的地方是在OpenShift的容器中,进程不能用ROOT用户运行。(译者注:表现为权限不够)

所以如果你在minishift里,没有指定一个非ROOT用户去运行一个Docker镜像,这肯定会失败。这意味着,非常遗憾,我们的Bitnami镜像现在还不能运行在OpenShift上。我们正在修复解决这个问题,也就是说在Dockerfile中用一个非特权用户,我将向您展示如何暂时规避这个问题。

开始使用OpenShift

使用OpenShift可以从minishift开始,他是一个定制的minikube,也就是说,它可以运行在你桌面系统的虚拟机里(就像k8s)。客户端oc(译者注:oc是OpenShift的主要命令)可以被非常容易的配置,因为他实际上是在kubectl外面包装了一层。

当你下载后,使用它感觉就像在使用minikube一样:(除了它默认的驱动是xhyve,当然如果你用的是Virtual Box......):

minishift start — vm-driver virtualbox

把oc添加到你的PATH中:

$ minishift oc-env

export

PATH=”/Users/sebgoa/.minishift/cache/oc/v1.5.0:$PATH”

Run this command to configure your shell:


eval $(minishift oc-env)


$ eval $(minishift oc-env)

修改SCC

为了修改SCC,你需要用admin用户登录到OpenShift中:

oc login -u sysadmin:admin

这时修改scc:

oc edit scc anyuid

如果你不使用admin用户登录,那么RBAC不会让你修改安全约束(security constraints),这时增加user会像这样:

users:

- system:serviceaccount:default:ci

- system:serviceaccount:ci:default

- system:serviceaccount:myproject:default

基本上,你在你自己的项目里(myproject)可以用默认的服务帐号(service account)以任何uid包括ROOT用户去在运行一个容器。需要注意的是,你自己创建的项目(myproject)是一个可以用被你自己访问的名字空间。它是默认被minishift创建的,你可以用oc config view在k8s中找到它。

作为普通用户切换回minishift( oc config just like kubectl config ):

oc config use-context minishift

用容器创建一个应用程序,并以ROOT身份运行一个进程

你现在可以用容器去创建一个应用程序了,并且这个应用程序的进程是ROOT用户运行的。你解除了pod的安全规则。但是这部太符合最小权限运行原则。oc new-app看起来很像kubectl run

oc new-app --name foobar \

          --docker-image bitnami/mariadb \

          --env MARIADB_ROOT_PASSWORD=root

现在你已经运行起来了bitnami mariadb在OpenShift里了,( oc logs like kubectl logs :

$ oc logs foobar-1-zft17

Welcome to the Bitnami mariadb container

Subscribe to project updates by watching https://github.com/bitnami/bitnami-docker-mariadb

Submit issues and feature requests at https://github.com/bitnami/bitnami-docker-mariadb/issues

Send us your feedback at containers@bitnami.com

nami INFO Initializing mariadb

mariadb INFO ==> Configuring permissions…

mariadb INFO ==> Validating inputs…

mariadb INFO ==> Initializing database…

...<snip>

结论

虽然在OpenShift里可以绕过默认的安全约束策略(SCC)但其实这并不是一个理想状态。这就是为什么在Bitnami中,我们现在去修改我们的容器应用模板去harden它们并且让它讷讷个够和运行在OpenShift中。

DOCKONE.png

原文来自:Docker

掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务
新闻动态 > 媒体报道
在OpenShift中运行容器
发布:2017-05-23

本文不是一篇关于如何在OpenShift中使用和部署容器的指导性文章,也没有具体介绍OpenShift的原理组成,关于如何使用OpenShift可以参考另一篇《OpenShift V3 应用发布部署的简单场景演示》。

本文的关注点在于OpenShift中的容器安全性问题,相信很多用过容器的读者都会遇到在容器里以root用户启动应用的情况,这篇文章着重介绍了OpenShift中我们如何处理这种情况,以及这样处理带来的副作用和其中的原因。

OpenShift 是Red Hat公司推出的一个基于Kubernetes的容器应用平台。并且很简捷,没错,它就是一个PaaS。新的V3版本的OpenShift做了一次重大的改变,所有的组件用go语言重新编写,并且和现在的Kubernetes有了很好的结合。当你使用OpenShift的时候,你其实得到了一个Red Hat推出的基于Kubernetes的分布式系统,OpenShift的功能是围绕着代码部署,自动化构建等等,是一个典型的PaaS平台。

OpenShift的优点是什么呢?Red Hat经常引以为豪的就是它的安全性。

我不是一个安全领域的专家,但是当你考虑使用Kubernetes并且如果你不想围绕secrets争论的时候,你会发现,Kubernetes有很多关于安全性的功能。RBAC就是一个当你用kubeadm去部署一个集群环境时默认的设置。可以通过强制的网络规则进行网络隔离,pod也可以用安全策略控制非常严格。加上身份验证机制,为所有组建间的通信提供TSL加密,权限控制,至少对我来说,这是一个非常强大和安全系统。

但是对早期的使用者来说这些安全设置是有代价的。在OpenShift中,使用Kubernetes默认的Pod安全策略,他们被SCC(Security Context Constraints)调用。默认使用SCC最明显的地方是在OpenShift的容器中,进程不能用ROOT用户运行。(译者注:表现为权限不够)

所以如果你在minishift里,没有指定一个非ROOT用户去运行一个Docker镜像,这肯定会失败。这意味着,非常遗憾,我们的Bitnami镜像现在还不能运行在OpenShift上。我们正在修复解决这个问题,也就是说在Dockerfile中用一个非特权用户,我将向您展示如何暂时规避这个问题。

开始使用OpenShift

使用OpenShift可以从minishift开始,他是一个定制的minikube,也就是说,它可以运行在你桌面系统的虚拟机里(就像k8s)。客户端oc(译者注:oc是OpenShift的主要命令)可以被非常容易的配置,因为他实际上是在kubectl外面包装了一层。

当你下载后,使用它感觉就像在使用minikube一样:(除了它默认的驱动是xhyve,当然如果你用的是Virtual Box......):

minishift start — vm-driver virtualbox

把oc添加到你的PATH中:

$ minishift oc-env

export

PATH=”/Users/sebgoa/.minishift/cache/oc/v1.5.0:$PATH”

Run this command to configure your shell:


eval $(minishift oc-env)


$ eval $(minishift oc-env)

修改SCC

为了修改SCC,你需要用admin用户登录到OpenShift中:

oc login -u sysadmin:admin

这时修改scc:

oc edit scc anyuid

如果你不使用admin用户登录,那么RBAC不会让你修改安全约束(security constraints),这时增加user会像这样:

users:

- system:serviceaccount:default:ci

- system:serviceaccount:ci:default

- system:serviceaccount:myproject:default

基本上,你在你自己的项目里(myproject)可以用默认的服务帐号(service account)以任何uid包括ROOT用户去在运行一个容器。需要注意的是,你自己创建的项目(myproject)是一个可以用被你自己访问的名字空间。它是默认被minishift创建的,你可以用oc config view在k8s中找到它。

作为普通用户切换回minishift( oc config just like kubectl config ):

oc config use-context minishift

用容器创建一个应用程序,并以ROOT身份运行一个进程

你现在可以用容器去创建一个应用程序了,并且这个应用程序的进程是ROOT用户运行的。你解除了pod的安全规则。但是这部太符合最小权限运行原则。oc new-app看起来很像kubectl run

oc new-app --name foobar \

          --docker-image bitnami/mariadb \

          --env MARIADB_ROOT_PASSWORD=root

现在你已经运行起来了bitnami mariadb在OpenShift里了,( oc logs like kubectl logs :

$ oc logs foobar-1-zft17

Welcome to the Bitnami mariadb container

Subscribe to project updates by watching https://github.com/bitnami/bitnami-docker-mariadb

Submit issues and feature requests at https://github.com/bitnami/bitnami-docker-mariadb/issues

Send us your feedback at containers@bitnami.com

nami INFO Initializing mariadb

mariadb INFO ==> Configuring permissions…

mariadb INFO ==> Validating inputs…

mariadb INFO ==> Initializing database…

...<snip>

结论

虽然在OpenShift里可以绕过默认的安全约束策略(SCC)但其实这并不是一个理想状态。这就是为什么在Bitnami中,我们现在去修改我们的容器应用模板去harden它们并且让它讷讷个够和运行在OpenShift中。

DOCKONE.png

原文来自:Docker

电话 0512-88869195