Share via


서비스 패브릭 REST 요청 인증

Service Fabric 클러스터는 X.509 인증서, Kerberos 또는 X.509 인증서와 Kerberos의 조합을 사용하여 보호될 수 있습니다. 이 문서에서는 다음을 설명합니다.

  • HttpGatewayEndpoints(REST 엔드포인트)가 특정 보안 솔루션을 준수하도록 클러스터 매니페스트를 편집하는 방법

  • 각 솔루션(X.509, Kerberos 또는 X.509와 Kerberos 함께 사용)에서 작동하도록 REST 호출을 수정하는 방법

X.509 보안을 사용하는 Http 게이트웨이

Azure 및 온-프레미스에서 Service Fabric의 REST 엔드포인트는 다음을 위해 X.509 인증서를 사용하여 지원합니다.

  1. 클라이언트의 인증 및 권한 부여: Service Fabric은 인증서에 따라 사용자 액세스, 관리자 액세스 또는 REST 클라이언트에 대한 액세스 권한을 부여하도록 구성할 수 있습니다.

  2. Service Fabric 노드 인증: REST 클라이언트는 올바른 Service Fabric 노드 중 하나와 통신하고 있는지 확인할 수 있습니다.

  3. 메시지(REST 요청 및 응답) 암호화

참고

사용자 권한이 있는 클라이언트에게는 https://localhost:19007/Nodes?api-version=6.0과 같은 읽기 요청에 대한 권한만 제공됩니다. 관리자 권한이 있는 클라이언트에게는 읽기 요청 및 쓰기 요청에 대한 권한이 제공됩니다. 쓰기 요청의 예제는 https://localhost:19007/Nodes/<NodeName>/$/Deactivate?api-version=6.0와 같습니다.

클러스터 매니페스트 변경

이 섹션에서는 X.509 인증서를 사용하도록 구성된 클러스터 매니페스트가 이미 있다고 가정합니다. 자세한 내용은 X.509 인증서를 사용하여 클러스터 보안을 참조하세요.

클라이언트의 인증 및 권한 부여(사용자 및 관리) 및 Service Fabric 노드의 인증을 지원하도록 클러스터를 구성하려면 클러스터 매니페스트에서 다음 매개 변수를 설정해야 합니다.

  • 각 노드 형식에 대한 서버 및 클라이언트 인증서의 지문

    • <ClientCertificate X509FindValue="…" />

    • <ServerCertificate X509FindValue="…" />

  • 보안 섹션

    • <Parameter Name="ClientRoleEnabled" Value="true" />

    • <Parameter Name="ServerAuthCredentialType" Value="X509" />

    • ClientAuthAllowedCommonNames 매개 변수

    • AdminAllowedCommonNames 매개 변수

    • ServerAuthAllowedCommonNames 매개 변수

이미 X.509로 보호된 클러스터 매니페스트에서 HttpGateway를 사용하도록 설정하려면(즉, 클러스터 및 클라이언트/서버 보안이 이미 사용됨) 다음 변경 내용만 필요합니다.

  • 모든 HttpGatewayEndpoint 요소의 프로토콜을 "https"로 설정합니다. 예를 들어 <HttpGatewayEndpoint Port="19017" Protocol="https"/>

  • HttpGateway 섹션에서 HttpGateway를 사용하도록 설정합니다. 예를 들어 Parameter <Name="IsEnabled" Value="true"/>

REST API와 X.509를 함께 사용하는 방법

X.509로 보호되는 HTTPS 요청의 경우 관련 클라이언트 인증서와 서버 인증서 지문을 만듭니다. 클라이언트 인증서의 일반 이름은 ClientAuthAllowedCommonNames 또는 AdminAllowedCommonNames에서 지정됩니다.

X.509로 보호되는 HTTP 엔드포인트의 경우에는 REST API가 변경되지 않습니다. REST 호출의 URL, HTTP 헤더, 요청 및 응답 본문은 변경되지 않습니다.

Kerberos 또는 NTLM 보안을 사용하는 Http 게이트웨이

온-프레미스에서 Service Fabric 클러스터는 Kerberos 및 NTLM을 사용하여 사용자 및 관리 클라이언트를 인증하고 권한을 부여하고 서버(Service Fabric 노드)를 인증할 수 있습니다. 그러나 Kerberos 또는 NTLM을 사용하여 메시지를 암호화할 수는 없습니다.

참고

Kerberos 사용 시에는 HTTPS를 사용하는 것이 좋으며 클러스터 매니페스트에 서버 인증서가 포함되는지를 확인하는 것이 좋습니다.

Kerberos 보안을 사용하는 고객의 경우에는 HTTPS도 사용하는 것이 좋습니다. 즉, 클러스터에 X.509 서버 인증서가 있어야 합니다. 이러한 방식으로 서버 인증서를 사용하여 통신을 암호화합니다.

클라이언트에 대해 X.509 인증서가 아닌 Kerberos 인증서를 사용하는 경우의 가장 큰 이점은 Kerberos 사용 시 클라이언트 인증서를 쉽게 관리할 수 있다는 것입니다.

Service Fabric을 사용하면 클라이언트가 Kerberos 대신 NTLM을 통해 인증될 수 있습니다. 그러나 NTLM은 사용하지 않는 것이 좋습니다. 자세한 내용은 구현자에 대한 보안 고려 사항을 참조하세요.

가능한 경우에는 항상 NTLM이 아닌 Kerberos를 사용하세요.

클러스터 매니페스트 변경

