【容器集群安全】一文搞定K8s集群信息收集(1)——外部信息收集

原创

zhouzhou的奇妙编程

修改于 2025-02-02 19:01:07

1060

本文在Al1ex大佬文章的基础上进一步细化补充了各个部分内容，使其更加适合小白入门学习。

前言

在当今数字化迅速发展的背景下，Kubernetes（简称K8s）作为领先的容器编排平台，已经成为企业部署、扩展和管理容器化应用的首选工具。随着其广泛应用，确保Kubernetes集群的安全性变得至关重要。一个未妥善保护的Kubernetes集群可能成为攻击者的目标，导致数据泄露、服务中断甚至是整个网络的沦陷。因此，了解如何有效地收集和分析Kubernetes集群的安全信息，对于预防潜在威胁、及时响应安全事件具有不可忽视的重要性。

本文《一文搞定K8s集群安全信息收集(1)——外部信息收集》旨在为读者提供一套系统的方法论，从外部视角出发，探讨如何全面地收集影响Kubernetes集群安全性的相关信息。我们将深入介绍多种技术手段与工具的应用，包括但不限于节点信息、资源列表、命名空间、Pod信息、服务详情、组件日志以及SSH密钥等关键领域的探索与分析。通过这些方法，我们希望能够帮助读者建立对自身Kubernetes环境更清晰的认识，识别潜在的安全隐患，并采取有效措施加以防范。

本系列文章将分为多个部分发布，此篇作为开篇之作，重点聚焦于“外部信息收集”，即那些可以从集群外部获取的信息。这不仅有助于理解集群暴露在外的风险面，也为后续内部深入检查奠定了基础。接下来的内容将详细展开每个主题，结合实际命令示例，指导读者如何一步步进行有效的安全信息收集工作。让我们一同开启这段提升Kubernetes集群安全之旅吧。

外部信息

集群信息

在深入探讨K8s集群的安全信息收集之前，首先了解如何获取集群的基本信息是非常重要的。这些信息包括集群的服务地址、版本信息以及主要组件（如API服务器、控制器管理器等）的状态。通过下面的命令，我们可以快速查看集群的核心信息：

kubectl cluster-info

执行上述命令后，你将看到类似以下的输出结果：

Kubernetes master is running at https://your-cluster-ip:6443
KubeDNS is running at https://your-cluster-ip:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

Kubernetes master: 提供了API服务器的访问地址，这是与K8s集群进行交互的主要入口。
KubeDNS: 显示了Kubernetes集群中DNS服务的状态和位置，这对于服务发现至关重要。

集群列表

通过使用kubectl config get-clusters命令，我们可以轻松列出在本地配置文件中定义的所有集群。这对于那些需要管理多个集群的环境特别有用，因为它允许管理员快速查看和切换不同的集群上下文。

执行以下命令以获取配置中所有集群的列表：

kubectl config get-clusters

此命令将输出类似如下的信息，显示你本地配置文件中所有的集群名称：

your-cluster-name-1
your-cluster-name-2
another-cluster-name

用户列表

在Kubernetes环境中，了解当前配置文件中定义的用户信息对于管理和维护集群安全至关重要。尽管kubectl config get-contexts命令主要用于列出当前配置中的上下文（即集群、用户和命名空间的组合），我们可以结合其他命令来获取详细的用户列表及其相关信息。

首先，让我们看看如何使用kubectl config get-contexts命令来查看所有已配置的上下文：

kubectl config get-contexts

执行上述命令后，你将看到类似如下的输出结果，其中包含各个上下文的详细信息，比如集群名称、用户以及当前使用的命名空间等：

CURRENT   NAME                 CLUSTER              AUTHINFO             NAMESPACE
*         context-one          cluster-one          user-one             default
          context-two          cluster-two          user-two             kube-system

这里的AUTHINFO列实际上对应于用户配置项的名称，它指示了每个上下文关联的用户。

为了进一步获取有关用户的详细信息，可以使用如下命令查看特定用户或所有用户的配置详情：

