首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

通过Kyverno使用KMS、Cosign和工作负载身份验证容器镜像

随着软件供应链攻击的增加,保护我们的软件供应链变得更加重要。此外,在过去几年中,容器的采用也有所增加。有鉴于此,对容器镜像进行签名以帮助防止供应链攻击的需求日益增长。此外,我们今天使用的大多数容器,即使我们在生产环境中使用它们,也容易受到供应链攻击。在传统的 CI/CD 工作流中,我们构建镜像并将其推入注册中心。供应链安全的一个重要部分是我们构建的镜像的完整性,这意味着我们必须确保我们构建的镜像没有被篡改,这意味着保证我们从注册中心中提取的镜像与我们将要部署到生产系统中的镜像相同。证明镜像没有被篡改的最简单和最好的方法之一(多亏了 Sigstore)是在构建之后立即签名,并在允许它们部署到生产系统之前验证它。这就是 Cosign 和 Kyverno 发挥作用的地方。

02

JFrog助力Google Anthos混合云Devops实践,实现安全高质量的容器镜像管理

自Google Anthos推出以来在混合云领域受到极大关注,作为Google进入ToB混合云市场的战略级产品,Anthos集成了如GKE (Google Kubernetes Engine)、GKE On-Prem、Istio on GKE等……引起业界的关注。可以说这又是Google又一大利器。那么混合云作为企业数字化转型的重要基础设施建设,既留了核心数据,降低了迁移风险,又能在原来资源的基础上增加公共云的弹性,一举多得,成为当前云计算发展的热门话题。而作为数字化转型的另外一个风向标DevOps如何与当前的混合云发展进行协作,带向企业进入云原生时代,将会成日今后数字化建设的一个重要主题。

04

加密 K8s Secrets 的几种方案

你可能已经听过很多遍这个不算秘密的秘密了--Kubernetes Secrets 不是加密的!Secret 的值是存储在 etcd 中的 base64 encoded(编码)[1] 字符串。这意味着,任何可以访问你的集群的人,都可以轻松解码你的敏感数据。任何人?是的,几乎任何人都可以,尤其是在集群的 RBAC 设置不正确的情况下。任何人都可以访问 API 或访问 etcd。也可能是任何被授权在 Namespace 中创建 pod 或 Deploy,然后使用该权限检索该 Namespace 中所有 Secrets 的人。 如何确保集群上的 Secrets 和其他敏感信息(如 token)不被泄露?在本篇博文中,我们将讨论在 K8s 上构建、部署和运行应用程序时加密应用程序 Secrets 的几种方法。

02

容器编排常见工具介绍

容器编排是一种自动化管理容器化应用程序的技术,它涉及在大规模的分布式系统中部署、管理、扩展和协调容器的整个生命周期。容器编排工具让开发者和运维团队能够更高效地在集群环境中操作容器,确保服务的高可用性、负载均衡、自我修复及资源优化。 容器编排的核心价值在于: 1. 自动化部署:自动化的部署流程使得应用能够快速且一致地部署到生产环境,减少了手动干预带来的错误和时间消耗。 2. 资源管理:有效管理和分配计算、存储、网络等资源,确保容器按需获取资源,同时优化整体基础设施的利用率。 3. 扩展性:根据实际需求自动扩展或缩减容器数量,实现水平扩展,以应对流量高峰或低谷,保证服务的稳定性和响应速度。 4. 健康监测与自愈:持续监控容器和服务的运行状态,当检测到故障时自动重启容器或重新调度服务,保证应用的高可用性。 5. 服务发现与负载均衡:帮助容器发现和通信,自动实现请求的负载均衡,提高服务的稳定性和效率。 6.配置管理:集中管理和分发配置信息给容器应用,支持应用的动态配置更新,而不影响服务运行。 容器编排工具是用于自动化容器化应用程序的部署、管理和扩展的技术解决方案,它们在现代软件开发和运维中扮演着关键角色。 1. Kubernetes (K8s): Kubernetes 是目前最流行和广泛采用的容器编排平台,由 Google 开源并得到了 Cloud Native Computing Foundation (CNCF) 的支持。Kubernetes 提供了一整套强大的功能,包括部署管理、自动扩展、负载均衡、存储编排、网络管理以及故障恢复等。其设计目标是为了解决大规模容器化应用的自动化部署、扩展和运维问题。 2. Docker Swarm: Docker Swarm 是 Docker 自带的容器编排工具,它允许用户将一群Docker主机转变为一个单一的虚拟系统,进行容器化的应用部署和管理。Swarm 提供了服务发现、负载均衡、加密网络和滚动更新等功能,适合那些希望在Docker生态系统内工作且对易用性有较高要求的用户。 3. Apache Mesos: Mesos 是一个分布式系统内核,最初由UC Berkeley开发,旨在提供有效的资源隔离和共享跨分布式应用或框架。虽然Mesos本身不是一个专门针对容器的编排工具,但它可以通过集成如Marathon这样的框架来管理容器。Mesos擅长于跨数据中心的大规模资源管理和调度,适用于需要高度定制化和灵活性的大型企业环境。 4. OpenShift OpenShift 是由 Red Hat 开发的一个容器应用平台,它建立在 Kubernetes 之上,并增加了额外的功能,如内置的CI/CD流水线、应用商店、开发者工具和增强的安全策略等。OpenShift 提供了企业级的容器解决方案,既有开源版本(OpenShift Origin),也有商业支持的企业版(OpenShift Container Platform)。 5. Docker Compose: 虽然严格来说 Docker Compose 更多被用于单机容器编排,但在较小规模的部署或开发环境中也常被提及。它允许用户通过YAML文件定义多容器应用的服务及其依赖关系,简化了在单个Docker主机上部署和管理复杂应用的过程。 除了上述工具,市场上还存在其他一些编排解决方案,例如HashiCorp的Nomad,它以简洁和轻量级著称;以及云服务商提供的托管容器服务,如Google Kubernetes Engine (GKE)、Amazon Elastic Kubernetes Service (EKS) 和 Azure Kubernetes Service (AKS),这些服务在Kubernetes的基础上提供了额外的管理便利性和云原生集成。

01

Ingress 的继任者 —— Gateway API?

在 Kubernetes 集群边缘对外提供网络服务的时候,通常需要借助 Ingress 对象,这个对象提供了暴露 Service 所必须的核心要素,例如基于主机名的路由、对 URL 路径的适配以及 TLS 配置等。但是在实际开放服务的时候,往往会有更多的具体需求,这时 Ingress 对象所提供的核心功能就有些力不从心了,各种 Ingress 控制器往往会使用 metadata.annotations 中的特定注解,来完成对 Ingress 特定行为的控制,完成各自的个性化功能,例如认证、路径变更、黑白名单等,这就让 Ingress 对象变成了一个奇怪的东西:结构化的核心结构,和非结构化的标注结合起来形成各种 Ingress 方言,并且后期还出现了 Traefik Middleware 这样的 CRD 配置,这给 Ingress 功能的集中管理造成了一个较大的困扰;另外 Ingress 中可以随意定制主机名、路径以及后端服务,也给共享集群的用户造成了一定的安全隐患。包括 Cotour、Traefik 在内的 Ingress 控制器后期都提供了各自的基于 CRD 的功能表达,客观上也让 Ingress 世界更为分裂。 例如要移除路径前缀,Nginx Ingress 控制器需要使用 nginx.ingress.kubernetes.io/rewrite-target 注解,而 Traefik 1.7 中则需要使用 traefik.ingress.kubernetes.io/rule-type: PathPrefixStrip 注解。

06
领券