Так-с, начнём с базы.
У нас есть rsa приватный ключик, и запрос на подписание csr (в csr в поле CN мы пишем имя пользователя).

Далее у нас 2 выбора, подписать с использованием openssl или же с помощью api кубера;

Как это сделать руками:
1)

openssl genrsa -out /root/60099.key 2048

2)

openssl req -new -key /root/60099.key -out /root/60099.csr
MUST SET username IN CN: [email protected] !!!!

3)

openssl x509 -req -in /root/60099.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out /root/60099.crt -days 500

4) Собираем наш профиль, не csr не нужно будет апрувить, мы их руками подписали:

k config set-credentials [email protected] --client-key=60099.key --client-certificate=60099.crt
k config set-context [email protected] --cluster=kubernetes [email protected]
k config get-contexts
k config use-context [email protected]

Вариант с api:
Шаги 1 и 2 повторяются из предыдущего шага;
3) Дальше нам необходимо создать запрос на подпись:

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: {{CN_from_csr}} # ADD
spec:
  groups:
  - system:authenticated
  request: {{BASE_64_ENCODED_CSR}} # ADD
  signerName: kubernetes.io/kube-apiserver-client
  usages:
  - client auth

4) Теперь надо его подписать (kubectl certificate approve {{CN_from_csr}});
5) Далее в объекте csr у нас появится сертификат который можно использовать для взаимодействия с кубером (сборка конфиг файла kubeconfig как в предыдущем способе);

Теперь про сладенькое.

Крч "группы" пользака можно подтянуть через OU расширения в сертификаты:

openssl req -new -newkey rsa:2048 -nodes -keyout /root/60099.key -out /root/60099.csr -subj "/CN=hacker-user/OU=system:masters/OU=system:authenticated"

or:

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: {{CN_from_csr}} # ADD
spec:
  groups:
  - system:masters # this
  - system:authenticated
  request: {{BASE_64_ENCODED_CSR}} # ADD
  signerName: kubernetes.io/kube-apiserver-client
  usages:
  - client auth

И всё, не отзываем, чтобы грохнуть надо будет перевыпускать корневой сертификат.

😂 Пока писал подумал, а почему мы выписываем сертификат именно у

kubernetes.io/kube-apiserver-client

Да , он автоматом не подписывает csr, однако у нас есть;

kubernetes.io/kube-apiserver-client-kubelet 

Он может таки и авто апрувнуть сертификатик, но надо будет представиться узлом. Если кто хочет протыкать или если кто-то так делал пожалуйста отпишитесь ;)

В свете последних событий с хомяком :)

Тут какой-то залетный задал вопрос https://t.iss.one/ScriptKiddieNotesChat/3460

Вообще, вопрос интересный. И я начал вспоминать, что же я знаю про "secondary context path traversal".

Как я всегда это понимал - это когда ты не напрямую проводишь атаку типа path traversal на веб-приложение, а когда при этом имеет место быть прокладка в виде прокси/шлюза. И чтобы визуально добиться и достать результат надо попотеть, ибо не так просто подобрать правильный path routing.

Натыкался на нечто подобное, когда в качестве прокси выступал nginx. Но чет не осилил.

Тема не то, чтобы новая, но вполне имеет место быть. Просто автоматикой не детектится, лол)

Материалы по теме:

https://github.com/GrrrDog/weird_proxies

https://speakerdeck.com/greendog/reverse-proxies-and-inconsistency

https://docs.google.com/presentation/d/1N9Ygrpg0Z-1GFDhLMiG3jJV6B_yGqBk8tuRWO1ZicV8

#bb

Так вот, оно что, Максим….

Интересно, примут ли?)

классика