kubectl config view --minify --flatten

该命令会显示一个精简且完全展开的配置视图，包括所有用户及其认证信息（如客户端证书、令牌等）。注意，出于安全考虑，敏感信息可能会被隐藏或加密，具体取决于你的配置。

环境变量

环境变量不仅影响着容器内应用程序的行为，还可能涉及到认证信息、服务发现等多个关键领域。正确配置和保护这些变量对于确保应用的安全性和稳定性至关重要。

使用env命令可以列出当前会话中的所有环境变量。这对于检查与Kubernetes相关的配置（如访问API服务器的凭证、命名空间等）特别有用。以下是获取当前环境变量的方法：

env

执行上述命令后，你将看到一系列以KEY=VALUE形式列出的环境变量，其中包含了系统环境、用户定义的变量以及其他相关设置。为了更好地理解哪些环境变量与Kubernetes直接相关，这里有几个常见的例子：

KUBECONFIG: 指定Kubernetes配置文件的位置，默认情况下为~/.kube/config。通过修改此变量，可以在不同的配置文件之间轻松切换。
NAMESPACE: 如果设置了此变量，它将指定默认使用的命名空间，避免每次执行kubectl命令时都需要手动指定--namespace选项。
HTTP_PROXY, HTTPS_PROXY, NO_PROXY: 这些代理相关的环境变量用于配置网络请求如何通过代理服务器转发，对于那些需要通过代理访问外部资源的应用来说非常重要。

为了更专注于与Kubernetes相关的环境变量，我们可以使用env | grep KUBE命令来过滤出那些名称中包含KUBE关键词的环境变量。这种方法可以快速定位到对Kubernetes集群管理至关重要的特定配置项。

执行以下命令以列出所有与Kubernetes相关的环境变量：

env | grep KUBE

看到类似如下的输出结果，具体取决于配置和设置：

KUBECONFIG=/path/to/your/kubeconfig
KUBERNETES_SERVICE_HOST=your-kubernetes-api-server-host
KUBERNETES_SERVICE_PORT=6443
KUBERNETES_PORT=tcp://your-kubernetes-api-server-host:6443
KUBERNETES_PORT_443_TCP=tcp://your-kubernetes-api-server-host:6443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_PORT=6443
KUBERNETES_PORT_443_TCP_ADDR=your-kubernetes-api-server-host

KUBECONFIG: 指定了kubeconfig文件的位置，该文件包含了访问Kubernetes集群所需的所有信息，包括集群位置、认证信息等。如果设置了此变量，它将覆盖默认的~/.kube/config路径。
KUBERNETES_SERVICE_HOST 和 KUBERNETES_SERVICE_PORT: 这两个变量通常在Pod内部可用，它们提供了API服务器的地址和端口，允许应用程序直接与Kubernetes API进行通信。
KUBERNETES_PORT, KUBERNETES_PORT_443_TCP, KUBERNETES_PORT_443_TCP_PROTO, * KUBERNETES_PORT_443_TCP_PORT, KUBERNETES_PORT_443_TCP_ADDR: 这些变量进一步描述了如何连接到Kubernetes API服务，包括协议类型（通常是TCP）、端口号以及地址。

配置信息

默认情况下，Kubernetes使用位于用户主目录下的.kube/config文件来存储访问集群所需的信息。通过查看这个文件的内容，你可以了解到当前配置的集群、上下文、用户认证信息等重要细节。

执行以下命令查看位于/home/r00t/.kube/config路径下的Kubernetes配置文件内容：

#上方路径
cat /home/r00t/.kube/config

请注意，直接查看或共享此文件时应格外小心，因为它可能包含敏感信息，如API服务器地址、证书数据和令牌等。以下是配置文件的一个简化示例：

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://your-cluster-ip:6443
  name: your-cluster-name
contexts:
- context:
    cluster: your-cluster-name
    user: your-user-name
  name: your-context-name
current-context: your-context-name
kind: Config
preferences: {}
users:
- name: your-user-name
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

