Можно ли запускать команды oc в терминалах openshift pod?
Можно ли как-нибудь запустить команды oc на терминалах pod? Что я пытаюсь сделать, это позволить пользователю войти в систему с помощью
oc login
Затем выполните команду, чтобы получить токен.
oc whoami -t
А затем используйте этот токен для вызова REST API openshift. Этот способ работает в локальной среде, но в openshift есть некоторые проблемы с разрешениями, так как я предполагаю, что openshift не дает пользователю root-права. он говорит, что разрешение отказано.
РЕДАКТИРОВАТЬ
Поэтому я хочу получить токен BEARER, который я могу отправить в заголовки API REST для создания модулей, служб, маршрутов и т. Д. И я хочу, чтобы этот токен был создан до того, как будет создан любой модуль, потому что я собираюсь использовать этот токен для создавать стручки. Я знаю, это может показаться глупым, но это то, что я хочу знать, если это возможно, то, как мы делаем это с помощью командной строки с помощью команд oc, возможно ли это в openshift.
Другой возможный способ - вызвать API, который дает мне токен, а затем использовать этот токен в других вызовах API.
@gshipley Для меня это похоже на проблему с куриным яйцом. Но если бы я объяснил вам, что я делаю на своей локальной машине, все, что я хотел бы, это повторить это на openshift, если это возможно. Я запускаю команды oc на nodejs, в моем репозитории есть файл oc.exe. Я запускаю oc login и oc whoami -t. Я читаю полученный токен и сохраняю его. Затем я отправляю этот токен как BEARER в заголовках API. Вот что работает на моей локальной машине. Я просто хочу повторить этот сценарий на openshift. Является ли это возможным?
1 ответ
В качестве администратора кластера создайте новый Role как, например, role.yml
apiVersion: authorization.openshift.io/v1
kind: ClusterRole
metadata:
name: mysudoer
rules:
apiGroups: [''],
resources: ['users']
verbs: ['impersonate']
resourceNames: ["<your user name>"]
и беги
oc create -f role.yml
или вместо создания сырых role.yml файл, используйте:
oc create clusterrole mysudoer --verb impersonate --resource users --resource-name "<your user name>"
затем дайте вашему ServiceAccount новую роль
oc adm policy add-cluster-role-to-user mysudoer system:serviceaccount:<project>:default
скачать oc инструмент в ваш контейнер. Теперь, когда вы выполняете команду, вам нужно добавить --as=<user name>или, чтобы скрыть это, создайте псевдоним оболочки внутри вашего контейнера
alias oc="oc --as=<user name>"
oc теперь должен вести себя точно так же, как на вашем компьютере, включая те же привилегии, что и ServiceAccount только функционирует как точка входа в API, но реальные задачи выполняются как пользователь.
Если вы хотите что-то более простое, просто добавьте соответствующие разрешения для вашего ServiceAccountнапример,
oc policy add-role-to-user admin -z default --namespace=<your project>
если вы запустите команду, любой контейнер в вашем проекте, который имеет oc сможет автоматически выполнять задачи внутри проекта. Тем не менее, таким образом, разрешения не наследуются от пользователя, как на первом шаге, поэтому всегда необходимо вручную добавлять их в учетную запись службы.
Объяснение, всегда есть ServiceAccount в вашем проекте под названием default, Он не имеет никаких привилегий, поэтому ничего не может сделать, однако все необходимые учетные данные для аутентификации ServiceAccount по умолчанию в каждом контейнере. Классная вещь в том, что oc, если вы не предоставите никаких учетных данных, а просто запустите его внутри контейнера в OpenShift, он автоматически попытается войти в систему, используя эту учетную запись. Приведенные выше шаги просто показывают, как получить надлежащие разрешения для учетной записи, чтобы oc может использовать это, чтобы сделать что-то значимое.
Если вы просто хотите получить доступ к RESt API, используйте токен, предоставленный в
/var/run/secrets/kubernetes.io/serviceaccount/token
и настроить разрешения для ServiceAccount как описано выше. При этом вам даже не понадобится oc инструмент командной строки.