在国产化服务器环境中，银河麒麟高级服务器操作系统 V10 已被广泛应用于政务、金融和能源等行业的基础设施。当业务迁移到 Kubernetes 后，容器安全不再只是镜像有没有漏洞，还包括工作负载是否以特权模式运行、是否挂载了宿主机敏感目录、RBAC 权限是否过大等。Starboard 作为 Kubernetes 原生的安全工具，通过扫描集群中的各类资源并把结果以 CRD 形式保存，天然适合与银河麒麟上的容器平台结合。本文将围绕部署和仪表板展示展开，所有步骤均以银河麒麟 V10 的终端环境为基准。
一、银河麒麟系统与容器平台准备
银河麒麟高级服务器操作系统 V10 的内核和用户态工具链与主流的 Linux 发行版保持较好的兼容性，支持 systemd 服务管理，默认使用 RPM 包管理。在安装 Starboard 之前，需要先准备一个可用的 Kubernetes 集群。如果已有集群，可以跳过集群安装步骤，但需要确认 kubectl 版本、容器运行时和权限模型满足要求。Starboard 依赖 Kubernetes 的自定义资源定义，因此集群版本不能过旧，建议使用 1.21 及以上版本。
首先安装容器运行时，例如 containerd。银河麒麟的软件源中通常包含 containerd 和 docker-ce，可以直接使用 yum 或 dnf 安装。安装完成后需要配置 cgroup 驱动和镜像加速，再启动服务。下面命令演示了安装 containerd 并启动的基本过程。
sudo yum install -y containerd.io sudo systemctl enable --now containerd sudo ctr version
在安装 Kubernetes 组件时，需要添加阿里云或内部镜像源，并安装 kubeadm、kubelet、kubectl。国产化环境中经常会遇到镜像拉取失败的问题，建议提前准备离线镜像仓库或配置镜像加速。集群初始化完成后，使用 kubectl get nodes 确认节点状态为 Ready。只有当节点全部就绪且核心组件运行正常时，才能继续部署 Starboard，否则扫描任务可能因为 API Server 连接不稳定而失败。
还需要确认当前登录用户对集群具备足够的权限。Starboard Operator 需要创建自定义资源定义、读取所有命名空间的工作负载信息，并在扫描完成后写入报告对象。建议使用具有 cluster-admin 权限的 kubeconfig 文件，或者至少保证用户拥有相应的 RBAC 绑定，避免在安装过程中出现权限不足的错误。
二、安装 Starboard Operator 并初始化
Starboard 提供命令行工具和 Operator 两种使用方式。CLI 适合临时扫描，Operator 则适合持续监控。对于仪表板场景，推荐使用 Operator，因为它能自动检测新创建的工作负载并触发扫描。安装 Operator 之前需要先获取 Starboard 的部署清单，然后通过 kubectl apply 部署。部署清单中会包含命名空间、服务账号、集群角色以及 Deployment 等资源。
由于银河麒麟环境中的容器镜像仓库访问可能受限，建议先把 Starboard Operator 的镜像同步到内网仓库，或配置镜像前缀。部署完成后，Operator 会在 starboard-system 命名空间中运行，并创建一系列 CRD，包括 VulnerabilityReport、ConfigAuditReport、CISKubeBenchReport 等。这些 CRD 是后续仪表板展示的数据来源，也是安全报告长期保存的基础。
kubectl apply -f starboard.yaml kubectl get pods -n starboard-system kubectl get crd | grep starboard
等待 Pod 就绪后，可以通过编辑 ConfigMap 来调整扫描策略。Starboard 默认会扫描所有命名空间，但可以通过配置 exclude 规则跳过系统命名空间，以减少扫描噪声。配置文件中的键值比较直观，建议至少保留漏洞扫描和配置审计两个模块。修改 ConfigMap 后，Operator 会自动重新加载部分配置，但某些参数可能需要重启 Pod 才能完全生效。
初始化过程中如果遇到镜像拉取失败，可以检查 Operator 的部署环境变量，确认镜像地址是否正确指向内网仓库。同时还需要注意，Starboard 在扫描镜像时需要拉取漏洞数据库，初次启动时可能会因为数据库下载较慢而出现短暂不可用。此时可以观察 Operator 日志，确认是否处于数据库初始化阶段。
三、执行安全扫描与报告解读
Operator 启动后，并不会立刻扫描已有工作负载，需要用户创建扫描触发器或重启工作负载。最简单的方式是给指定命名空间打上标签，或者直接运行一次 on-demand 扫描。Starboard 的 CLI 也能手动触发扫描并输出报告，适合在调试阶段快速验证配置是否正确。
下面命令使用 CLI 对 default 命名空间中的所有 Deployment 执行漏洞扫描，扫描结果会写入对应的 VulnerabilityReport CRD。这类报告属于命名空间级资源，可以使用 kubectl get vulnerabilityreports 查看。如果需要查看具体内容，可以使用 -o yaml 参数输出完整的报告结构。
starboard scan vulnerabilityreport --namespace default kubectl get vulnerabilityreports -n default kubectl get vulnerabilityreport -n default -o yaml
报告内容通常包括镜像名称、漏洞 ID、严重等级、修复版本和简要描述。严重等级分为 Critical、High、Medium、Low。需要注意的是，Starboard 的漏洞数据来源于上游的 Trivy 数据库，离线环境下需要定期更新数据库，否则报告可能不准确。配置审计报告则主要关注安全上下文、资源限制、只读根文件系统等项目，每一项都会有审计结果。
通过阅读这些 CRD 可以了解当前集群的安全状态，但 YAML 格式并不直观，尤其是当命名空间数量较多时，人工检查每个报告的工作量会迅速增加。这时就需要仪表板来聚合展示，把分散的报告转换成有序的风险视图。运营商团队不需要逐条解析 YAML，只需要打开 Web 界面即可查看哪些工作负载存在高危漏洞或配置缺陷。
四、部署 Octant 仪表板并加载 Starboard 插件
Octant 是一个面向 Kubernetes 开发者的 Web 界面工具，它支持插件机制，可以展示自定义资源。Starboard 官方提供了 Octant 插件，能够在浏览器中呈现漏洞报告、配置审计和 CIS 基准扫描结果。在银河麒麟系统上部署 Octant 非常轻量，只需要下载对应架构的二进制文件并运行即可，不需要额外部署数据库或后端服务。
安装 Octant 后，需要先启动 Octant 服务，它会在本地监听 7777 端口。为了加载 Starboard 插件，需要将插件二进制文件放到 Octant 的插件目录，并在启动参数中指定。由于银河麒麟可能运行在 ARM64 或 x86_64 架构上，下载时要注意选择正确架构。插件加载成功后，Octant 会在启动日志中输出相关信息。
octant --disable-open-browser --listener-addr 0.0.0.0:7777 # 插件目录示例 mkdir -p ~/.config/octant/plugins cp starboard-octant-plugin ~/.config/octant/plugins/
浏览器访问仪表板地址后，左侧导航栏会出现 Starboard 相关条目，点击即可查看不同命名空间下的安全报告。仪表板按照风险等级对漏洞进行排序，并用颜色标识严重程度，方便运维人员快速定位问题。对于配置审计，仪表板会列出每一项的通过、失败和警告状态，还可以直接跳转到对应的 Kubernetes 资源，查看具体的工作负载定义。
如果企业已有 Prometheus 和 Grafana 监控栈，也可以将 Starboard 的报告通过 exporter 暴露为指标，再在 Grafana 中构建统一的安全态势面板。这种方案更复杂，但适合已有监控体系的大型集群。对于中小型环境，直接使用 Octant 插件已经能够满足日常的安全查看需求，而且部署成本低，维护也相对简单。
五、策略优化与常见问题处理
在实际使用中，Starboard 默认策略可能会产生大量低级别的安全告警，影响仪表板的使用体验。可以通过修改 Operator 的 ConfigMap 来设置扫描范围、忽略规则和严重等级阈值。建议将系统命名空间排除，并只对业务命名空间启用自动扫描。这样既能降低扫描负载，也能让仪表板聚焦在真正需要关注的业务风险上。
国产化环境中常见的问题包括：镜像仓库证书不受信任、扫描数据库下载失败、插件无法连接 API Server 等。遇到镜像拉取失败时，可以检查 containerd 的配置文件是否设置了正确的镜像加速地址。遇到证书错误时，可以将内部仓库的 CA 证书添加到系统信任链中。遇到扫描数据库无法更新时，可以下载离线数据库文件并挂载到 Trivy 缓存目录，保证扫描结果的准确性。
另外，在银河麒麟的 SELinux 或安全模块开启时，Starboard Operator 可能需要额外的权限才能读取容器运行时信息。建议在测试环境中先关闭 SELinux，确认功能正常后再逐步收紧安全策略。通过上述配置和排错，就能在银河麒麟平台上稳定运行 Starboard 容器安全仪表板，为 Kubernetes 工作负载提供持续的安全可见性，同时降低安全团队的人工排查成本。