애플리케이션 접근 문제 해결 | Teleport 공식 기술 문서 한국판 by 인포그랩

애플리케이션 접근 문제 해결

이 섹션에서는 Teleport로 애플리케이션에 대한 접근을 관리하는 데 발생할 수 있는 일반적인 문제와 이를 우회하거나 해결하는 방법을 설명합니다.

애플리케이션에 접근할 수 없음

애플리케이션 접근을 방해하는 가장 일반적인 문제는 교차 사이트 요청 위조(CSRF) 또는 교차 출처 리소스 공유(CORS) 오류입니다.

교차 사이트 요청 위조는 인증된 사용자의 신원을 사용하여 사용자의 동의 없이 작업을 수행하는 공격 유형입니다. 예를 들어, CSRF 공격은 사용자의 자격 증명을 사용하여 위조된 요청을 발행하여 자금을 이체하거나 비밀번호를 변경하거나 구매를 할 수 있습니다. 브라우저와 애플리케이션은 이러한 유형의 공격을 방지하기 위한 검사를 수행합니다. 그러나 이러한 검사는 특정 조건에서 합법적인 요청도 차단할 수 있습니다.

증상

브라우저가 보안 쿠키를 생성할 수 없거나 이전에 생성된 보안 쿠키에서 로그인 권한을 부여받을 수 없는 경우, 다음과 같은 오류가 표시될 수 있습니다:

유효하지 않거나 누락된 CSRF 토큰

이 오류는 광고 차단 또는 스크립트 차단 확장기능이나 브라우저 자체로 인해 발생할 수 있습니다. Teleport를 통해 애플리케이션에 접근할 때, Grafana 및 ArgoCD 와 같이 WebSockets를 광범위하게 사용하는 애플리케이션에서 이 오류가 가장 자주 발생할 수 있으며, 교차 사이트 스크립팅 제한으로 인해 트래픽을 명시적으로 허용해야 하는 브라우저에서 나타날 수 있습니다.

교차 사이트 요청 위조(CSRF) 또는 교차 출처 리소스 공유(CORS)의 문제는 일반적으로 애플리케이션 기능 손실, 트래픽이 허용되지 않음을 나타내는 애플리케이션 자체의 오류, 또는 CORS 또는 CSRF 오류를 나타내는 애플리케이션 로그로 이어집니다.

대부분의 경우, 각 애플리케이션에 대한 Teleport 구성에서 Origin 및 Host 헤더에 대해 명시적인 rewrite 설정을 추가함으로써 이러한 유형의 문제를 해결할 수 있습니다.

해결책 1: 애플리케이션 서비스 구성 파일

정적 구성 앱을 /etc/teleport.yaml 에서 사용하는 경우 CSRF 또는 CORS 문제를 해결하려면:

텍스트 편집기로 애플리케이션 구성이 포함된 /etc/teleport.yaml 파일을 엽니다.

2. 다음 grafana 예제와 유사한 rewrite.headers 섹션을 추가합니다:

app_service:
  enabled: true
  apps:
    - name: grafana
      uri: http://localhost:3000
      public_addr: grafana.teleport.example.com
      rewrite:
        headers:
          - "Origin: https://grafana.teleport.example.com" # Teleport 애플리케이션 서브도메인이 "https://"로 시작
          - "Host: grafana.teleport.example.com" # Teleport 애플리케이션 서브도메인 자체

변경 사항을 저장하고 Teleport 서비스를 재시작합니다.

해결책 2: `teleport-kube-agent` 값 파일

Kubernetes 및 teleport-kube-agent 를 사용하여 애플리케이션을 배포하는 경우 CSRF 또는 CORS 문제를 해결하려면:

텍스트 편집기로 애플리케이션 구성 파일이 포함된 teleport/examples/chart/teleport-kube-agent/values.yaml 파일을 엽니다.

2. values.yaml 파일에서 apps 섹션을 찾습니다.

# 프록시될 애플리케이션의 세부사항. 예:
# apps:
#  - name: grafana
#    uri: http://localhost:3000
apps: []

다음 grafana 예제와 유사한 rewrite.headers 섹션을 추가합니다:

apps:
  - name: grafana
    uri: http://localhost:3000
    public_addr: grafana.teleport.example.com
    rewrite:
      headers:
        - "Origin: https://grafana.teleport.example.com" # Teleport 애플리케이션 서브도메인이 "https://"로 시작
        - "Host: grafana.teleport.example.com" # Teleport 애플리케이션 서브도메인 자체