clusters: 包含一个或多个集群的定义，每个集群条目至少包含服务器地址（API服务器的URL）和用于验证服务器身份的证书数据。
contexts: 定义了如何在特定集群中使用特定用户的身份进行操作。上下文结合了集群名称和用户名称，允许快速切换不同的集群和用户组合。
current-context: 显示当前使用的上下文名称，指定了你当前正在与哪个集群交互以及使用哪个用户的身份。
users: 列出了访问集群所需的所有用户凭证。这通常包括客户端证书和私钥，有时也可能包含Bearer令牌或其他形式的认证信息。

节点信息

节点是Kubernetes集群中实际运行容器的工作机器，可以是物理机或虚拟机。获取节点列表以及它们的状态可以帮助我们快速识别潜在的问题，并进行相应的维护工作。

要查看集群中的所有节点及其状态，可以使用以下命令：

#节点列表
kubectl get nodes

执行此命令后，你将看到类似如下的输出结果，它列出了每个节点的名字、状态、角色、版本以及其他一些基本信息：

NAME      STATUS   ROLES    AGE     VERSION
node1     Ready    <none>   3d22h   v1.24.0
node2     Ready    <none>   3d21h   v1.24.0

这里的STATUS字段显示了节点是否准备好接受负载(Ready)或其他状态（例如NotReady），这对于监控集群健康状况非常有用。

为了进一步确认各个节点的网络连通性和响应速度，我们可以使用ping命令对每个节点进行简单的连通性测试。以下是针对两个示例节点node1和node2的命令：

# 对node1进行连通性测试
ping node1 -c 1

# 对node2进行连通性测试
ping node2 -c 1

上述命令中的-c 1参数限制了仅发送一个ICMP回显请求，这有助于减少测试时间并降低对网络的影响。如果节点名称不能直接解析为IP地址，请确保使用可解析的主机名或直接使用节点的IP地址代替。

执行ping node1 -c 1后，会看到如下输出：

PING node1 (192.168.1.10) 56(84) bytes of data.
64 bytes from 192.168.1.10 (192.168.1.10): icmp_seq=1 ttl=64 time=0.345 ms

--- node1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.345/0.345/0.345/0.000 ms

该输出表明与node1的连接正常，且响应时间为0.345毫秒。

资源列表

通过使用kubectl get all命令，可以快速获取当前命名空间下几乎所有类型的资源的概览，包括Pods、Services、Deployments、ReplicaSets等。这为管理员提供了一个全面的视角来监控和管理他们的应用和服务。

执行以下命令以列出当前命名空间下的所有资源：

kubectl get all

你将看到类似如下的输出结果，它列出了不同类型的资源及其状态：

NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
service/kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP    10d

NAME                         READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/example-dep  1/1     1            1           5m

NAME                                    DESIRED   CURRENT   READY   AGE
replicaset.apps/example-dep-7bf6db4f8   1         1         1       5m

NAME                       READY   STATUS    RESTARTS   AGE
pod/example-pod            1/1     Running   0          5m

Service: 提供了一种抽象的方法来暴露应用，允许网络流量被路由到正确的Pod上。上面的例子展示了一个名为kubernetes的服务，它是默认创建的，用于访问API服务器。
Deployment: 定义了期望的应用状态，并负责维持该状态。示例中的example-dep部署确保了一个副本集始终运行着指定数量的Pod实例。
ReplicaSet: 确保在任何给定时间都有指定数量的Pod副本正在运行。尽管直接操作ReplicaSet并不常见，它们通常由更高层次的控制器（如Deployments）管理。
Pod: 是Kubernetes中最小的可部署单元，包含一个或多个容器。上述例子中的example-pod展示了其状态、重启次数以及已运行的时间。

对于更详细的资源信息，可以添加-o wide选项来扩展输出详情，或者使用describe命令深入查看特定资源的详细信息。例如：

# 获取更多关于某个Pod的信息
kubectl describe pod example-pod

# 或者获取更加详细的列表
kubectl get all -o wide