이 섹션에서는 클라이언트 인증에 Kerberos를 사용하고 서버 인증 및 암호화에 X.509 인증서를 사용하도록 클러스터 매니페스트를 이미 구성했다고 가정합니다. 자세한 내용은 Windows 보안 사용하여 클러스터 보안을 참조하세요.

REST API와 Kerberos를 함께 사용하는 방법

REST API를 사용하여 Kerberos 지원 클러스터와 통신할 때는 REST API가 변경되지 않습니다. REST 호출의 URL, HTTP 헤더, 요청 및 응답 본문은 변경되지 않습니다.

그러나 표준 Kerberos 및 NTLM HTTP 인증 프로세스를 따라야 합니다.

다음 사항에 유의하세요.

  • 대부분의 HTTP 클라이언트는 자동으로 이 프로세스를 따릅니다.

  • 서버가 Kerberos/NTLM으로 보호되는 것으로 알려진 경우 다음 프로세스의 3단계에서 시작할 수 있습니다. 이렇게 하면 하나의 네트워크 홉이 제거됩니다.

REST를 사용하는 Kerberos 인증 프로세스

다음은 REST를 사용하는 Kerberos 인증 프로세스의 예제 시퀀스입니다.

  1. 추가 HTTP 헤더를 포함하지 않고 REST API를 호출합니다.

    GET http://localhost:19007/Nodes?api-version=6.0 HTTP/1.1  
    User-Agent: Fiddler  
    Host: localhost:19007  
    
    
  2. Kerberos 지원 클러스터가 401 권한 없음으로 응답하고 www-authenticate 헤더를 "Negotiate"로 설정합니다.

    HTTP/1.1 401 Unauthorized  
    Server: Microsoft-HTTPAPI/2.0  
    WWW-Authenticate: Negotiate  
    Date: Thu, 09 Jan 2014 08:20:55 GMT  
    Content-Length: 0  
    
    
  3. 이제 클라이언트가 서비스 SPN을 사용하여 AD에 페더레이션 방식 또는 상호 방식으로 연결해 토큰을 가져와야 합니다.

    서비스의 SPN은 연결 중인 Service Fabric 노드의 HTTP\FQDN입니다."

  4. AD에서 반환된 토큰은 권한 부여 헤더에서 "협상 <토큰>" 형식으로 사용해야 합니다.

    GET http://localhost:19007/Nodes?api-version=6.0 HTTP/1.1  
    User-Agent: Fiddler  
    Host: localhost:19007  
    Authorization: Negotiate YH8GBisG<…>CSqGSIb3EgECAgYKKwYBBAGCNwICHqI/BD1OVE<…>RNT05E  
    
    
  5. 서버가 토큰을 인증하며 클라이언트는 작업을 완료할 권한이 있으면 요청 실행을 시작합니다.

    HTTP/1.1 200 OK  
    Content-Type: application/json; charset=utf-8  
    Server: Microsoft-HTTPAPI/2.0  
    Date: Thu, 09 Jan 2014 08:38:43 GMT  
    Content-Length: 1457  
    
    [{"Name":"Node4","IpAddressOrFQDN":"localhost","Type":"NodeType04","CodeVersion":"2.0.283.0","ConfigVersion":"1.0","NodeStatus":1,"NodeUpTimeInSeconds":"4335",NodeDownTimeInSeconds":"0","HealthState":1,"IsSeedNode":false,"UpgradeDomain":"MYUD1","FaultDomain":"fd:\/RACK2","Id":{"Id":"b5bd41bc26a079f4df3791b2b5d42e5"}},{"Name":"Node1","IpAddressOrFQDN":"localhost","Type":"NodeType01","CodeVersion":"2.0.283.0","ConfigVersion":"1.0","NodeStatus":1,"NodeUpTimeInSeconds":"4335",NodeDownTimeInSeconds":"0","HealthState":1,"IsSeedNode":true,"UpgradeDomain":"MYUD1","FaultDomain":"fd:\/RACK1","Id":{"Id":"10152272d1e44a94356a41d96dc9b466"}},{"Name":"Node2","IpAddressOrFQDN":"localhost","Type":"NodeType02","CodeVersion":"2.0.283.0","ConfigVersion":"1.0","NodeStatus":1,"NodeUpTimeInSeconds":"4335",NodeDownTimeInSeconds":"0","HealthState":1,"IsSeedNode":true,"UpgradeDomain":"MYUD2","FaultDomain":"fd:\/RACK2","Id":{"Id":"15091e9851978afe10f2f3ab37c1d2f0"}},{"Name":"Node5","IpAddressOrFQDN":"localhost","Type":"NodeType05","CodeVersion":"2.0.283.0","ConfigVersion":"1.0","NodeStatus":1,"NodeUpTimeInSeconds":"4335",NodeDownTimeInSeconds":"0","HealthState":1,"IsSeedNode":false,"UpgradeDomain":"MYUD2","FaultDomain":"fd:\/RACK1","Id":{"Id":"6e48b9c722325a66f805e2890bb7dd30"}},{"Name":"Node3","IpAddressOrFQDN":"localhost","Type":"NodeType03","CodeVersion":"2.0.283.0","ConfigVersion":"1.0","NodeStatus":1,"NodeUpTimeInSeconds":"4335",NodeDownTimeInSeconds":"0","HealthState":1,"IsSeedNode":true,"UpgradeDomain":"MYUD3","FaultDomain":"fd:\/RACK1","Id":{"Id":"880f1f5072c2c4805e9cb15ec710d083"}}]