Kibana에 대한 SAML 인증 - Amazon Elasticsearch Service

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Kibana에 대한 SAML 인증

Kibana에 대한 SAML 인증을 사용하면 기존 자격 증명 공급자를 사용하여 Elasticsearch 6.7 이상을 실행하는 도메인에서 Kibana에 대한 Single Sign-On(SSO)을 제공할 수 있습니다. 이 기능을 사용하려면 세분화된 액세스 제어를 활성화해야 합니다.

Amazon Cognito 또는 내부 사용자 데이터베이스를 통해 인증하는 대신, Kibana에 대한 SAML 인증을 사용하면 타사 자격 증명 공급자를 사용하여 Kibana에 로그인하고, 세분화된 액세스 제어를 관리하고, 데이터를 검색하고, 시각화를 빌드할 수 있습니다. 는 Okta, Keycloak, Active Directory Federation Services 및 Auth0과 같은 SAML 2.0 표준을 사용하는 공급자를 지원합니다.Amazon Elasticsearch Service

Kibana에 대한 SAML 인증은 웹 브라우저를 통해서만 Kibana에 액세스하기 위한 것입니다. SAML 자격 증명을 사용하여 또는 Kibana 에 직접 HTTP 요청을 할 수 Elasticsearch없습니다APIs.

SAML 구성 개요

이 페이지에서는 사용자가 기존 자격 증명 공급자를 가지고 있고 이에 대해 어느 정도 잘 알고 있다고 가정합니다. AWS는 정확한 공급자에 대한 자세한 구성 단계를 제공할 수 없으며 Amazon ES 도메인에 대한 단계만 제공할 수 있습니다.

