InfoGrab Docs

관리형 업데이트

요약

많은 Teleport 리소스가 에이전트 없는 모드를 지원하지만, 에이전트 배포가 때로는 더 간단하고 편리합니다. Teleport Agent 관리형 업데이트에는 두 가지 버전이 있습니다: 업데이터는 에이전트 옆에 배포되어 에이전트를 업데이트하는 소프트웨어입니다.

많은 Teleport 리소스가 에이전트 없는 모드를 지원하지만, 에이전트 배포가 때로는 더 간단하고 편리합니다. 그러나 대규모 Teleport 배포는 추가적인 부담을 만들 수 있습니다: 모든 에이전트 업데이트.

Teleport Agent 관리형 업데이트에는 두 가지 버전이 있습니다:

  • 버전 1: apt, yum 또는 zypper 패키지 관리자를 사용하는 systemd 기반 Linux 배포판과 Kubernetes 클러스터를 지원합니다.
  • 버전 2: v1에서 패키지 관리자 의존성을 제거하고, 더 다양한 설정(예: Teleport Community Edition, Teleport Enterprise, FIPS, 단일 호스트의 여러 에이전트)을 지원하며, 업데이트 일정에 대한 더 많은 제어를 제공합니다.

업데이트 로직 및 실패 모드#

업데이터는 에이전트 옆에 배포되어 에이전트를 업데이트하는 소프트웨어입니다. 여러 에이전트를 업데이트하려면 여러 업데이터가 필요합니다.

업데이터를 Teleport와 최대한 분리되도록 설계했습니다. 업데이터는 에이전트가 Teleport 클러스터에 조인할 수 없는 경우에도 에이전트를 업데이트할 수 있습니다. 손상된 버전을 푸시할 수 있지만, 롤백/롤포워드는 항상 리소스에 수동으로 연결하여 에이전트를 수정하지 않고도 가능해야 합니다.

업데이터는 버전 서버에서 대상 버전을 주기적으로 가져와 에이전트를 대상 버전으로 업데이트합니다. 에이전트를 재시작하면 현재 열려 있는 세션이 중단될 수 있으므로, 유지 관리 창 중이거나 에이전트가 비정상인 경우에만 에이전트를 업데이트합니다.

버전 2 업데이트 로직#

관리형 업데이트 버전 2에서 Teleport 클러스터 자체가 각 에이전트에게 업데이트 여부를 알려줌으로써 업데이트를 주도합니다. 업데이트 결정을 중앙화하면 롤아웃에 대한 더 많은 제어가 가능합니다. Teleport 클러스터는 모든 에이전트를 볼 수 있으므로, 업데이트를 점진적으로 롤아웃하거나 결함이 있는 업데이트를 감지하는 것과 같은 더 복잡한 결정을 내릴 수 있습니다.

버전 2에서 업데이터는 업데이트 후 에이전트를 모니터링합니다. 에이전트가 정상적으로 돌아오지 않으면, 업데이터는 연결 복원을 시도하기 위해 마지막으로 작동하는 버전으로 자동으로 롤백을 시작합니다.

버전 1 업데이트 로직#

관리형 업데이트 버전 1에서 업데이터가 업데이트를 주도하고, Teleport는 버전 일정을 제공하는 것만 담당합니다.

유지 관리 일정이 있을 때 업데이터는 이를 준수합니다. 그러나 업데이터가 유지 관리 일정을 찾을 수 없으면 에이전트를 비정상으로 간주하고 가능한 빨리 업데이트를 수행합니다. 마찬가지로 업데이터가 에이전트가 비정상임을 감지하면 저하된 상태에서 복구하려고 대기 중인 업데이트를 즉시 적용합니다.

추가적인 안전 장치도 구현했습니다: 중요 유지 관리 토글. 버전 서버는 업데이트가 중요하다고 지정할 수 있습니다. 중요 업데이트는 업데이터가 일반 유지 관리 창 밖에 있더라도 적용됩니다.

보안#

버전 2 보안 불변성#

버전 2 업데이터는 TLS를 통해 CDN에서 바이너리를 가져오고 shasum으로 무결성을 검증합니다. 에이전트는 기본적으로 공식 Teleport CDN을 사용합니다. 사용자 정의 CDN은 업데이터 수준에서 구성할 수 있습니다. 보안상의 이유로, 업데이터 CDN을 원격으로 재구성하고 임의의 바이너리를 설치하게 하는 방법은 없습니다.

현재 바이너리는 서명되지 않으며, 이는 향후 변경될 수 있습니다. OCI 아티팩트(Docker 이미지)는 cosign의 서명 형식을 사용하여 서명됩니다.