这些命令有助于深入了解资源的配置、事件历史以及其他有用的调试信息。

命名空间

在Kubernetes中，命名空间（Namespaces）提供了一种将集群资源划分为多个虚拟集群的方法。这对于大型分布式系统或拥有多个团队的组织来说特别有用，因为它允许你根据项目、团队或环境来划分资源，从而实现更好的资源隔离和管理。

使用kubectl get namespaces命令可以列出当前Kubernetes集群中所有的命名空间，这有助于管理员快速了解集群中的逻辑分区情况，并进行相应的资源配置和权限管理。

执行以下命令以查看所有命名空间：

kubectl get namespaces

执行该命令后，你可能会看到类似如下的输出结果：

NAME              STATUS   AGE
default           Active   10d
kube-system       Active   10d
kube-public       Active   10d
kube-node-lease   Active   10d
development       Active   5d
testing           Active   3d
production        Active   2d

default: 每个新创建的资源如果没有指定命名空间，则默认属于此命名空间。
kube-system: 由Kubernetes系统组件使用的命名空间，包括核心服务如API服务器、调度器等。
kube-public: 此命名空间是自动创建的，并且对于所有用户都是可读的（包括未认证的用户），主要用于公开访问的信息。
kube-node-lease: 包含与节点心跳相关的Lease对象，用于提高节点状态检测的效率。
development, testing, production: 这些是自定义命名空间的例子，通常按照应用生命周期的不同阶段或者不同的业务部门来划分。

Pod信息

Pod是Kubernetes中最小的可部署单元，它包含一个或多个容器、共享存储（卷）、IP地址以及如何运行容器的选项。了解Pod的状态和配置对于确保应用程序的健康运行至关重要。通过使用kubectl get pod命令，可以快速获取当前命名空间下所有Pod的基本信息。

执行以下命令以列出当前命名空间下的所有Pod：

#获取Pod
kubectl get pod

将看到类似如下的输出结果，其中包含了每个Pod的名字、准备就绪状态、重启次数以及运行时间等信息：

NAME                        READY   STATUS    RESTARTS   AGE
example-pod-1               1/1     Running   0          2m
example-pod-2               1/1     Running   0          2m
frontend-6789fcd45b-4j7bz   2/2     Running   0          3d
backend-5c67b97f4d-2nqz8    1/1     Running   1          5d

READY: 显示了Pod中预期的容器数量与实际准备好提供服务的容器数量的比例。例如，2/2表示该Pod中有两个容器，并且两者都已准备好。
STATUS: 描述了Pod的当前状态，常见的状态包括：
Pending: Kubernetes正在创建Pod。
Running: Pod已经被绑定到某个节点上，所有容器已被创建并且至少有一个容器正在运行。
Succeeded: Pod中的所有容器都已成功退出并且不会被重启。
Failed: 所有容器都已终止，但至少有一个容器以失败状态结束。
Unknown: 由于某种原因无法获取Pod的状态。
RESTARTS: 表示容器被重启的次数。频繁的重启可能指示存在问题，需要进一步调查。
AGE: Pod已经运行的时间长度。

若要获取特定Pod的更详细信息，可以使用describe命令：

#Pod详细信息
kubectl describe pod example-pod-1

这将提供关于指定Pod的详细信息，包括其事件历史、使用的镜像、环境变量、挂载的卷等，这对于排查问题非常有用。

以YAML格式获取指定Pod的完整定义和当前状态。这种方法不仅展示了Pod创建时的原始配置，还提供了运行时的状态细节，这对于调试和审计非常有用。

执行以下命令来查看特定Pod的详细信息（请将<pod-name>替换为实际的Pod名称）：

#yaml格式显示Pod的详细信息
kubectl get pod <pod-name> -o yaml

例如，如果你想要查看名为example-pod-1的Pod详情，命令如下：

kubectl get pod example-pod-1 -o yaml

部分输出示例：

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2025-02-02T08:47:18Z"
  name: example-pod-1
  namespace: default
  labels:
    app: web
