Kerberos и SSL для Impala в Kubernetes

Сергей Тихомиров, Константин Алпашкин

В данной статье описан процесс подключения Kerberos-аутентификации и SSL-шифрования для кластера Impala, развернутом в Kubernetes.

Описанный в статье сценарий настройки предполагает наличие чистого незащищенного кластера Impala в Kubernetes, развернутого в соответствии с инструкциями из статьи Установка Impala в Kubernetes.

Требования

Процедура настройки

Шаг 1. Установка оператора Kerberos

Установите оператор Kerberos и Kerberos config с помощью Helm, как описано в статье Установка оператора Kerberos в Kubernetes. Ниже приведены примеры Helm values-файлов для установки оператора Kerberos и Kerberos config.

ko-values.yaml
replicas: 1
image:
  registry: hub.arenadata.io (1)
  repository: adc-enterprise/kerberos-operator (2)
  pullPolicy: IfNotPresent
  tag: <tag> (3)

serviceAccount:
  create: true
  automount: true

service:
  type: ClusterIP
  port: 8443

payloadNamespaces:
  names: (4)
    - kerberos-prod
    - kerberos-staging
  allowClusterRole: false (5)
  deleteProtection: true (6)
  avoidCreation: false (7)


terminationGracePeriodSeconds: 10
1 URL хранилища образов.
2 Путь к репозиторию образа Kerberos-оператора в хранилище.
3 Версия образа, которая будет использована Kubernetes.
4 Список пространств имен, доступных для Kerberos-оператора.
5 Явное согласие на предоставление доступа ко всему кластеру. Когда значение параметра true, а payloadNamespaces.names пусто, чарт создает ClusterRole/ClusterRoleBinding для доступа ко всем пространствам имен.
6 Флаг, определяющий добавлять ли аннотацию helm.sh/resource-policy: keep к пространству имен, предотвращающую удаление командой helm uninstall.
7 Флаг, определяющий пропускать ли шаг создания пространства имен. Следует использовать только если заранее известно о наличии пространства имен (например, созданного оператором Kerberos).
kc-values.yaml
ldapSecret:
  enabled: true
  provider: freeipa (1)
  address: 	ldap://tsn-freeipa.ru-central1.internal (2)
  adminUser: uid=admin,cn=users,cn=accounts,dc=ru-central1,dc=internal (3)
  adminPassword: bigdata (4)
  baseDN: cn=services,cn=accounts,dc=ru-central1,dc=internal (5)
  ca: | <pem-certificate> (6)

kdcConfig:
  labelSelector:
    env: prod
  libdefaults:
    debug: 'false'
    default_realm: RU-CENTRAL1.INTERNAL
    dns_lookup_kdc: 'false'
    dns_lookup_realm: 'false'
    udp_preference_limit: '1'
  realm: RU-CENTRAL1.INTERNAL (7)
  domainRealm:
    ru-central1.internal: RU-CENTRAL1.INTERNAL
  realms:
    RU-CENTRAL1.INTERNAL: |
      kdc = tsn-freeipa.ru-central1.internal (8)
      admin_server = tsn-freeipa.ru-central1.internal (9)
1 Тип провайдера Kerberos. Может быть одним из следующих значений: ad, samba, freeipa.
2 URL для подключения к LDAP.
3 Имя пользователя с правами администратора.
4 Пароль администратора.
5 База поиска.
6 CA-сертификат для доверия с TLS-сертификатом сервера LDAP.
7 Kerberos-реалм (realm).
8 Хост с доступным KDC.
9 Хост с доступным kadmin.

Команды для установки Helm-чартов:

$ helm upgrade --install kerberos-operator oci://"$PRIVATE_REGISTRY"/adc-enterprise/charts/kerberos-operator --version <chart_version> -f ko-values.yaml --namespace kerberos-operator --create-namespace
$ helm upgrade --install kerberos-config oci://"$PRIVATE_REGISTRY"/adc-enterprise/charts/kerberos-config --version <chart_version> -f kc-values.yaml --namespace kerberos-operator --create-namespace

Для проверки установки используйте команды:

$ kubectl get secrets -n kerberos-operator
$ kubectl get configmaps -n kerberos-operator

Пример вывода:

kubectl get secrets -n kerberos-operator
NAME                                      TYPE                                 DATA   AGE
kerberos-config-ldap-credentials          krb5.arenadata.io/ldap-credentials   5      7s
sh.helm.release.v1.kerberos-config.v1     helm.sh/release.v1                   1      7s
sh.helm.release.v1.kerberos-operator.v1   helm.sh/release.v1                   1      48m
kubectl get configmaps -n kerberos-operator
NAME               DATA   AGE
kube-root-ca.crt   1      50m

Шаг 2. Создание keytab-ресурса и принципалов

  1. Создайте манифест-файл impala_keytab.yaml с принципалами Impala. Например:

    apiVersion: krb5.arenadata.io/v1alpha1
kind: Keytab
metadata:
  name: impala-keytab
  namespace: impala