솔루션 3: 동적 앱 구성

동적 구성이 있는 애플리케이션을 배포하는 경우 CSRF 또는 CORS 문제를 해결하려면:

rewrite.headers 섹션을 포함하도록 동적 앱 구성을 수정하십시오:

kind: app
version: v3
metadata:
  name: grafana
  labels:
    env: dev
spec:
  uri: http://localhost:3000
  public_addr: grafana.teleport.example.com
  rewrite:
    headers:
      - name: "Origin"
        value: "https://grafana.teleport.example.com" # Teleport 애플리케이션 서브도메인을 "https://"로 접두사
      - name: "Host"
        value: "grafana.teleport.example.com" # Teleport 애플리케이션 서브도메인 자체

솔루션 4: Kubernetes 앱 자동 검색

Kubernetes 자동 검색을 사용하여 애플리케이션을 배포하는 경우 CSRF 또는 CORS 문제를 해결하려면:

rewrite.headers 섹션을 포함하도록 Kubernetes Service 구성을 수정하십시오:

apiVersion: v1
kind: Service
metadata:
  annotations:
    teleport.dev/app-rewrite: |
      headers:
      - name: "Origin"
        value: "https://grafana.teleport.example.com" # Teleport 애플리케이션 서브도메인을 "https://"로 접두사
      - name: "Host"
        value: "grafana.teleport.example.com" # Teleport 애플리케이션 서브도메인 자체

신뢰할 수 없는 인증서 오류

기본적으로, Teleport Proxy Service에서 제공하는 인증서는 신뢰할 수 있고 인식된 인증 기관에서 발급되어야 합니다.

증상

자체 서명된 인증서를 생성했거나 인식되지 않는 인증 기관에 의해 서명된 인증서를 사용하는 경우, 다음과 유사한 오류가 표시될 수 있습니다:

ERROR: "unable to verify HTTPS certificate chain in : \x1b[31mERROR: \x1b[0mWARNING:"

  연결하는 프록시가 알려지지 않은 기관에 의해 서명된 인증서를 제시했습니다.
  이는 자체 서명된 인증서를 제시하거나 인증서가 클라이언트가 알지 못하는 기관에 의해 실제로 서명된 것일 수 있습니다.

솔루션

루트 인증 기관과 자체 서명된 인증서를 제대로 생성한 경우, 클라이언트가 인증서를 수용할 수 있도록 --insecure 명령줄 옵션을 사용할 수 있습니다. 예를 들어, 다음과 유사한 명령을 실행하여 자체 서명된 인증서로 Teleport를 시작할 수 있습니다:

sudo teleport start --config=/etc/teleport.yaml --insecure

Teleport Proxy Service에서 제시된 인증서 체인을 검증하기 위해 사용하고 싶은 인증 기관이 있는 경우, 명령줄에서 SSL_CERT_FILE 또는 SSL_CERT_DIR 환경 변수를 수동으로 설정할 수 있습니다. 예를 들어:

sudo SSL_CERT_FILE=path-to-rootCA-pem teleport start --config=/etc/teleport.yaml

sudo 는 기본적으로 환경 변수를 상속하지 않기 때문에, SSL_CERT_FILE 및 SSL_CERT_DIR 환경 변수를 명령줄 옵션으로 지정해야 합니다.

요청 헤더가 너무 큼

기본적으로 Teleport는 사용자의 Teleport 역할과 특성을 애플리케이션에 발급된 JWT에 포함시킵니다. 사용자가 많은 역할이나 특성을 가진 경우, 이로 인해 JWT가 너무 커져 요청 실패를 초래할 수 있습니다.

증상

Teleport 뒤의 HTTP 애플리케이션에 연결하려고 할 때 요청 헤더 필드가 너무 큽니다라는 오류가 표시됩니다.

솔루션

당신이 Teleport로 보호하는 애플리케이션이 사용자에 대한 Teleport 역할이나 특성을 알 필요가 없는 경우, Teleport를 구성하여 이 정보를 JWT에서 생략할 수 있습니다. 이렇게 하면 더 작은 JWT가 생성되어 제한을 초과할 가능성이 줄어듭니다.

이 구성은 애플리케이션의 rewrite 구성의 jwt_claims 속성 아래에서 사용할 수 있습니다. 자세한 내용은 웹 애플리케이션 접근을 참조하십시오.

Teleport 원문 보기