spec:
  containers:
  - name: example-container
    image: nginx:latest
    ports:
    - containerPort: 80
    env:
    - name: ENVIRONMENT
      value: "production"
  restartPolicy: Always
status:
  phase: Running
  conditions:
  - type: Initialized
    status: "True"
    lastProbeTime: null
    lastTransitionTime: "2025-02-02T08:47:18Z"
  ...
  containerStatuses:
  - name: example-container
    state:
      running:
        startedAt: "2025-02-02T08:47:23Z"
    ready: true
    restartCount: 0
    image: nginx:latest
    ...

这将返回一个详细的YAML文档，内容包括但不限于：

metadata: 包含Pod的名字、命名空间、标签等元数据。
spec: 描述了Pod的期望状态，包括容器定义、卷挂载、环境变量等。
status: 提供了Pod的实际状态信息，如条件（conditions）、容器状态（container statuses）、事件（events）等。

通过使用kubectl get pods --all-namespaces -o wide命令，可以列出所有命名空间中的所有Pod，并提供扩展的信息，如节点名称、IP地址等。这对于跨多个命名空间管理资源或进行故障排查尤其有用。

执行以下命令以获取所有Pod的详细列表：

#获取所有pod信息
kubectl get pods --all-namespaces -o wide

此命令将输出一个包含所有命名空间下Pod的详细信息表格，类似于下面的格式：

NAMESPACE     NAME                              READY   STATUS    RESTARTS   AGE     IP               NODE         NOMINATED NODE   READINESS GATES
default       example-pod-1                     1/1     Running   0          2m      10.244.0.4       node1        <none>           <none>
kube-system   kube-dns-6fc95b5b5d-7jz8f         3/3     Running   0          10d     10.244.1.3       node2        <none>           <none>
development   dev-app-5c67b97f4d-2nqz8          1/1     Running   1          5d      10.244.0.10      node1        <none>           <none>
testing       test-service-697c97f8d4-g4v5h     2/2     Running   0          3d      10.244.1.7       node2        <none>           <none>
production    prod-backend-7bf6db4f8d-9g7p5     1/1     Running   0          2d      10.244.0.15      node1        <none>           <none>

NAMESPACE: Pod所属的命名空间。
NAME: Pod的名字。
READY: 显示了Pod中预期的容器数量与实际准备好提供服务的容器数量的比例。
STATUS: 描述了Pod的当前状态（如Running, Pending, Succeeded等）。 * RESTARTS: 容器重启的次数，可以帮助识别潜在的问题。
AGE: Pod已经运行的时间长度。
IP: Pod被分配的内部IP地址，用于在集群内部通信。
NODE: Pod正在运行所在的节点名称。
NOMINATED NODE: 如果存在，则指示该Pod可能被调度到哪个节点上。
READINESS GATES: 提供额外的状态检查机制，确保Pod只有在其特定条件满足时才被认为是准备就绪的。

服务信息

在Kubernetes中，服务（Service）是一种抽象方式，它定义了一组逻辑Pod及其访问策略。服务为应用提供了稳定的IP地址和DNS名称，并且能够实现负载均衡。了解集群中的服务信息对于确保应用的可访问性和可靠性至关重要。

使用kubectl get service命令可以列出当前命名空间下的所有服务及其相关信息。这有助于管理员快速查看服务的状态、外部IP、端口映射等重要细节。

执行以下命令以获取当前命名空间下所有服务的信息：

kubectl get service

你将看到类似如下的输出结果，其中包含了每个服务的名字、类型、集群IP、外部IP、端口以及运行时间等信息：

NAME         TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE
kubernetes   ClusterIP      10.96.0.1       <none>           443/TCP        10d
web-service  LoadBalancer   10.100.200.12   203.0.113.1      80:30000/TCP   2d
api-service  NodePort       10.100.201.45   <none>           8080:30001/TCP 1d
db-service   ClusterIP      10.100.202.78   <none>           5432/TCP       3d

