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

애플리케이션 액세스 문제 해결

이 섹션에서는 Teleport로 애플리케이션에 대한 액세스를 관리하는 데 발생할 수 있는 일반적인 문제와 이를 사전 대응하거나 해결하는 방법에 대해 설명합니다.

애플리케이션에 액세스할 수 없음

애플리케이션에 대한 액세스를 차단하는 가장 일반적인 문제는 Cross-Site Request Forgery (CSRF) 또는 Cross-Origin Resource Sharing (CORS) 오류입니다.

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

증상

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

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

이 오류는 광고 차단기 또는 스크립트 차단 확장 프로그램 또는 브라우저 자체에 의해 발생할 수 있습니다. Teleport를 통한 애플리케이션에 액세스할 때 이 오류는 WebSockets를 광범위하게 사용하는 애플리케이션(예: Grafana 및 ArgoCD)과 크로스 사이트 스크립팅 제한이 트래픽이 명시적으로 허용되어야 하는 브라우저에서 가장 자주 발생할 수 있습니다.

Cross-Site Request Forgery (CSRF) 또는 Cross-Origin Resource Sharing (CORS) 문제는 대개 애플리케이션 기능 손실, 트래픽이 허용되지 않는다는 애플리케이션 자체의 오류, 또는 CORS 또는 CSRF 오류를 나타내는 애플리케이션 로그를 초래합니다.

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

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

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

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

다음 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" # "https://"가 추가된 Teleport 애플리케이션 서브도메인
      - "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 파일을 엽니다.

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" # "https://"가 추가된 Teleport 애플리케이션 서브도메인
    - "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" # "https://"가 추가된 Teleport 애플리케이션 서브도메인
    - name: "Host"
      value: "grafana.teleport.example.com" # Teleport 애플리케이션 서브도메인 자체

해결책 4: Kubernetes 앱 자동 검색

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

Kubernetes Service 구성을 편집하여 rewrite.headers 섹션을 포함합니다:

apiVersion: v1
kind: Service
metadata:
  annotations:
    teleport.dev/app-rewrite: |
      headers:
      - name: "Origin"
        value: "https://grafana.teleport.example.com" # "https://"가 추가된 Teleport 애플리케이션 서브도메인
      - 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

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

요청 헤더가 너무 큼

기본적으로 Teleport는 사용자의 Teleport 역할과 특성을 애플리케이션용으로 발급되는 JWT에 포함합니다. 사용자의 Teleport에 역할이나 특성이 많은 경우 JWT가 너무 커져서 요청이 실패할 수 있습니다.

증상

Teleport 뒤에서 HTTP 앱에 연결하려고 할 때 요청 헤더 필드가 너무 큽니다라는 오류가 표시됩니다.

해결책

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

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

Teleport 원문 보기