Налаштування користувача для kubectl (kuberc)

Файл конфігурації Kubernetes kuberc дозволяє вам визначити параметри для kubectl, такі як стандартні параметри та аліаси команд. На відміну від файлу kubeconfig, файл конфігурації kuberc не містить відомостей про кластер, імен користувачів або паролів.

В Linux/POSIX системах стандартне розташування цього файлу конфігурації — $HOME/.kube/kuberc. У Windows стадартний шлях подібний до %USERPROFILE%\.kube\kuberc. Ви можете вказати kubectl, щоб він шукав конфігурацію в іншому шляху, використовуючи аргумент командного рядка --kuberc. Ви також можете встановити змінну середовища KUBERC.

Файл kuberc, що використовує формат kubectl.config.k8s.io/v1beta1, дозволяє вам визначити наступні типи налаштувань користувача:

1. Aliases — дозволяють створювати коротші версії ваших улюблених команд, за бажанням встановлюючи параметри та аргументи.
2. Defaults — дозволяють налаштовувати стандартні значення параметрів для ваших улюблених команд.
3. Політика втулків для облікових даних — дозволяє налаштувати політику для втулків облікових даних exec.

aliases

У конфігурації kuberc секція aliases дозволяє вам визначити власні скорочення для команд kubectl, за бажанням з попередньо встановленими аргументами та прапорцями командного рядка.

Наступний приклад визначає аліас kubectl getn для команди kubectl get, додатково вказуючи формат виводу JSON: --output=json.

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
aliases:
- name: getn
  command: get
  options:
   - name: output
     default: json

В цьому прикладі були використані такі налаштування:

1. name — Імʼя аліасу не повинно збігатися з вбудованими командами.
2. command — Вкажіть вбудовану команду, яку буде виконувати ваш аліас. Це включає підтримку підкоманд, таких як create role.
3. options — Вкажіть стандартне значення для параметрів. Якщо ви явно вкажете параметр під час виконання kubectl, значення, яке ви надасте, матиме пріоритет над стандартним значенням , визначеним у kuberc.

З цим аліасом виконання kubectl getn pods стандартно виведе JSON. Однак, якщо ви виконаєте kubectl getn pods -oyaml, вивід буде у форматі YAML.

Повний опис схеми kuberc доступний тут.

prependArgs

Цей приклад розширює попередній, вводячи секцію prependArgs, яка дозволяє вставляти довільні аргументи безпосередньо після команди kubectl та її підкоманди (якщо така є).

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
aliases:
  - name: getn
    command: get
    options:
      - name: output
        default: json
    prependArgs:
      - namespace

В цьому прикладі були використані такі налаштування:

1. name — Імʼя аліасу не повинно збігатися з вбудованими командами.
2. command — Вкажіть вбудовану команду, яку буде виконувати ваш аліас. Це включає підтримку підкоманд, таких як create role.
3. options — Вкажіть стандартне значення для параметрів. Якщо ви явно вкажете параметр під час виконання kubectl, значення, яке ви надасте, матиме пріоритет над стандартним значенням, визначеним у kuberc.
4. prependArgs — Вкажіть явний аргумент, який буде розміщено відразу після команди. Тут це буде перетворено на kubectl get namespace test-ns --output json.

appendArgs

Цей приклад представляє механізм, подібний до додавання аргументів, але в цей раз ми будемо додавати аргументи в кінець команди kubectl.

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
aliases:
- name: runx
  command: run
  options:
    - name: image
      default: busybox
    - name: namespace
      default: test-ns
  appendArgs:
    - --
    - custom-arg

В цьому прикладі були використані такі налаштування:

1. name — Імʼя аліасу не повинно збігатися з вбудованими командами.
2. command — Вкажіть вбудовану команду, яку буде виконувати ваш аліас. Це включає підтримку підкоманд, таких як create role.
3. options — Вкажіть стандартне значення для параметрів. Якщо ви явно вкажете параметр під час виконання kubectl, значення, яке ви надасте, матиме пріоритет над стандартним значенням, визначеним у kuberc.
4. appendArgs — Вкажіть явні аргументи, які будуть розміщені в кінці команди. Тут це буде перетворено на kubectl run test-pod --namespace test-ns --image busybox -- custom-arg.

defaults

У рамках конфігурації kuberc секція defaults дозволяє вказати стандартні значення для аргументів командного рядка.

Цей приклад робить інтерактивне видалення стандартним режимом для виклику kubectl delete:

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
defaults:
- command: delete
  options:
    - name: interactive
      default: "true"

В цьому прикладі були використані такі налаштування:

1. command — Вбудована команда, це включає підтримку підкоманд, таких як create role.
2. options — Вкажіть стандартні значення для параметрів. Якщо ви явно вкажете параметр під час виконання kubectl, значення, яке ви надасте, матиме пріоритет над стандартним значенням, визначеним у kuberc.