ClusterIP: 默认的服务类型，提供了一个集群内部可以访问的虚拟IP地址。这种类型的服务仅在集群内部可用。
NodePort: 在每个节点的IP上开放一个特定端口，并将该端口上的流量转发到对应的服务。这种方式允许从集群外部访问服务。
LoadBalancer: 对于支持外部负载均衡器的云提供商，此类型会创建一个外部负载均衡器，并将流量分配给服务。通常用于需要公开访问的应用程序。
ExternalName: 将服务映射到一个外部的服务名，通过CNAME记录直接返回指定的外部域名。

若要深入了解某个服务的具体配置和状态，可以使用describe命令：

kubectl describe service web-service

这将提供关于指定服务的更详细信息，包括其端点（Endpoints）、选择器（Selectors）、标签（Labels）、注解（Annotations）以及相关的事件日志，这对于故障排查非常有用。

DPLM信息

在Kubernetes中，Deployment是一种控制器对象，它提供了一种管理Pod的声明式方法。通过使用Deployment，可以轻松实现应用的滚动更新、回滚以及扩展等操作。了解集群中Deployment的基础信息对于确保应用程序的可用性、版本管理和故障恢复至关重要。

使用kubectl get deployment命令可以列出当前命名空间下的所有Deployment及其相关信息。这有助于管理员快速查看每个Deployment的状态、期望的副本数量、当前的副本数量以及其他关键细节。

执行以下命令以获取当前命名空间下所有Deployment的信息：

#deployment基础信息
kubectl get deployment

看到类似如下的输出结果，其中包含了每个Deployment的名字、期望的副本数与实际运行的副本数、更新策略、状态以及运行时间等信息：

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
web-deployment     3/3     3            3           2d
api-deployment     2/2     2            2           1d
backend-deployment 1/1     1            1           3d

若要深入了解某个Deployment的具体配置和状态，可以使用describe命令：

kubectl describe deployment web-deployment

这将提供关于指定Deployment的更详细信息，包括其容器镜像、标签选择器、环境变量、卷挂载、事件历史记录等，这对于故障排查和管理非常有用。

日志信息

系统日志

要查看系统级别的日志，通常可以访问位于/var/log/messages的文件（具体路径可能因操作系统而异）。这个文件包含了系统级事件的日志信息，如服务启动、硬件错误、内核消息等。这对于诊断与节点或基础设施相关的问题非常有用。

执行以下命令以查看系统日志：

#系统日志
cat /var/log/messages

由于直接使用cat命令可能会输出大量信息，因此更常用的做法是结合grep或其他工具来过滤出感兴趣的部分。例如，如果你想查找与某个特定服务相关的错误信息，可以这样做：

grep "error" /var/log/messages

或者，如果需要实时查看日志更新，可以使用tail -f命令：

tail -f /var/log/messages

这将使终端持续显示新添加到日志文件中的内容，非常适合用于实时监控。

组件日志

在Kubernetes集群中，核心组件的日志对于监控和故障排查至关重要。这些组件包括API服务器（kube-apiserver）、调度器（kube-scheduler）、控制器管理器（kube-controller-manager）、kubelet等。它们各自负责集群的不同功能，其日志信息可以帮助我们了解集群内部的工作状态、识别潜在问题并进行相应的维护。

使用journalctl命令可以方便地查看这些系统服务的日志信息。以下是如何查看特定Kubernetes组件日志的方法。

要查看Kubernetes API服务器的日志，可以使用如下命令：

journalctl -u kube-apiserver

此命令将输出API服务器的所有日志条目。为了便于分析最近的活动或错误，你可以结合-f选项实时跟踪日志更新：

journalctl -u kube-apiserver -f

同样，你可以查看kube-scheduler的日志以了解任务调度的情况：

journalctl -u kube-scheduler

如果只想查看最新的几行日志，可以使用-n选项指定行数：

journalctl -u kube-scheduler -n 50

这将显示kube-scheduler的最后50条日志记录。

Kubelet是运行在每个节点上的主要“节点代理”，它确保容器都在Pod中健康运行。查看kubelet的日志有助于诊断与节点相关的各种问题：

