# Налаштування користувача для kubectl (kuberc)
LLMS index: [llms.txt](/llms.txt)
---
СТАН ФУНКЦІОНАЛУ:
Kubernetes 1.34 [beta]
Файл конфігурації 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](#aliases) — дозволяють створювати коротші версії ваших улюблених команд, за бажанням встановлюючи параметри та аргументи.
2. [Defaults](#defaults) — дозволяють налаштовувати стандартні значення параметрів для ваших улюблених команд.
3. [Політика втулків для облікових даних](#credential-plugin-policy) — дозволяє налаштувати політику для втулків облікових даних exec.
## aliases
У конфігурації `kuberc` секція _aliases_ дозволяє вам визначити власні скорочення для команд kubectl, за бажанням з попередньо встановленими аргументами та прапорцями командного рядка.
Наступний приклад визначає аліас `kubectl getn` для команди `kubectl get`, додатково вказуючи формат виводу JSON: `--output=json`.
```yaml
apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
aliases:
- name: getn
command: get
options:
- name: output
default: json
```
В цьому прикладі були використані такі налаштування:
1. `name` — Імʼя аліасу не повинно збігатися з вбудованими командами.
1. `command` — Вкажіть вбудовану команду, яку буде виконувати ваш аліас. Це включає підтримку підкоманд, таких як `create role`.
1. `options` — Вкажіть стандартне значення для параметрів. Якщо ви явно вкажете параметр під час виконання `kubectl`, значення, яке ви надасте, матиме пріоритет над стандартним значенням , визначеним у `kuberc`.
З цим аліасом виконання `kubectl getn pods` стандартно виведе JSON. Однак, якщо ви виконаєте `kubectl getn pods -oyaml`, вивід буде у форматі YAML.
Повний опис схеми `kuberc` доступний [тут](/docs/reference/config-api/kuberc.v1beta1/).
### prependArgs
Цей приклад розширює попередній, вводячи секцію `prependArgs`, яка дозволяє вставляти довільні аргументи безпосередньо після команди kubectl та її підкоманди (якщо така є).
```yaml
apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
aliases:
- name: getn
command: get
options:
- name: output
default: json
prependArgs:
- namespace
```
В цьому прикладі були використані такі налаштування:
1. `name` — Імʼя аліасу не повинно збігатися з вбудованими командами.
1. `command` — Вкажіть вбудовану команду, яку буде виконувати ваш аліас. Це включає підтримку підкоманд, таких як `create role`.
1. `options` — Вкажіть стандартне значення для параметрів. Якщо ви явно вкажете параметр під час виконання `kubectl`, значення, яке ви надасте, матиме пріоритет над стандартним значенням, визначеним у `kuberc`.
1. `prependArgs` — Вкажіть явний аргумент, який буде розміщено відразу після команди. Тут це буде перетворено на `kubectl get namespace test-ns --output json`.
### appendArgs
Цей приклад представляє механізм, подібний до додавання аргументів, але в цей раз ми будемо додавати аргументи в кінець команди kubectl.
```yaml
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` — Імʼя аліасу не повинно збігатися з вбудованими командами.
1. `command` — Вкажіть вбудовану команду, яку буде виконувати ваш аліас. Це включає підтримку підкоманд, таких як `create role`.
1. `options` — Вкажіть стандартне значення для параметрів. Якщо ви явно вкажете параметр під час виконання `kubectl`, значення, яке ви надасте, матиме пріоритет над стандартним значенням, визначеним у `kuberc`.
1. `appendArgs` — Вкажіть явні аргументи, які будуть розміщені в кінці команди. Тут це буде перетворено на `kubectl run test-pod --namespace test-ns --image busybox -- custom-arg`.
## defaults
У рамках конфігурації `kuberc` секція `defaults` дозволяє вказати стандартні значення для аргументів командного рядка.
Цей приклад робить інтерактивне видалення стандартним режимом для виклику `kubectl delete`:
```yaml
apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
defaults:
- command: delete
options:
- name: interactive
default: "true"
```
В цьому прикладі були використані такі налаштування:
1. `command` — Вбудована команда, це включає підтримку підкоманд, таких як `create role`.
1. `options` — Вкажіть стандартні значення для параметрів. Якщо ви явно вкажете параметр під час виконання `kubectl`, значення, яке ви надасте, матиме пріоритет над стандартним значенням, визначеним у `kuberc`.
З цим налаштуванням, виконання `kubectl delete pod/test-pod` стандартно запитуватиме підтвердження. Однак, `kubectl delete pod/test-pod --interactive=false` обійде підтвердження.
## Політика втулків для облікових даних {#credential-plugin-policy}
СТАН ФУНКЦІОНАЛУ:
Kubernetes v1.35 [beta]
Редактори `kubeconfig` можуть вказати виконуваний втулок, який буде використовуватися для отримання облікових даних для автентифікації клієнта в кластері. У конфігурації `kuberc` ви можете встановити політику виконання для таких втулків за допомогою двох полів верхнього рівня. Обидва поля є необовʼязковими.
### credentialPluginPolicy
Ви можете налаштувати політику для втулків облікових даних, використовуючи опціональне поле `credentialPluginPolicy`. Для цього поля існує три допустимі значення:
1. `"AllowAll"`
Коли політика встановлена на `"AllowAll"`, не буде жодних обмежень щодо того, які втулки можуть працювати. Ця поведінка ідентична поведінці версій Kubernetes до 1.35.
2. `"DenyAll"`
Коли політика встановлена на `"DenyAll"`, жодні втулки exec не будуть дозволені до запуску.
3. `"Allowlist"`
Коли політика встановлена на `"Allowlist"`, користувач може вибірково дозволяти виконання втулків для введення облікових даних. Коли політика встановлена на `"Allowlist"`, ви **повинні** також вказати поле `credentialPluginAllowlist` (також на верхньому рівні). Це поле описано нижче.
Примітка:
Для збереження зворотної сумісності невизначена або порожня credentialPluginPolicy ідентична явному встановленню політики на "AllowAll".
### credentialPluginAllowlist
Примітка:
Встановлення цього поля, коли credentialPluginPolicy не є Allowlist (включно з випадками, коли це поле відсутнє або порожнє), вважається помилкою конфігурації.
Поле `credentialPluginAllowlist` визначає список наборів критеріїв (наборів *вимог*) для дозволу на виконання втулків облікових даних. Кожен набір вимог буде перевірятися по черзі; як тільки втулок відповідатиме всім вимогам хоча б одного набору, йому буде дозволено виконуватися. Тобто загальний результат застосування allowlist до втулка `my-binary-plugin` є _логічним АБО_ рішеннями, прийнятими для кожного елемента в списку.
Як приклад, розглянемо таку конфігурацію списку дозволених втулків:
```yaml
apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: Allowlist
credentialPluginAllowlist:
- command: foo
- command: bar
- command: baz
```
В наведеному вище прикладі allowlist дозволить втулки з командами "foo", "bar", _АБО_ "baz".
Примітка:
Щоб набір вимог був дійсним, він повинен мати принаймні одне поле, яке не є порожнім і явно вказане. Якщо всі поля порожні або не вказані, це вважається помилкою конфігурації, і втулок не буде дозволений до виконання. Те саме стосується поля credentialPluginAllowlist, якщо воно не вказане або явно вказане як порожній список. Це зроблено для того, щоб запобігти ситуаціям, коли користувач неправильно вводить ключ credentialPluginAllowlist, думаючи, що вказав список дозволених, хоча насправді цього не зробив.
Наприклад, наступне є недійсним:
apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: Allowlist
credentialPluginAllowlist:
- command: ""
Примітка:
Поки kuberc знаходиться у бета-версії, name може використовуватися як псевдонім для command у записах allowlist. Починаючи з Kubernetes 1.36, name застаріває на користь command. Надання обох name та command в одному записі allowlist вважається помилкою, оскільки це налаштування є критично важливим для безпеки. Поле name буде повністю видалено, коли kuberc досягне GA.
### Приклад {#credential-plugin-policy-example}
Наступний приклад показує політику `"Allowlist"` з її списком дозволених елементів:
apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: Allowlist
credentialPluginAllowlist:
- command: my-trusted-binary
- command: /usr/local/bin/my-other-trusted-binary
apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: Allowlist
credentialPluginAllowlist:
- command: my-trusted-binary
- command: "C:\\my-other-trusted-binary"
Увага:
Якщо ви використовуєте провайдера керованого Kubernetes, перевірте документацію провайдера щодо того, які втулки exec потрібні у вашому середовищі, і замість цього використовуйте політику "Allowlist".
Якщо після встановлення політики "DenyAll", як показано нижче, виникнуть проблеми, перегляньте повідомлення про помилки kubectl, щоб зʼясувати, які втулки не вдалося запустити, і порівняйте їх з документацією вашого провайдера. Нарешті, змініть політику на "Allowlist" і додайте необхідні втулки в поле credentialPluginAllowlist.