es.davy.ai

Preguntas y respuestas de programación confiables

¿Tienes una pregunta?

Si tienes alguna pregunta, puedes hacerla a continuación o ingresar lo que estás buscando.

system: el nodo no logra obtener secretos del apiserver a través de curl

27 Jul, 2023 Programación

Estoy haciendo una POC para la investigación de seguridad, intentando acceder directamente a los secretos del espacio de nombres desde un nodo de trabajador. Tengo un clúster en GKE ejecutando Kubernetes 1.20.

Estoy ejecutando el siguiente comando desde un nodo de trabajador (no maestro):

curl -v $APISERVER/api/v1/namespaces/default/pods/ \
  --cacert /etc/srv/kubernetes/pki/ca-certificates.crt \
  --cert /var/lib/kubelet/pki/kubelet-client.crt \
  --key /var/lib/kubelet/pki/kubelet-client.key

Y funciona bien.

Sin embargo, al intentar obtener los secretos, falla:

curl -v $APISERVER/api/v1/namespaces/default/secrets/ \
  --cacert /etc/srv/kubernetes/pki/ca-certificates.crt \
  --cert /var/lib/kubelet/pki/kubelet-client.crt \
  --key /var/lib/kubelet/pki/kubelet-client.key

{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "secrets is forbidden: User \"system:node:gke-XXX--YYY\" cannot list resource \"secrets\" in API group \"\" in the namespace \"pencil\": No Object name found",
  "reason": "Forbidden",
  "details": {
    "kind": "secrets"
  },
  "code": 403
}

Al consultar la documentación, veo que kubelet en el nodo debería poder acceder a los secretos: https://kubernetes.io/docs/reference/access-authn-authz/node/

Y según mi entendimiento, la autorización está respaldada por el ClusterRole system:node. Al examinarlo, veo que tiene el rol para “obtener” secretos:

% kubectl get clusterrole system:node -o json
{
    "apiVersion": "rbac.authorization.k8s.io/v1",
    "kind": "ClusterRole",
...
        {
            "apiGroups": [
                ""
            ],
            "resources": [
                "configmaps",
                "secrets"
            ],
            "verbs": [
                "get",
                "list",
                "watch"
            ]
        },
...
    ]
}

Y alguna documentación más relevante para la comunicación entre kubelet y kube-apiserver: https://kubernetes.io/docs/concepts/architecture/control-plane-node-communication/#node-to-control-plane

Tags:  , , , ,

Answer

  1. Avatar for davy.ai
    davy.ai

    Parece que el problema está relacionado con el espacio de nombres especificado en el comando curl. El mensaje de error indica que el usuario system:node:gke-XXX--YYY no tiene permiso para listar recursos en el grupo de recursos secrets en el espacio de nombres pencil.

    Para acceder a los secretos, debes añadir el recurso del espacio de nombres a la solicitud de la API. Por ejemplo, para acceder a los secretos en el espacio de nombres por defecto, el comando sería:

    curl -v $APISERVER/api/v1/namespaces/default/secrets/ \
  --cacert /etc/srv/kubernetes/pki/ca-certificates.crt \
  --cert /var/lib/kubelet/pki/kubelet-client.crt \
  --key /var/lib/kubelet/pki/kubelet-client.key

    Además, es importante asegurarse de que ClusterRoleBinding para system:node permita que el node específico acceda a los secretos solicitados en el namespace específico. Para ello, puedes crear un RoleBinding que otorgue permisos al grupo system:node y al nombre específico del nodo. Por ejemplo:

    kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: node-secrets-access
  namespace: default
subjects:
- kind: User
  name: system:node:gke-XXX--YYY
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: system:node
  apiGroup: rbac.authorization.k8s.io

    Este RoleBinding permite al usuario system:node:gke-XXX--YYY acceder a los secretos en el espacio de nombres default.

    Es importante tener en cuenta que acceder a los secretos directamente desde un nodo de trabajo puede no ser la mejor práctica de seguridad. Se recomienda utilizar métodos nativos de Kubernetes, como montar secretos como Secrets de Kubernetes o utilizar Vault como un almacén seguro de secretos.

Comments are closed.