journalctl -u kubelet | tail

上述命令将展示kubelet日志的最后一部分，这对于快速检查最近发生的事件非常有用。

除了上述组件之外，其他重要的Kubernetes组件还包括：

#kube-controller-manager: 使用类似的方式查看其日志：
journalctl -u kube-controller-manager

#Kubernetes依赖于etcd作为其后端存储，查看etcd日志对理解集群状态也很有帮助
journalctl -u etcd

容器日志

在Kubernetes环境中，容器日志对于监控应用健康状况、调试问题以及进行安全审计至关重要。虽然Kubernetes本身提供了查看Pod内容器日志的方法（通过kubectl logs命令），但在某些情况下，你可能需要直接访问Docker或其他容器运行时的日志来获取更详细的调试信息。

使用Docker查看容器日志

如果你的集群使用Docker作为容器运行时，可以使用docker logs命令来查看特定容器的日志。这在直接与节点交互以排查底层问题时特别有用。

要查看某个容器的日志，请先找到该容器的ID或名称，然后执行以下命令：

#容器日志
docker logs <容器ID>

例如，如果你想查看ID为abc123def456的容器日志，你可以这样操作：

docker logs abc123def456

为了实时跟踪日志输出，可以添加-f选项：

docker logs -f abc123def456

此外，若只想查看最近的日志条目，可以使用--tail参数指定行数：

docker logs --tail 50 abc123def456

这将显示容器的最后50条日志记录。

使用Kubernetes查看容器日志

尽管可以直接通过Docker查看容器日志，但推荐的方式是使用Kubernetes提供的工具来进行日志管理，因为这种方法更加集成且便于跨环境使用。

要查看Kubernetes Pod中容器的日志，可以使用kubectl logs命令：

kubectl logs <pod-name>

如果Pod中有多个容器，则需要指定容器名称：

kubectl logs <pod-name> -c <container-name>

为了查看之前终止的容器的日志，可以加上--previous选项：

kubectl logs <pod-name> --previous

这对于分析导致容器崩溃的原因非常有用。

SSH私钥

SSH（Secure Shell）是一种加密网络协议，用于在不安全的网络中安全地远程登录到计算机系统。SSH密钥对通常包括一个私钥和一个公钥，它们被广泛用于服务器访问、Git版本控制系统的认证以及Kubernetes集群的访问等多种场景。然而，SSH私钥是敏感信息，不当处理可能会导致严重的安全风险。

首先，可以通过以下命令查看用户主目录下的文件列表，确认.ssh目录是否存在：

ls -al ~/

这条命令将列出用户主目录中的所有文件和目录，并显示详细的权限信息。查找类似如下的输出行以确认.ssh目录的存在：

drwx------  2 user user 4096 Feb  2 16:35 .ssh

接下来，进入.ssh目录查看其中的内容：

ls -al ~/.ssh

这将展示.ssh目录内的所有文件及其权限设置，例如：

-rw-------  1 user user 1679 Feb  2 16:35 id_rsa
-rw-r--r--  1 user user  406 Feb  2 16:35 id_rsa.pub
-rw-r--r--  1 user user 1856 Feb  2 16:35 known_hosts

这里，id_rsa是你的私钥文件，而id_rsa.pub则是对应的公钥文件。

直接使用cat命令查看私钥文件的内容：

cat ~/.ssh/id_rsa

历史命令

在Linux系统中，.bash_history文件记录了用户通过Bash shell执行的命令历史。这些记录对于用户回顾之前的操作、快速重复常用的命令非常有用。然而，该文件也可能包含敏感信息，如服务器地址、用户名、密码等，尤其是在手动输入包含密码的命令时（例如通过mysql -u user -p password或curl请求中包含API密钥）。因此，定期检查和清理.bash_history中的敏感信息是保护系统安全的重要步骤。

要查看用户的命令历史记录，可以使用以下命令：

cat ~/.bash_history