Kibana 로그인 흐름은 다음 두 가지 형식 중 하나를 취할 수 있습니다.

  • 시작된 서비스 공급자(SP): Kibana(예: https://my-domain.us-east-1.es.amazonaws.com/_plugin/kibana)로 이동하여 로그인 화면으로 리디렉션합니다. 로그인하면 자격 증명 공급자가 Kibana로 리디렉션합니다.

  • 시작된 자격 증명 공급자(IdP): 자격 증명 공급자로 이동하여 로그인한 다음 애플리케이션 디렉터리에서 Kibana를 선택합니다.

Amazon ES는 SP가 시작한 URLs와 IdP가 시작된 두 개의 Single Sign-On을 제공하지만, 원하는 Kibana 로그인 흐름과 일치하는 로그인 흐름만 있으면 됩니다.

어느 경우든 목표는 자격 증명 공급자를 통해 로그인하여 사용자 이름(필수)과 백엔드 역할(선택 사항이지만 권장됨)이 포함된 SAML 어설션을 받는 것입니다. 이 정보를 사용하면 세분화된 액세스 제어가 SAML 사용자에게 권한을 할당할 수 있습니다. 외부 자격 증명 공급자에서는 일반적으로 백엔드 역할을 "역할" 또는 "그룹"이라고 합니다.

참고

SSO URL을 변경할 수 없으므로 Kibana에 대한 SAML 인증은 프록시 서버를 지원하지 않습니다.

SAML 인증 활성화

새 도메인이 생성되지 않은 기존 도메인에서만 Kibana에 대한 SAML 인증을 활성화할 수 있습니다. 메타데이터 파일의 크기 때문에 AWS 콘솔을 사용하는 것이 좋습니다.IdP

작은 정보

도메인은 한 번에 하나의 Kibana 인증 방법만 지원합니다. Kibana에 대한 Amazon Cognito 인증을 활성화한 경우 SAML을 활성화하려면 비활성화해야 합니다.

Kibana에 대해 SAML 인증을 활성화하려면(콘솔)

  1. 도메인, 작업인증 수정을 선택합니다.

  2. SAML 인증 활성화를 선택합니다.

  3. 서비스 공급자 개체 ID와 두 개의 SSO URLs를 적어 둡니다. SSO URLs 중 하나만 필요합니다. 지침은 SAML 구성 개요 단원을 참조하십시오.

    작은 정보

    나중에 도메인에 대해 URLs사용자 지정 엔드포인트를 활성화할 경우 이러한 가 변경됩니다. 이러한 경우 IdP를 업데이트해야 합니다.

  4. 이러한 값을 사용하여 자격 증명 공급자를 구성합니다. 이것은 프로세스의 가장 복잡한 부분이며, 안타깝게도 공급자마다 용어와 단계가 크게 다릅니다. 공급자의 설명서를 참조하십시오.

    Okta에서 예를 들어 “SAML 2.0 웹 애플리케이션”을 생성합니다. Single sign on URL에 3단계에서 선택한 SSO URL을 지정합니다. Audience URI (SP Entity ID)(대상 URI(SP 개체 ID))에서 SP 개체 ID를 지정합니다.

    Okta에는 사용자 및 백엔드 역할 대신 사용자 및 그룹이 있습니다. 그룹 속성 문의 경우 이름role 필드에 를 추가하고 필터.+ 필드에 정규식 을 추가하는 것이 좋습니다. 이 문은 사용자가 인증한 후 SAML 어설션의 role 필드에 모든 사용자 그룹을 포함하도록 Okta 자격 증명 공급자에게 지시합니다.

    Auth0에서 "일반 웹 애플리케이션"을 생성한 다음 SAML 2.0 추가 기능을 활성화합니다. Keycloak에서 “클라이언트”를 생성합니다.

  5. 자격 증명 공급자를 구성하면 IdP 메타데이터 파일이 생성됩니다. 이 XML 파일에는 TLS 인증서, Single Sign-On 엔드포인트 및 자격 증명 공급자의 엔터티 ID와 같은 공급자에 대한 정보가 포함되어 있습니다.

    메타데이터 파일의 내용을 복사하여 AWS 콘솔의 IdPMetadata from IDP(IDP의 데이터) 필드에 붙여 넣습니다. 또는 Import from XML file(XML 파일에서 가져오기) 버튼을 사용하여 메타데이터 파일을 업로드합니다. 메타데이터 파일은 다음과 같아야 합니다.

    <?xml version="1.0" encoding="UTF-8"?> <md:EntityDescriptor entityID="entity-id" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"> <md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <md:KeyDescriptor use="signing"> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:X509Data> <ds:X509Certificate>tls-certificate</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </md:KeyDescriptor> <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat> <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="idp-sso-url"/> <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="idp-sso-url"/> </md:IDPSSODescriptor> </md:EntityDescriptor>
  6. 속성의 내용을 복사하여 메타데이터 파일에서 AWS 콘솔의 entityIDIDP 개체 ID 필드에 붙여 넣습니다. 또한 많은 자격 증명 공급자가 이 값을 사후 구성 요약의 일부로 표시합니다. 일부 공급자는 이를 "발급자"라고 합니다.

  7. SAML 마스터 사용자 이름 및/또는 SAML 마스터 백엔드 역할을 제공합니다. 이 사용자 이름 및/또는 백엔드 역할은 새 마스터 사용자와 동일한 클러스터에 대한 전체 권한을 받지만 Kibana 내에서만 해당 권한을 사용할 수 있습니다.

    예를 들어 Okta에서 jdoe 그룹에 속한 사용자 admins가 있을 수 있습니다. SAML 마스터 사용자 이름jdoe 필드에 를 추가하면 해당 사용자만 모든 권한을 받게 됩니다. SAML 마스터 백엔드 역할admins 필드에 을 추가하면 그룹에 속한 모든 사용자에게 모든 권한이 부여됩니다.admins

    SAML 어설션의 내용은 SAML 마스터 사용자 이름 및/또는 SAML 마스터 역할에 사용하는 문자열과 정확히 일치해야 합니다. 일부 자격 증명 공급자는 사용자 이름 앞에 접두사를 추가하여 진단하기 어려운 불일치를 일으킬 수 있습니다. 자격 증명 공급자 사용자 인터페이스에 jdoe가 표시될 수 있지만 SAML 어설션에 auth0|jdoe가 포함될 수 있습니다. 항상 SAML 어설션의 문자열을 사용합니다.

    많은 자격 증명 공급자를 통해 구성 프로세스 중에 샘플 어설션을 볼 수 있으며, SAML-tracer와 같은 도구를 사용하면 실제 어설션의 콘텐츠를 검사하고 문제를 해결할 수 있습니다. 어설션은 다음과 같습니다.

    <?xml version="1.0" encoding="UTF-8"?> <saml2:Assertion ID="id67229299299259351343340162" IssueInstant="2020-09-22T22:03:08.633Z" Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"> <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">idp-issuer</saml2:Issuer> <saml2:Subject> <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">username</saml2:NameID> <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml2:SubjectConfirmationData NotOnOrAfter="2020-09-22T22:08:08.816Z" Recipient="domain-endpoint/_plugin/kibana/_opendistro/_security/saml/acs"/> </saml2:SubjectConfirmation> </saml2:Subject> <saml2:Conditions NotBefore="2020-09-22T21:58:08.816Z" NotOnOrAfter="2020-09-22T22:08:08.816Z"> <saml2:AudienceRestriction> <saml2:Audience>domain-endpoint</saml2:Audience> </saml2:AudienceRestriction> </saml2:Conditions> <saml2:AuthnStatement AuthnInstant="2020-09-22T19:54:37.274Z"> <saml2:AuthnContext> <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef> </saml2:AuthnContext> </saml2:AuthnStatement> <saml2:AttributeStatement> <saml2:Attribute Name="role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">GroupName Match Matches regex ".+" (case-sensitive) </saml2:AttributeValue> </saml2:Attribute> </saml2:AttributeStatement> </saml2:Assertion>
  8. Optional SAML settings(SAML 설정(선택 사항)) 섹션을 확장합니다.

  9. 사용자 이름에 대해 SAML 어설션의 요소를 사용하려면 Subject key(제목 키)NameID 필드를 비워 둡니다. 어설션에서 이 표준 요소를 사용하지 않고 대신 사용자 이름을 사용자 지정 속성으로 포함하는 경우 여기에 해당 속성을 지정합니다.

    백엔드 역할을 사용하려는 경우(권장), 또는 와 같은 role역할 키group 필드의 어설션에서 속성을 지정합니다. 이는 SAML-tracer와 같은 도구가 도움이 될 수 있는 또 다른 상황입니다.

  10. 기본적으로 Kibana는 60분 후에 사용자를 로그아웃합니다. Session time to live 필드를 사용하여 이 값을 최대 1,440(24시간)개까지 늘릴 수 있습니다.

  11. 제출을 선택합니다. 도메인은 Kibana를 사용할 수 없는 약 1분 동안 처리 상태로 전환됩니다.

  12. 도메인이 처리를 마치면 Kibana를 엽니다.

    • SP에서 시작한 URL을 선택한 경우 domain-endpoint/_plugin/kibana/로 이동합니다.

    • 에서 시작한 URL을 선택한 경우 자격 증명 공급자의 애플리케이션 디렉터리로 이동합니다.IdP

    두 경우 모두 SAML 마스터 사용자 또는 SAML 마스터 백엔드 역할에 속한 사용자로 로그인합니다. 7단계의 예제를 계속하려면 jdoe 또는 admins 그룹의 멤버로 로그인합니다.

  13. Kibana가 로드되면 보안역할을 선택합니다.

  14. 다른 사용자가 Kibana에 액세스하도록 허용하는 역할 매핑.

    예를 들어 신뢰할 수 있는 동료 jroeall_accesssecurity_manager 역할에 매핑할 수 있습니다. 백엔드 역할 analystsreadallkibana_user 역할에 매핑할 수도 있습니다.

    Kibana가 아닌 API를 사용하려면 다음 샘플 요청을 참조하십시오.

    PATCH _opendistro/_security/api/rolesmapping [ { "op": "add", "path": "/security_manager", "value": { "users": ["master-user", "jdoe", "jroe"], "backend_roles": ["admins"] } }, { "op": "add", "path": "/all_access", "value": { "users": ["master-user", "jdoe", "jroe"], "backend_roles": ["admins"] } }, { "op": "add", "path": "/readall", "value": { "backend_roles": ["analysts"] } }, { "op": "add", "path": "/kibanauser", "value": { "backend_roles": ["analysts"] } } ]

CLI 명령 예

다음 AWS CLI 명령은 기존 도메인에서 Kibana에 대한 SAML 인증을 활성화합니다.

aws es update-elasticsearch-domain-config \ --domain-name my-domain \ --advanced-security-options '{"SAMLOptions":{"Enabled":true,"MasterUserName":"my-idp-user","MasterBackendRole":"my-idp-group-or-role","Idp":{"EntityId":"entity-id","MetadataContent":"metadata-content-with-quotes-escaped"},"RolesKey":"optional-roles-key","SessionTimeoutMinutes":180,"SubjectKey":"optional-subject-key"}}'

메타데이터 XML에서 모든 따옴표와 줄 바꿈 문자를 이스케이프해야 합니다. 예를 들어 <KeyDescriptor use=\"signing\">\n 대신 <KeyDescriptor use="signing">를 사용하고 줄 바꿈을 사용합니다. 사용에 대한 자세한 내용은 AWS CLI 단원을 참조하십시오.AWS CLI Command Reference

샘플 구성 API 요청

구성 API에 대한 다음 요청은 기존 도메인에서 Kibana에 대한 SAML 인증을 활성화합니다.

POST https://es.us-east-1.amazonaws.com/2015-01-01/es/domain/my-domain/config { "AdvancedSecurityOptions": { "SAMLOptions": { "Enabled": true, "MasterUserName": "my-idp-user", "MasterBackendRole": "my-idp-group-or-role", "Idp": { "EntityId": "entity-id", "MetadataContent": "metadata-content-with-quotes-escaped" }, "RolesKey": "optional-roles-key", "SessionTimeoutMinutes": 180, "SubjectKey": "optional-subject-key" } } }

메타데이터 XML에서 모든 따옴표와 줄 바꿈 문자를 이스케이프해야 합니다. 예를 들어 <KeyDescriptor use=\"signing\">\n 대신 <KeyDescriptor use="signing">를 사용하고 줄 바꿈을 사용합니다. 구성 API 사용에 대한 자세한 내용은 Amazon Elasticsearch Service 구성 API 참조 단원을 참조하십시오.

SAML 문제 해결

오류 세부 정보

Your request: '/some/path' is not allowed.

자격 증명 공급자에게 올바른 SSO URL(3단계)을 제공했는지 확인합니다.

Please provide valid identity provider metadata document to enable SAML.

메타데이터 파일이 SAML 2.0 표준을 준수하지 않습니다.IdP 검증 도구를 사용하여 오류를 확인합니다.

SAML 구성 옵션은 콘솔에 표시되지 않습니다.

최신 서비스 소프트웨어로 업데이트합니다.

SAML configuration error: Something went wrong while retrieving the SAML configuration, please check your settings.

이 일반 오류는 여러 가지 이유로 발생할 수 있습니다.

  • 자격 증명 공급자에게 올바른 SP 개체 ID와 SSO URL을 제공했는지 확인합니다.

  • 메타데이터 파일을 재생성하고 IdP 개체 ID를 확인합니다.IdP AWS 콘솔에서 업데이트된 메타데이터를 추가합니다.

  • 도메인 액세스 정책이 Kibana 및 _opendistro/_security/*에 대한 액세스를 허용하는지 확인합니다. 일반적으로 세분화된 액세스 제어를 사용하는 도메인의 경우 오픈 액세스 정책을 사용하는 것이 좋습니다.

  • SAML 구성 단계는 자격 증명 공급자의 설명서를 참조하십시오.

Missing role: No roles available for this user, please contact your system administrator.

성공적으로 인증했지만 SAML 어설션의 사용자 이름 및 백엔드 역할이 역할에 매핑되지 않으므로 권한이 없습니다. 이러한 매핑은 대/소문자를 구분합니다.

SAML-tracer와 같은 도구와 다음 호출을 사용하는 역할 매핑을 사용하여 SAML 어설션의 내용을 확인합니다.

GET _opendistro/_security/api/rolesmapping

Kibana에 액세스하려고 하면 브라우저가 HTTP 500 오류를 계속 리디렉션하거나 수신합니다.

이러한 오류는 SAML 어설션에 총 1,500자 정도로 많은 수의 역할이 포함된 경우 발생할 수 있습니다. 예를 들어 평균 길이가 20자인 80개의 역할을 전달하는 경우 웹 브라우저의 쿠키 크기 제한을 초과할 수 있습니다.

SAML 인증 비활성화

Kibana에 대한 SAML 인증을 비활성화하려면(콘솔)

  1. 도메인, 작업인증 수정을 선택합니다.

  2. SAML 인증 활성화를 선택 취소합니다.

  3. 제출을 선택합니다.

  4. 도메인이 처리를 마치면 다음 호출을 사용하여 세분화된 액세스 제어 역할 매핑을 확인합니다.

    GET _opendistro/_security/api/rolesmapping

    Kibana에 대한 SAML 인증을 비활성화하면 SAML 마스터 사용자 이름 및/또는 SAML 마스터 백엔드 역할에 대한 매핑이 제거되지 않습니다. 이러한 매핑을 제거하려면 내부 사용자 데이터베이스(활성화된 경우)를 사용하여 Kibana에 로그인하거나 API를 사용하여 이러한 매핑을 제거합니다.

    PUT _opendistro/_security/api/rolesmapping/all_access { "users": [ "master-user" ] }