버전 1 보안 불변성#

에이전트를 업데이트할 때, 업데이터는 배포 전에 새 버전의 신뢰성을 확인합니다. apt, yum 또는 zypper를 사용하는 Linux 배포판에서는 기존 패키지 서명 시스템에 의존합니다. Kubernetes 기반 환경에서는 OCI 이미지 서명(cosign의 서명)을 검증합니다.

버전 서버 및 신뢰의 원천#

에이전트 버전은 다음 제약 조건을 따릅니다:

  • 에이전트는 절대 Proxy 또는 Auth Service 버전을 초과해서는 안 됩니다.
  • 에이전트는 항상 Proxy 또는 Auth Service 버전보다 하나의 주요 버전 이하여야 합니다.

모범 사례는 항상 에이전트 버전을 Proxy Service 및 Auth Service 버전과 맞추는 것입니다. Auth Service 및 Proxy Service를 업그레이드하려면 Teleport 클러스터 업그레이드 가이드를 따르십시오.

업데이터는 Teleport 프록시를 쿼리하여 실행해야 하는 버전을 검색합니다.

Teleport Cloud#

Teleport Cloud를 사용하는 경우 대상 버전은 자동으로 관리됩니다. 관리형 업데이트 버전 1에서는 유지 관리 창을 구성할 수 있습니다. 관리형 업데이트 버전 2에서는 사용자 정의 업데이트 일정을 구성하고 에이전트가 언제, 어떤 순서로 업데이트되는지 제어할 수 있습니다.

Self-hosted Teleport#

Teleport Enterprise를 자체 호스팅하는 경우 자동 에이전트 업데이트를 설정할 수 있습니다. 원하는 에이전트 버전을 구성할 책임이 있습니다. 또한 에이전트가 정상이고 올바르게 업데이트되는지 확인하기 위해 에이전트 상태 및 롤아웃 상태를 모니터링해야 합니다.

다음 단계#

클러스터에서 관리형 업데이트 v2 구성을 수행하십시오.

관리형 업데이트 v2 리소스 참조를 참조하십시오.

이후 업그레이드 절차의 일부로 에이전트를 자동 업데이트에 등록할 수 있습니다.

관리형 업데이트

원문 보기
요약

많은 Teleport 리소스가 에이전트 없는 모드를 지원하지만, 에이전트 배포가 때로는 더 간단하고 편리합니다. Teleport Agent 관리형 업데이트에는 두 가지 버전이 있습니다: 업데이터는 에이전트 옆에 배포되어 에이전트를 업데이트하는 소프트웨어입니다.

많은 Teleport 리소스가 에이전트 없는 모드를 지원하지만, 에이전트 배포가 때로는 더 간단하고 편리합니다. 그러나 대규모 Teleport 배포는 추가적인 부담을 만들 수 있습니다: 모든 에이전트 업데이트.

Teleport Agent 관리형 업데이트에는 두 가지 버전이 있습니다:

  • 버전 1: apt, yum 또는 zypper 패키지 관리자를 사용하는 systemd 기반 Linux 배포판과 Kubernetes 클러스터를 지원합니다.
  • 버전 2: v1에서 패키지 관리자 의존성을 제거하고, 더 다양한 설정(예: Teleport Community Edition, Teleport Enterprise, FIPS, 단일 호스트의 여러 에이전트)을 지원하며, 업데이트 일정에 대한 더 많은 제어를 제공합니다.

업데이트 로직 및 실패 모드#

업데이터는 에이전트 옆에 배포되어 에이전트를 업데이트하는 소프트웨어입니다. 여러 에이전트를 업데이트하려면 여러 업데이터가 필요합니다.

업데이터를 Teleport와 최대한 분리되도록 설계했습니다. 업데이터는 에이전트가 Teleport 클러스터에 조인할 수 없는 경우에도 에이전트를 업데이트할 수 있습니다. 손상된 버전을 푸시할 수 있지만, 롤백/롤포워드는 항상 리소스에 수동으로 연결하여 에이전트를 수정하지 않고도 가능해야 합니다.

업데이터는 버전 서버에서 대상 버전을 주기적으로 가져와 에이전트를 대상 버전으로 업데이트합니다. 에이전트를 재시작하면 현재 열려 있는 세션이 중단될 수 있으므로, 유지 관리 창 중이거나 에이전트가 비정상인 경우에만 에이전트를 업데이트합니다.

버전 2 업데이트 로직#

