Aws-cert-manager - История изменений

Sirmax: Sirmax переименовал страницу Aws LetsEncrypt в Aws-cert-manager

2025-06-23T09:29:37Z

Sirmax переименовал страницу Aws LetsEncrypt в Aws-cert-manager

← Предыдущая	Версия 09:29, 23 июня 2025
(нет различий)

Sirmax в 09:29, 23 июня 2025

2025-06-23T09:29:19Z

← Предыдущая		Версия 09:29, 23 июня 2025
Строка 38:		Строка 38:
	* Мониторит и продлевает его до истечения срока действия.		* Мониторит и продлевает его до истечения срока действия.

		+	==Возможные источники сертефикатов==
−
		+	* https://cert-manager.io/docs/configuration/issuers/
	==Установка==		==Установка==
	<PRE>		<PRE>

Sirmax в 09:25, 23 июня 2025

2025-06-23T09:25:19Z

← Предыдущая		Версия 09:25, 23 июня 2025
Строка 5:		Строка 5:
	[[Категория: SSL]]		[[Категория: SSL]]
	[[Категория: LetsEncrypt]]		[[Категория: LetsEncrypt]]
		+	[[Категория: cert-manager]]

	Для Ingress требуется автоматически выписывать сертификаты для доменов которые "Хостятся" на нем		Для Ingress требуется автоматически выписывать сертификаты для доменов которые "Хостятся" на нем

Sirmax в 10:10, 9 июня 2025

2025-06-09T10:10:09Z

← Предыдущая		Версия 10:10, 9 июня 2025
Строка 2:		Строка 2:
	[[Категория: K8s]]		[[Категория: K8s]]
	[[Категория: EKS]]		[[Категория: EKS]]
		+	[[Категория: Ingress]]
		+	[[Категория: SSL]]
		+	[[Категория: LetsEncrypt]]

	Для Ingress требуется автоматически выписывать сертификаты для доменов которые "Хостятся" на нем		Для Ingress требуется автоматически выписывать сертификаты для доменов которые "Хостятся" на нем

Sirmax: /* AltNames ? */

2025-06-08T17:35:39Z

AltNames ?

← Предыдущая		Версия 17:35, 8 июня 2025
Строка 331:		Строка 331:
	<BR>		<BR>
	Ну и конечно еще более радикальный способ - сделать 2 экземпляра <code>Ingress</code>		Ну и конечно еще более радикальный способ - сделать 2 экземпляра <code>Ingress</code>
		+
		+	=Дополгительный вопросы для проработки позже=
		+	* Проверить другие способы получения сертификатов (Vault, Amazon)

Sirmax в 17:34, 8 июня 2025

2025-06-08T17:34:18Z

← Предыдущая		Версия 17:34, 8 июня 2025
Строка 3:		Строка 3:
	[[Категория: EKS]]		[[Категория: EKS]]

−	Для Ingress требуется автоматически выписывать ~~сертефикаты~~ для доменов которые "Хостятся" на нем	+	Для Ingress требуется автоматически выписывать сертификаты для доменов которые "Хостятся" на нем
	<BR>		<BR>

Строка 16:		Строка 16:
	** Список возможных Issuers досаточно широк (https://cert-manager.io/docs/configuration/issuers/), для тестирования можно например использовать локально развернутый Hashicorp Vault		** Список возможных Issuers досаточно широк (https://cert-manager.io/docs/configuration/issuers/), для тестирования можно например использовать локально развернутый Hashicorp Vault
	<BR>		<BR>
−	* Использовать ~~сертефикаты~~ от AWS (это пока не реализовано)	+	* Использовать сертификаты от AWS (это пока не реализовано)

	=<code>cert-manager</code>=		=<code>cert-manager</code>=
Строка 24:		Строка 24:
	* Установка в том чимсле создания <code>Custom Resource Definition</code> (далее <code>CRD</code>)		* Установка в том чимсле создания <code>Custom Resource Definition</code> (далее <code>CRD</code>)
	* Cоздается ресусурс типа <code>Issuer</code> или <code>ClusterIssuer</code> — описывает, откуда брать сертификаты		* Cоздается ресусурс типа <code>Issuer</code> или <code>ClusterIssuer</code> — описывает, откуда брать сертификаты
−	** Разница в том что <code>Issuer</code> доступен только внутри namespace, в моем случае когда все ~~сертефикаты~~ нужны для нескольких копий приложения ("окружений"), например <code>dev.domain.tld</code>, <code>staging.domain.tld</code>, <code>qa.domain.tld</code> нужно будет изменить <code>ClusterIssuer</code> на <code>Issuer</code>. Пока окружение одно это не важно, но как только их несколько то не хочется иметь один ~~сертефикат~~ на всех с длинным списком Altnames (но это требует проверки)	+	** Разница в том что <code>Issuer</code> доступен только внутри namespace, в моем случае когда все сертификаты нужны для нескольких копий приложения ("окружений"), например <code>dev.domain.tld</code>, <code>staging.domain.tld</code>, <code>qa.domain.tld</code> нужно будет изменить <code>ClusterIssuer</code> на <code>Issuer</code>. Пока окружение одно это не важно, но как только их несколько то не хочется иметь один сертификат на всех с длинным списком Altnames (но это требует проверки)

	* После создания </code>Certificate</code>-ресурса — <code>cert-manager</code> следит за ним и выполняет выпуск согласно настройкам ресурса, результат сохраняет в <code>Secret</code>		* После создания </code>Certificate</code>-ресурса — <code>cert-manager</code> следит за ним и выполняет выпуск согласно настройкам ресурса, результат сохраняет в <code>Secret</code>
Строка 77:		Строка 77:
	}}		}}

