Всем доброго утра! Какой самый нативный способ для приложения на golang

в кубере узнать свой Namespace в котором он установлен?
Нашёл вот закрытый issue
https://github.com/kubernetes/client-go/issues/804

Получается реально только читать из файла /var/run/secrets/kubernetes.io/serviceaccount/namespace или пробрасывать в ENV, как предложено в коментарии
https://github.com/kubernetes/client-go/issues/804#issuecomment-1298410210

неужели с дефолтным serviceAccount-ом нельзя через клиента вычитать?

А передать в под переменной не вариант? Это выглядит намного проще.

сделайте не дефолтный

Вот так и решил делать, просто казалось раз есть serviceAccount и уже клиент внутри, то казалось из него можно это стрясти, оказалось что нет и проще переменную добавить в спеке и os.Getenv вычитать

да, уже не дефолтный, всё равно телодвижений больше выходит...

а чем кат файла не мил? или приложенька запускается с automountServiceAccountToken: false?

Самое простое это metadata.namespace как env. В противном случае сервисакаунту нужны права на чтение нс из апишки

Мне не нравится такой вариант

исчерпывающее объяснение

env: - name: NAMESPACE valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.namespace

> неужели с дефолтным serviceAccount-ом нельзя через клиента вычитать? можно , прочитать файл /var/run/secrets/kubernetes.io/serviceaccount/namespace

Чтение из файла потенуиальная дыра, более безопасно читать в рантайме

А в чём дыра? Чем опасно, кто может воспользоваться?

Смотри 0дей никто не отменяет, плюс файл в принципе можно подменить. Вектор атаки может быть разным и в локальной обработки никто не гарантирует что нельзя будет выполнить выполнение кода после чтения файла. В контексте чтения файлов нужно настраивать fim

да это очередные загоны безопасников. В определенную фазу луны, когда рандомный генератор чисел выдаст 42, станет возможно в не экспортируемую функцию передать аргумент определенного вида, и тогда, если у тебя есть полный ко всему, ты сможешь подменить файл

Ну я не спорю, что в теории можно подменить файл и под подумает, что он в другом неймспейсе. Ну ок. Подумает :)

Я так и сделал, только зачем тут apiVersion: v1?

убери, не страшно

Хотел разобраться, может оно важно в каких-то случаях

Все что стейтфул потенциальная дыра либо слабость для неавторизованного доступа

это поле несет точно такой-же смысл, как и в других ресурсах куба. У ресурса есть apiVersion, от него зависит схема. Конкретно в этом кейсе apiversion не влияет особо, потому что имя всегда в метадате

монтируемые файлы из секретов и configmap'ов это не стейтфул

Еще раз перечитай что я говорил.

не важно что ты говорил, тред о /var/run/secrets/kubernetes.io/serviceaccount И чтения файлов от туда

А вот теперь представь что есть уязвимость которая мне позволит подмонтировать какой то файл как сервис акаунт либо я просто хотел испортить жизнь кому то. Я про это и писал. Чтение/запись файлов и работа с ними потенциально опасно.

Тебе что то не понятно?

да это очередные если бы да кабы. Конкретную уязвимость в пример надо давать, и способы ее применения. Подмонтировать? Этим занимается kubelet, насколько мне известно. Ну давай рассмотрим этот вектор атаки, ты каким-то образом ломанул kubelet, чтобы он монтировал левые сервис аккаунты, чтобы что? Чтобы код считал левый аккаунт, и не смог авторизоваться в kube-apiserver? А че бы тогда не монтировать левые entrypoint'ы?

Я опять же говорил про потенциальные риски. Кто говорит про кублет)? Например есть 0дей который злоумышленику позволяет подменить твой сервис акаунт на какой либо левый файл. Это можно искобчать?

> Например есть 0дей который злоумышленику позволяет подменить твой сервис акаунт на какой либо левый файл В чем этот 0day, монтированием файликов в под вроде kubelet занимается. Можно еще containerd/cri-o ломануть, но опять встает вопрос, нафига тогда подменять service аккаунты

Ты достоверно не знаешь кто смонтировал и изменен ли файл. Так как нет достоверных данных о состоянии. На основе таких сигнатур работает фим. В таком случае ты достоверно знаешь изменился ли файл или нет и что поменялось

резюмируя, читать можно, таких потенциальных дыр можно найти очень много, я бы не парился по этому поводу. Закрывают их судя по всему по субъективному принципу, по каким-то предпринимают меры, по каким-то нет или делают вид что предпринимают, потому что это комплексное решение.

кстати, если я правильно помню, там этот "волюм" - смонтирован с RO

да, но там 0day уязвимость, которая подменяет же, то есть монтирует другое