관리형 업데이트 버전 2에서 Teleport 클러스터 자체가 각 에이전트에게 업데이트 여부를 알려줌으로써 업데이트를 주도합니다. 업데이트 결정을 중앙화하면 롤아웃에 대한 더 많은 제어가 가능합니다. Teleport 클러스터는 모든 에이전트를 볼 수 있으므로, 업데이트를 점진적으로 롤아웃하거나 결함이 있는 업데이트를 감지하는 것과 같은 더 복잡한 결정을 내릴 수 있습니다.

버전 2에서 업데이터는 업데이트 후 에이전트를 모니터링합니다. 에이전트가 정상적으로 돌아오지 않으면, 업데이터는 연결 복원을 시도하기 위해 마지막으로 작동하는 버전으로 자동으로 롤백을 시작합니다.

버전 1 업데이트 로직#

관리형 업데이트 버전 1에서 업데이터가 업데이트를 주도하고, Teleport는 버전 일정을 제공하는 것만 담당합니다.

유지 관리 일정이 있을 때 업데이터는 이를 준수합니다. 그러나 업데이터가 유지 관리 일정을 찾을 수 없으면 에이전트를 비정상으로 간주하고 가능한 빨리 업데이트를 수행합니다. 마찬가지로 업데이터가 에이전트가 비정상임을 감지하면 저하된 상태에서 복구하려고 대기 중인 업데이트를 즉시 적용합니다.

추가적인 안전 장치도 구현했습니다: 중요 유지 관리 토글. 버전 서버는 업데이트가 중요하다고 지정할 수 있습니다. 중요 업데이트는 업데이터가 일반 유지 관리 창 밖에 있더라도 적용됩니다.

보안#

버전 2 보안 불변성#

버전 2 업데이터는 TLS를 통해 CDN에서 바이너리를 가져오고 shasum으로 무결성을 검증합니다. 에이전트는 기본적으로 공식 Teleport CDN을 사용합니다. 사용자 정의 CDN은 업데이터 수준에서 구성할 수 있습니다. 보안상의 이유로, 업데이터 CDN을 원격으로 재구성하고 임의의 바이너리를 설치하게 하는 방법은 없습니다.

현재 바이너리는 서명되지 않으며, 이는 향후 변경될 수 있습니다. OCI 아티팩트(Docker 이미지)는 cosign의 서명 형식을 사용하여 서명됩니다.

버전 1 보안 불변성#

에이전트를 업데이트할 때, 업데이터는 배포 전에 새 버전의 신뢰성을 확인합니다. apt, yum 또는 zypper를 사용하는 Linux 배포판에서는 기존 패키지 서명 시스템에 의존합니다. Kubernetes 기반 환경에서는 OCI 이미지 서명(cosign의 서명)을 검증합니다.

버전 서버 및 신뢰의 원천#

에이전트 버전은 다음 제약 조건을 따릅니다:

  • 에이전트는 절대 Proxy 또는 Auth Service 버전을 초과해서는 안 됩니다.
  • 에이전트는 항상 Proxy 또는 Auth Service 버전보다 하나의 주요 버전 이하여야 합니다.

모범 사례는 항상 에이전트 버전을 Proxy Service 및 Auth Service 버전과 맞추는 것입니다. Auth Service 및 Proxy Service를 업그레이드하려면 Teleport 클러스터 업그레이드 가이드를 따르십시오.

업데이터는 Teleport 프록시를 쿼리하여 실행해야 하는 버전을 검색합니다.

Teleport Cloud#

Teleport Cloud를 사용하는 경우 대상 버전은 자동으로 관리됩니다. 관리형 업데이트 버전 1에서는 유지 관리 창을 구성할 수 있습니다. 관리형 업데이트 버전 2에서는 사용자 정의 업데이트 일정을 구성하고 에이전트가 언제, 어떤 순서로 업데이트되는지 제어할 수 있습니다.

Self-hosted Teleport#

Teleport Enterprise를 자체 호스팅하는 경우 자동 에이전트 업데이트를 설정할 수 있습니다. 원하는 에이전트 버전을 구성할 책임이 있습니다. 또한 에이전트가 정상이고 올바르게 업데이트되는지 확인하기 위해 에이전트 상태 및 롤아웃 상태를 모니터링해야 합니다.

다음 단계#

클러스터에서 관리형 업데이트 v2 구성을 수행하십시오.

관리형 업데이트 v2 리소스 참조를 참조하십시오.

이후 업그레이드 절차의 일부로 에이전트를 자동 업데이트에 등록할 수 있습니다.