spec:
  items:
    - realm: RU-CENTRAL1.INTERNAL (1)
      labelSelector:
        env: prod
      principals: (2)
        - HTTP/impala-cloud.ru-central1.internal
        - impala/impala-cloud.ru-central1.internal
        - impala/impala-jdbc.ru-central1.internal
  rotation:
    interval: 720h
    checkInterval: 1h
    1 Kerberos реалм (realm).
    2 Kerberos-принципалы для доступа к керберизированным сервисам ADH.

  2. Примените конфигурацию:

    $ kubectl apply -f impala_keytab.yaml

  3. Проверьте создание keytab-ресурса с помощью команд:

    $ kubectl get keytab -n impala
$ kubectl get secret impala-keytab -n impala

    Пример вывода:

    NAME            ROTATION            READY             AGE    NEXTROTATION
impala-keytab   RotationScheduled   SecretGenerated   2d1h   Next rotation required 2026-05-22T14:13:11Z
    NAME            TYPE                       DATA   AGE
impala-keytab   krb5.arenadata.io/bundle   2      2d1h

Шаг 3. Обновление секретов Kubernetes

Развернутый ранее кластер Impala использует секрет Kubernetes c конфигурационными файлами ADH для взаимодействия с незащищенными ADH-сервисами. Для включения Kerberos/SSL и обеспечения взаимодействия Impala с сервисами ADH, защищенными SSL, необходимо изменить конфигурационные файлы ADH и пересоздать секреты Kubernetes.

  1. Измените конфигурационные файлы core-site.xml, hdfs-site.xml и hive-site.xml. Обновленные файлы должны содержать следующие свойства:

    core-site.xml
    <?xml version="1.0"?>
<configuration>
        <property>
                <name>fs.defaultFS</name>
                <value>hdfs://adh</value>
        </property>
        <property>
                <name>dfs.nameservices</name>
                <value>adh</value>
        </property>
        <property>
                <name>hadoop.security.authentication</name>
                <value>kerberos</value>
        </property>
        <property>
                <name>dfs.ha.namenodes.adh</name>
                <value>nn_ka-adh-1,nn_ka-adh-2</value>
        </property>
        <property>
                <name>dfs.namenode.rpc-address.adh.nn_ka-adh-1</name>
                <value>ka-adh-1.ru-central1.internal:8020</value>
        </property>
        <property>
                <name>dfs.namenode.rpc-address.adh.nn_ka-adh-2</name>
                <value>ka-adh-2.ru-central1.internal:8020</value>
        </property>
        <property>
                <name>dfs.namenode.kerberos.principal</name>
                <value>nn/_HOST@REALM</value>
        </property>
</configuration>
    hdfs-site.xml
    <?xml version="1.0"?>
<configuration>
        <property>
                <name>dfs.nameservices</name>
                <value>adh</value>
        </property>
        <property>
                <name>dfs.ha.namenodes.adh</name>
                <value>nn_ka-adh-1,nn_ka-adh-2</value>
        </property>
        <property>
                <name>dfs.namenode.rpc-address.adh.nn_ka-adh-1</name>
                <value>ka-adh-1.ru-central1.internal:8020</value>
        </property>
        <property>
                <name>dfs.namenode.rpc-address.adh.nn_ka-adh-2</name>
                <value>ka-adh-2.ru-central1.internal:8020</value>
        </property>
        <property>
                <name>dfs.client.failover.proxy.provider.adh</name>
               <value>org.apache.hadoop.hdfs.server.namenode.ha.ObserverReadProxyProvider</value>
        </property>
</configuration>
    hive-site.xml
    <?xml version="1.0"?>
<configuration>
    <property>
        <name>hive.metastore.uris</name>
        <value>thrift://ka-adh-2.ru-central1.internal:9083</value>
    </property>
    <property>
        <name>metastore.use.SSL</name>
        <value>True</value>
    </property>
    <property>
		<name>metastore.truststore.password</name>
		<value>bigdata</value>
	</property>
	<property>
		<name>metastore.truststore.path</name>
		<value>/etc/ssl/truststore.jks</value>
	</property>
	<property>
		<name>hive.metastore.sasl.enabled</name>
		<value>True</value>
	</property>
	<property>
		<name>hive.metastore.kerberos.principal</name>
		<value>hive/_HOST@RU-CENTRAL1.INTERNAL</value>
	</property>
</configuration>

    где RU-CENTRAL1.INTERNAL — ваш Kerberos-реалм.

  2. Если вы используете Impala с Ranger, обновите настройки Ranger согласно инструкции.

  3. Пересоздайте секрет Kubernetes:

    $ kubectl delete secret <hadoop-conf> -n <impala-cluster-ns>
$ kubectl create secret generic <hadoop-conf> -n <impala-cluster-ns> --from-file=core-site.xml --from-file=hdfs-site.xml --from-file=hive-site.xml

    где:

    • <hadoop-conf> — имя секрета с конфигурационными файлами ADH.

    • <impala-cluster-ns> — пространство имен, используемое кластером Impala.

  4. Создайте JKS-файл хранилища сертификатов. Данный truststore-файл должен содержать все сертификаты вашего ADH-кластера. Создайте секрет для truststore-файла:

    $ kubectl create secret generic ca-certs --namespace <impala-cluster-ns> --from-file=truststore.jks=/etc/ssl/truststore.jks

  5. Сгенерируйте сертификат для Impala:

    $ openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