−	=Генерация ~~сертефикатов~~=	+	=Генерация сертификатов=
	==Аннотация <code>Ingress</code>==		==Аннотация <code>Ingress</code>==
−	Для того что бы включить генерацию ~~сертефикатов~~ требуется указать аннотацию у <code>Ingress</code>, в которой указать имя желаемого <code>Issuer</code> / <code>ClusterIssuer</code>	+	Для того что бы включить генерацию сертификатов требуется указать аннотацию у <code>Ingress</code>, в которой указать имя желаемого <code>Issuer</code> / <code>ClusterIssuer</code>
	<PRE>		<PRE>
	apiVersion: networking.k8s.io/v1		apiVersion: networking.k8s.io/v1
Строка 115:		Строка 115:

	{{caution\|text=		{{caution\|text=
−	Это может выглядеть как парадокс "курицы и яйца" - секркт должен быть на момент выпуска ~~сертефиката~~,<BR>	+	Это может выглядеть как парадокс "курицы и яйца" - секркт должен быть на момент выпуска сертификата,<BR>
−	но его нельзя создать так как нет еще ~~сертефиката~~ который туда ложить.	+	но его нельзя создать так как нет еще сертификата который туда ложить.
	<BR>		<BR>
	<BR>		<BR>
Строка 228:		Строка 228:
	</PRE>		</PRE>

−	Проверить содержимое и декодировать ~~сертефикат~~ можно например так	+	Проверить содержимое и декодировать сертификат можно например так
	<PRE>		<PRE>
	kubectl -n mpp-staging get secret mpp-staging-tls -o yaml \		kubectl -n mpp-staging get secret mpp-staging-tls -o yaml \

Sirmax: /* AltNames ? */

2025-06-08T17:33:22Z

AltNames ?

← Предыдущая		Версия 17:33, 8 июня 2025
Строка 304:		Строка 304:
	<BR>		<BR>
	==<code>AltNames ?</code>==		==<code>AltNames ?</code>==
−	В конфигурации <code>Ingress</code> для всех ~~сертефикато~~ указан общий секрет:	+	В конфигурации <code>Ingress</code> для всех сертификатов указан общий секрет:
	<PRE>		<PRE>
	kubectl -n mpp-staging get ingress mpp-ingress -o yaml \| yq '.spec.tls'		kubectl -n mpp-staging get ingress mpp-ingress -o yaml \| yq '.spec.tls'
Строка 316:		Строка 316:
	secretName: mpp-staging-tls		secretName: mpp-staging-tls
	</PRE>		</PRE>
−	Если хочется иметь разные ~~сертефикаты~~ для разных хостов, то нужно использовать конфигурацию вида	+	Если хочется иметь разные сертификаты для разных хостов, то нужно использовать конфигурацию вида
	<PRE>		<PRE>
	- hosts:		- hosts:
Строка 327:		Строка 327:
	secretName: mpp-staging-myseconddomain-tls		secretName: mpp-staging-myseconddomain-tls
	</PRE>		</PRE>
−	В такой конфигурации будет создано 2 отдельных ~~сертефиката~~ каждый со свои списком AltNames. <BR>	+	В такой конфигурации будет создано 2 отдельных сертификата каждый со свои списком AltNames. <BR>
	Это может быть нужно, если не хочется дать понять внешнему пользователю что домены как-либо связаны.		Это может быть нужно, если не хочется дать понять внешнему пользователю что домены как-либо связаны.
	<BR>		<BR>

Sirmax: /* AltNames ? */

2025-06-08T17:31:58Z

AltNames ?

← Предыдущая		Версия 17:31, 8 июня 2025
Строка 323:		Строка 323:
	secretName: mpp-staging-mydomain-tld-tls		secretName: mpp-staging-mydomain-tld-tls
	- hosts:		- hosts:
		+	- seeble1.staging.myseconddomain.tld
−	...
	- seeble2.staging.myseconddomain.tld		- seeble2.staging.myseconddomain.tld
	secretName: mpp-staging-myseconddomain-tls		secretName: mpp-staging-myseconddomain-tls
	</PRE>		</PRE>
		+	В такой конфигурации будет создано 2 отдельных сертефиката каждый со свои списком AltNames. <BR>
		+	Это может быть нужно, если не хочется дать понять внешнему пользователю что домены как-либо связаны.
		+	<BR>
		+	Ну и конечно еще более радикальный способ - сделать 2 экземпляра <code>Ingress</code>

Sirmax в 17:25, 8 июня 2025

2025-06-08T17:25:33Z

@@ Строка 303: / Строка 303: @@
 <BR>
 <PRE>
 kubectl -n mpp-staging get ingress mpp-ingress -o yaml | yq '.spec.tls'
 - hosts:
     - be.staging.mydomain.tld
@@ Строка 313: / Строка 315: @@
     - seeble2.staging.myseconddomain.tld
   secretName: mpp-staging-tls
 </PRE>

Sirmax в 17:21, 8 июня 2025

2025-06-08T17:21:57Z

← Предыдущая		Версия 17:21, 8 июня 2025
Строка 301:		Строка 301:
	</PRE>		</PRE>
	Тут можно видеть что все доменные имена, которые присутвуют в конфигурации <code>Ingress</code> перечислены как <code>Alternative Name</code>		Тут можно видеть что все доменные имена, которые присутвуют в конфигурации <code>Ingress</code> перечислены как <code>Alternative Name</code>
		+
		+	<BR>
		+	=1=
		+
		+	<PRE>
		+	kubectl -n mpp-staging get ingress mpp-ingress -o yaml \| yq '.spec.tls'
		+	- hosts:
		+	- be.staging.mydomain.tld
		+	- login.staging.mydomain.tld
		+	...
		+	- seeble2.staging.myseconddomain.tld
		+	secretName: mpp-staging-tls
		+	</PRE>