З цим налаштуванням, виконання kubectl delete pod/test-pod стандартно запитуватиме підтвердження. Однак, kubectl delete pod/test-pod --interactive=false обійде підтвердження.

Політика втулків для облікових даних

Редактори kubeconfig можуть вказати виконуваний втулок, який буде використовуватися для отримання облікових даних для автентифікації клієнта в кластері. У конфігурації kuberc ви можете встановити політику виконання для таких втулків за допомогою двох полів верхнього рівня. Обидва поля є необовʼязковими.

credentialPluginPolicy

Ви можете налаштувати політику для втулків облікових даних, використовуючи опціональне поле credentialPluginPolicy. Для цього поля існує три допустимі значення:

1. "AllowAll"

Коли політика встановлена на "AllowAll", не буде жодних обмежень щодо того, які втулки можуть працювати. Ця поведінка ідентична поведінці версій Kubernetes до 1.35.

2. "DenyAll"

Коли політика встановлена на "DenyAll", жодні втулки exec не будуть дозволені до запуску.

3. "Allowlist"

Коли політика встановлена на "Allowlist", користувач може вибірково дозволяти виконання втулків для введення облікових даних. Коли політика встановлена на "Allowlist", ви повинні також вказати поле credentialPluginAllowlist (також на верхньому рівні). Це поле описано нижче.

credentialPluginAllowlist

Поле credentialPluginAllowlist визначає список наборів критеріїв (наборів вимог) для дозволу на виконання втулків облікових даних. Кожен набір вимог буде перевірятися по черзі; як тільки втулок відповідатиме всім вимогам хоча б одного набору, йому буде дозволено виконуватися. Тобто загальний результат застосування списку дозволених втулків до втулка my-binary-plugin є логічним АБО рішеннями, прийнятими для кожного елемента в списку.

Як приклад, розглянемо таку конфігурацію списку дозволених втулків:

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: Allowlist
credentialPluginAllowlist:
  - name: foo
  - name: bar
  - name: baz

У наведеному вище прикладі список дозволених втулків дозволить втулки з іменами "foo", "bar" АБО "baz".

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: Allowlist
credentialPluginAllowlist:
  - name: ""

name

name визначає імʼя втулка для перевірки повноважень, який може бути виконаний. Воно може бути вказане як базова назва бажаного втулка або повний шлях. Якщо вказано як базова назва, рішення, прийняте цим полем, буде "allow", якщо виконується одна з двох наступних умов:

1. Поле name точно дорівнює полю command втулка.
2. Виконано повне розпізнавання шляху як для name, так і для command, і результати збігаються.

Якщо вказано повний шлях, рішення, прийняте цим полем, є "allow", якщо виконується одна з наступних умов:

1. Поле name точно дорівнює полю command втулка (тобто command також є повним шляхом).
2. Виконано повне розпізнавання шляху для поля command, і поле name точно збігається.

Що стосується визначення повного шляху, згаданого раніше на цій сторінці, ні символічні посилання, ні глобальні шаблони пошуку оболонки не визначаються.

Наприклад, розглянемо запис у списку дозволених з name /usr/local/bin/my-binary, де /usr/local/bin/my-binary є символічним посиланням на /this/is/a/target. Якщо command, вказаний у kubeconfig, є /this/is/a/target, він не буде дозволений. Щоб це працювало, потрібно явно додати /this/is/a/target до списку дозволених. З іншого боку, якщо kubeconfig має command як /usr/local/bin/my-binary, то список дозволених дозволить його запуск.

Приклад

Наступний приклад показує політику "Allowlist" з її списком дозволених елементів:

• POSIX
• Windows

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: Allowlist
credentialPluginAllowlist:
  - name: my-trusted-binary
  - name: /usr/local/bin/my-other-trusted-binary

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: Allowlist
credentialPluginAllowlist:
  - name: my-trusted-binary
  - name: "C:\my-other-trusted-binary"

Запропоновані defaults

Розробники kubectl рекомендують використовувати kuberc із такими стандартними defaults:

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
defaults:
  # (1) стандартно server-side apply
  - command: apply
    options:
      - name: server-side
        default: "true"

  # (2) стандартно інтерактивне видалення
  - command: delete
    options:
      - name: interactive
        default: "true"

# Перед вибором DenyAll ознайомтеся з наведеною вище приміткою про провайдерів керованих інстансів
credentialPluginPolicy: DenyAll

В цьому прикладі були використані такі налаштування:

1. Стандартно використовується Server-Side Apply.
2. Стандартно інтерактивне видалення щоразу, коли викликається kubectl delete, щоб запобігти випадковому видаленню ресурсів з кластера.
3. Запуск виконуваних втулків для облікових даних буде заборонено.

Вимкнення kuberc

Щоб тимчасово вимкнути функціональність kuberc, встановіть змінну середовища KUBERC зі значенням off:

export KUBERC=off

або вимкніть функціональну можливість:

export KUBECTL_KUBERC=false

Це може бути корисно для усунення несправностей, якщо ваш kuberc спричиняє проблеми.