这将输出存储在.bash_history文件中的所有命令列表，按它们被输入的顺序排列。例如：

ssh user@192.168.1.10
mysql -u root -p mypassword
git clone https://username:password@github.com/repo.git

可以看出，直接在命令行中输入密码是非常不安全的做法，因为这些信息会被明文记录在bash_history中。

面板相关

在Kubernetes环境中，仪表板（如 Kubernetes Dashboard）提供了一个基于Web的用户界面，使得管理和监控集群变得更加直观和便捷。通过这个界面，您可以查看集群的状态、部署应用、调试问题等。为了确保面板服务正常运行并可访问，定期检查其Pod和服务状态是十分必要的。

使用kubectl get pods,svc -n kubernetes-dashboard -o wide命令可以查看与Kubernetes Dashboard相关的Pod和服务的详细信息。这有助于确认面板是否正确部署以及服务是否能够正常访问。

执行以下命令以获取Kubernetes Dashboard命名空间下的所有Pod和服务的状态：

#查看面板pod和service状态
kubectl get pods,svc -n kubernetes-dashboard -o wide

该命令将输出类似如下信息：

NAME                                             READY   STATUS    RESTARTS   AGE     IP           NODE       NOMINATED NODE   READINESS GATES
pod/kubernetes-dashboard-7f99b75bf4-jnm8x        1/1     Running   0          3h20m   10.244.1.5   node1      <none>           <none>
pod/dashboard-metrics-scraper-76585494d8-9l7wq   1/1     Running   0          3h20m   10.244.2.4   node2      <none>           <none>

NAME                                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE     SELECTOR
service/kubernetes-dashboard        NodePort    10.100.200.80   <none>        443:30443/TCP   3h20m   k8s-app=kubernetes-dashboard
service/dashboard-metrics-scraper   ClusterIP   10.100.201.90   <none>        8000/TCP        3h20m   k8s-app=dashboard-metrics-scraper

#查看serviceaccount和secrets
kubectl get sa,secrets -n kubernetes-dashboard

获取token

在Kubernetes中，ServiceAccount通常用于为Pod提供访问Kubernetes API的凭据。每个ServiceAccount都会自动关联一个Secret，其中包含了一个用于认证的Bearer Token。这些Token对于通过API或Dashboard访问集群资源是必需的。因此，了解如何安全地查看和管理这些Token是非常重要的。

执行以下命令可以查看特定Secret中的Token信息。例如，如果你想要查看与kubernetes-dashboard相关的ServiceAccount的Token，可以使用如下命令：

kubectl describe secrets/kubernetes-dashboard-token-8kxnh -n kubernetes-dashboard

同样，如果有一个自定义的ServiceAccount（如admin-myuser），并且你想要获取其Token，可以使用类似的命令：

kubectl describe secret/admin-myuser-token-jcj9d -n kubernetes-dashboard

这些命令将输出类似下面的信息，其中包括了token字段，这是你需要用来登录Kubernetes Dashboard或其他需要API访问的地方：

Name:         kubernetes-dashboard-token-8kxnh
Namespace:    kubernetes-dashboard
Labels:       <none>
Annotations:  kubernetes.io/service-account.name=kubernetes-dashboard
              kubernetes.io/service-account.uid=0f3b45b2-7a1e-4c3c-ba8a-6df5556c7efb

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1025 bytes
namespace:  20 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6ImlvZUlScVlTQ2RtNjFwYmJqUmMwdW9LUTBFS1pXczJKemdSa2hTT2FadEUwUTF3USJ9...

小结

本文详细介绍了从外部角度对Kubernetes集群进行安全评估的方法，涵盖了节点、资源列表、命名空间、Pod和服务详情、组件及容器日志、SSH密钥安全以及历史命令的检查。通过具体命令示例，指导读者识别潜在的安全威胁，并强调了保护敏感信息和遵循最佳安全实践的重要性。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

腾讯技术创作特训营S11#重启人生

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

腾讯技术创作特训营S11#重启人生

#K8s集群安全

#信息收集