-keyout impala-jdbc.ru-central1.internal.key \
-out impala-jdbc.ru-central1.internal.crt \
-subj "/CN=impala-jdbc.ru-central1.internal"

  6. Создайте секрет для входящих JDBC-соединений:

    $ kubectl -n <impala-cluster-ns> create secret generic impala-tls --from-file=cert.crt=impala-jdbc.ru-central1.internal.crt --from-file=crt.key=impala-jdbc.ru-central1.internal.key

Шаг 4. Обновление инсталляции Impala-кластера

  1. Обновите конфигурационный файл Impala-кластера (impala_cluster_values.yaml), добавив в него параметры Kerberos/SSL. Обновленный файл должен иметь следующий вид:

    image:
  registry: "<registry>"
  repository: "<image>"
  tag: "<tag>"
  pullPolicy: Always

useRanger: false
clusterDomain: cluster.local
configsSecretName: "hadoop-conf"

kerberos: (1)
  realm: RU-CENTRAL1.INTERNAL
  hostname: impala-jdbc.ru-central1.internal
  keytab:
    create: false
    secretName: impala-keytab
    labelSelector:
      env: prod

ssl:
  secretName: ca-store (2)
  trustStoreKey: truststore.jks

tls:
  secretName: impala-tls (3)
  certificateKey: cert.crt
  privateKey: crt.key
#  clientCaCertificate: ca.pem

catalog:

coordinator:

executor:
  replicas: 2

statestore:
    1 Параметры Kerberos для доступа защищенному кластеру Impala.
    2 Имя секрета с truststore-файлом.
    3 Имя секрета с сертификатом Impala.
    ПРИМЕЧАНИЕ

    Редактируя конфигурационные файлы для Impala, убедитесь, что значения следующих параметров совпадают:

  2. Обновите инсталляцию кластера Impala:

    $ helm upgrade --install impala-cluster oci://"$PRIVATE_REGISTRY"/adc-enterprise/charts/impala-cluster --version <version> -f impala_cluster_values.yaml --namespace <impala-cluster-ns> --create-namespace

  3. Удалите старые поды кластера, чтобы оператор Impala создал новые с обновленной конфигурацией:

    $ kubectl delete pods -n <impala-cluster-ns> -l app.kubernetes.io/instance=impala

  4. Проверьте, что все поды имеют состояние Running:

    $ kubectl get pods -n <impala-cluster-ns>

    Ожидаемый вывод:

    NAME                           READY   STATUS    RESTARTS   AGE
impala-cluster-catalog-0       1/1     Running   0          65m
impala-cluster-coordinator-0   1/1     Running   0          65m
impala-cluster-executor-0      1/1     Running   0          65m
impala-cluster-executor-1      1/1     Running   0          65m
impala-cluster-statestore-0    1/1     Running   0          65m

Шаг 5. Подключение к Impala по JDBC

Для внешнего доступа к Impala по JDBC необходимо настроить один из способов публикации сервиса, например, используя балансировщик нагрузки (load balancer) или Ingress-контроллер. Все настройки, связанные с публикацией сервиса, включая DNS, аннотации, параметры Ingress, TLS-сертификаты, правила балансировщика и прочие, должны быть указаны в соответствии с вашей инфраструктурой Kubernetes.

  1. Получите внешний IP-адрес балансировщика или Ingress-контроллера. Например:

    impala-lb                    LoadBalancer   10.96.231.158   10.92.42.144   21050:32154/TCP,26000:30753/TCP,24000:32645/TCP   25h

    Скопируйте внешний IP-адрес для дальнейших шагов (в данном примере это 10.92.42.144).

  2. Подключитесь к Impala по JDBC, например, с помощью DBeaver. Строка подключения JDBC имеет следующий вид:

    jdbc:impala://<external-ip>:21050/default;AuthMech=1;KrbServiceName=impala;KrbHostFQDN=impala-jdbc.ru-central1.internal;SSL=1;SSLTrustStore=<path>truststore.jks;SSLTrustStorePwd=<password>;httpPath=cliservice

    где:

    • <external-ip> — IP-адрес Ingress-контроллера или балансировщика.

    • KrbServiceName=impala — сервисное имя Kerberos.

    • KrbHostFQDN=impala-jdbc.ru-central1.internal — имя хоста, указанное в values-файле кластера Impala (impala_cluster_values.yaml).

    • SSLTrustStore=<path>/truststore.jks — путь к truststore-файлу с сертификатами для использования DBeaver.

    • SSLTrustStorePwd=<password> — пароль для доступа к truststore-файлу.

Нашли ошибку? Выделите текст и нажмите Ctrl+Enter чтобы сообщить о ней