Đơn giản hóa việc xác thực bằng tích hợp LDAP gốc trên Amazon EMR | Dịch vụ web của Amazon

Nhiều công ty có danh tính công ty được lưu trữ bên trong các nhà cung cấp danh tính (IdP) như active Directory (AD) hoặc OpenLDAP. Trước đây, khách hàng sử dụng Amazon EMR có thể tích hợp các cụm của họ với Active Directory bằng cách định cấu hình vùng tin cậy một chiều giữa miền AD của họ và vùng Kerberos của cụm EMR. Để biết thêm chi tiết, hãy tham khảo Hướng dẫn: Định cấu hình ủy thác đa lĩnh vực với miền Active Directory.

Thiết lập này là yếu tố hỗ trợ quan trọng giúp người dùng và nhóm doanh nghiệp có sẵn trong các cụm EMR và xác định các chính sách kiểm soát quyền truy cập để kiểm soát quyền truy cập dữ liệu của họ (ví dụ: thông qua Tích hợp Apache Ranger gốc của Amazon EMR).

Mặc dù tùy chọn này vẫn có sẵn nhưng Amazon EMR đã phát hành hỗ trợ xác thực LDAP gốc, một tính năng bảo mật mới giúp đơn giản hóa việc tích hợp với OpenLDAP và Active Directory.

Tính năng này cho phép những điều sau:

tự động cấu hình bảo mật cho các ứng dụng được hỗ trợ (HiveServer2, Trino, Presto và Livy) để sử dụng giao thức Kerberos dưới lớp vỏ bọc và LDAP làm xác thực bên ngoài. Điều này cho phép tích hợp đơn giản hơn từ các công cụ bên ngoài, để kết nối với các điểm cuối của cụm, không còn phải thiết lập xác thực kerberos mà thay vào đó, có thể được cấu hình đơn giản để cung cấp tên người dùng và mật khẩu LDAP
kiểm soát truy cập chi tiết (FGAC) đối với những người có thể truy cập cụm EMR của bạn thông qua SSH
các chính sách ủy quyền chi tiết trên cơ sở dữ liệu và bảng Hive Metastore nếu được sử dụng kết hợp với tích hợp Amazon EMR Apache Ranger gốc.

Trong bài đăng này, chúng tôi đi sâu vào xác thực LDAP của Amazon EMR, cho biết cách hoạt động của quy trình xác thực, cách truy xuất và kiểm tra các cấu hình LDAP cần thiết cũng như cách xác nhận cụm EMR được tích hợp LDAP đúng cách.

Sử dụng thông tin trên blog này:

Các nhóm quản lý cụm EMR có thể tăng cường phối hợp với quản trị viên LDAP IdP của họ để yêu cầu thông tin chính xác và thực hiện đúng cách các thử nghiệm định cấu hình trước
Người dùng cuối cụm EMR có thể hiểu việc kết nối từ các công cụ bên ngoài đến cụm EMR hỗ trợ LDAP đơn giản như thế nào so với xác thực dựa trên Kerberos trước đó

Cách tích hợp LDAP của Amazon EMR hoạt động

Khi nói về xác thực trong bối cảnh khung EMR, chúng ta có thể phân biệt giữa hai cấp độ:

Xác thực bên ngoài – Được sử dụng bởi người dùng và các thành phần bên ngoài để tương tác với các khung đã cài đặt
Xác thực nội bộ – Được sử dụng trong các khuôn khổ để xác thực thông tin liên lạc của các thành phần nội bộ

Với tính năng mới này, xác thực khung nội bộ vẫn được quản lý thông qua Kerberos, nhưng điều này minh bạch đối với người dùng cuối hoặc các dịch vụ bên ngoài, mặt khác, sử dụng tên người dùng và mật khẩu để xác thực.

Các khung được cài đặt EMR được hỗ trợ triển khai phương thức xác thực dựa trên LDAP, được cung cấp một tập hợp thông tin xác thực tên người dùng và mật khẩu, xác thực chúng dựa trên điểm cuối LDAP và trong trường hợp thành công, sẽ cho phép sử dụng khung.

Sơ đồ sau đây tóm tắt cách hoạt động của luồng xác thực.

Quy trình làm việc bao gồm các bước sau:

Người dùng kết nối với một trong các điểm cuối được hỗ trợ (chẳng hạn như HiveServer2, Điều phối viên Trino/Presto hoặc Hue WebUI) và cung cấp thông tin xác thực công ty của họ (tên người dùng và mật khẩu).
Khung được liên hệ sử dụng trình xác thực tùy chỉnh để thực hiện xác thực bằng dịch vụ Đại lý bí mật EMR chạy bên trong các phiên bản cụm.
Dịch vụ Đại lý bí mật EMR xác thực thông tin xác thực được cung cấp dựa trên điểm cuối LDAP.
Trong trường hợp thành công, điều sau đây xảy ra:
- Hiệu trưởng Kerberos được tạo cho người dùng cụ thể trên cụm Trung tâm phân phối khóa MIT (MIT KDC) chạy bên trong nút chính.
- Keytab chính Kerberos được tạo bên trong thư mục chính của người dùng trên nút chính.

Sau khi xác thực hoàn tất, người dùng có thể bắt đầu sử dụng khung.

Bên trong tất cả các phiên bản cụm, dịch vụ SSSD được định cấu hình để truy xuất người dùng và nhóm từ điểm cuối LDAP và cung cấp chúng với tư cách là người dùng hệ thống.

Luồng xác thực khi kết nối với SSH hơi khác một chút và được tóm tắt trong sơ đồ sau.

Quy trình làm việc bao gồm các bước sau:

Người dùng kết nối SSH với phiên bản chính EMR, cung cấp thông tin xác thực của công ty (tên người dùng và mật khẩu).
Dịch vụ SSHD đã liên hệ sẽ sử dụng dịch vụ SSSD để xác thực thông tin xác thực được cung cấp.
Dịch vụ SSSD xác thực thông tin xác thực được cung cấp dựa trên điểm cuối LDAP. Trong trường hợp thành công, người dùng sẽ đến thư mục chính có liên quan. Tại thời điểm này, người dùng có thể sử dụng các CLI khác nhau (beeline, trino-cli, presto-cli, curl) để truy cập Hive, Trino/Presto hoặc Livy.
Để sử dụng Spark CLI (spark-submit, pyspark, spark-shell), người dùng phải gọi ldap-kinit script và cung cấp tên người dùng và mật khẩu được yêu cầu.
Việc xác thực được thực hiện bằng cách sử dụng dịch vụ EMR Secret Agent chạy bên trong các phiên bản cụm.
Dịch vụ Đại lý bí mật EMR xác thực thông tin xác thực được cung cấp dựa trên điểm cuối LDAP.
Trong trường hợp thành công, điều sau đây xảy ra:
- Hiệu trưởng Kerberos được tạo cho người dùng cụ thể trên cụm MIT KDC chạy bên trong nút chính.
- Keytab chính Kerberos được tạo bên trong thư mục chính của người dùng trên nút chính.
- Một vé kerberos được lấy và lưu trữ trên bộ đệm vé Kerberos của người dùng trên nút chính.

Sau ldap-kinit tập lệnh hoàn tất, người dùng có thể bắt đầu sử dụng Spark CLI.

Trong các phần sau, chúng tôi sẽ trình bày cách truy xuất các giá trị cài đặt LDAP cần thiết cũng như tìm hiểu cách khởi chạy một cụm bằng xác thực LDAP EMR và kiểm tra nó.

Tìm thông số LDAP thích hợp

Để định cấu hình xác thực LDAP cho Amazon EMR, bước đầu tiên là truy xuất thuộc tính LDAP dùng để thiết lập cụm của bạn. Bạn cần những thông tin sau:

Tên DNS của máy chủ LDAP
Chứng chỉ ở định dạng PEM được sử dụng để tương tác qua LDAP an toàn (LDAPS) với điểm cuối LDAP
Cơ sở tìm kiếm người dùng LDAP, là một đường dẫn (hoặc nhánh) trên cây LDAP từ nơi tìm kiếm người dùng (chỉ những người dùng thuộc nhánh này mới được truy xuất)
Cơ sở tìm kiếm nhóm LDAP, là đường dẫn (hoặc nhánh) trên cây LDAP từ nơi tìm kiếm nhóm (chỉ các nhóm thuộc nhánh này mới được truy xuất)
Máy chủ LDAP liên kết thông tin xác thực của người dùng, là tên người dùng và mật khẩu dành cho người dùng dịch vụ (thường được gọi là người dùng liên kết) được sử dụng để kích hoạt các truy vấn LDAP và truy xuất thông tin người dùng như tên người dùng và tư cách thành viên nhóm.

Với Active Directory, quản trị viên AD có thể truy xuất thông tin này trực tiếp từ Active Directory Users and Computers dụng cụ. Khi bạn chọn một người dùng trong công cụ này, bạn có thể thấy các thuộc tính liên quan (ví dụ: distinguishedName). Ảnh chụp màn hình sau đây hiển thị một ví dụ.

Từ ảnh chụp màn hình, chúng ta có thể thấy rằng distinguishedName đối với người dùng thì John là CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=com, có nghĩa là john thuộc các cơ sở tìm kiếm sau, được sắp xếp từ hẹp nhất đến rộng nhất:

OU=users,OU=italy,OU=emr,DC=awsemr,DC=com
OU=italy,OU=emr,DC=awsemr,DC=com
OU=emr,DC=awsemr,DC=com
DC=awsemr,DC=com

Tùy thuộc vào số lượng mục trong thư mục LDAP của công ty, việc sử dụng cơ sở tìm kiếm rộng có thể dẫn đến thời gian truy xuất và thời gian chờ lâu. Đó là một cách tốt để định cấu hình cơ sở tìm kiếm càng hẹp càng tốt để bao gồm tất cả những người dùng cần thiết. Trong ví dụ trước, OU=users,OU=italy,OU=emr,DC=awsemr,DC=com có thể là cơ sở tìm kiếm tốt nếu tất cả người dùng bạn muốn cấp quyền truy cập vào cụm EMR đều là một phần của Đơn vị tổ chức đó.

Một cách khác để truy xuất thuộc tính người dùng là sử dụng ldapsearch dụng cụ. Bạn có thể sử dụng phương pháp này cho Active Directory cũng như OpenLDAP và việc kiểm tra khả năng kết nối với điểm cuối LDAP là cực kỳ hữu ích.

Sau đây là ví dụ với Active Directory (OpenLDAP cũng tương tự).

Điểm cuối LDAP phải có thể phân giải và truy cập được bằng cách Đám mây điện toán đàn hồi Amazon (Amazon EC2) Phiên bản cụm EMR qua TCP trên cổng 636. Bạn nên chạy thử nghiệm từ phiên bản Amazon Linux 2 EC2 thuộc cùng mạng con với cụm EMR và có cùng nhóm bảo mật EMR được liên kết với phiên bản cụm EMR.

Sau khi bạn khởi chạy phiên bản EC2, hãy cài đặt nc công cụ và kiểm tra độ phân giải và kết nối DNS. Giả sử rằng DC1.awsemr.com là tên DNS cho điểm cuối LDAP, hãy chạy các lệnh sau:

sudo yum install nc
nc -vz DC1.awsemr.com 636

Nếu độ phân giải DNS không hoạt động bình thường, bạn sẽ nhận được lỗi như sau:

Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Could not resolve hostname "DC1.awsemr.com": Name or service not known. QUITTING.

Nếu không thể truy cập điểm cuối, bạn sẽ nhận được lỗi như sau:

Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connection timed out.

Trong một trong hai trường hợp này, nhóm mạng và DNS phải tham gia để khắc phục sự cố và giải quyết sự cố.

Trong trường hợp thành công, đầu ra sẽ trông như sau:

Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 10.0.1.235:636.
Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.

Nếu mọi thứ đều hoạt động, hãy tiến hành kiểm tra và cài đặt openldap khách hàng như sau:

sudo yum install openldap-clients

Sau đó chạy ldapsearch các lệnh truy xuất thông tin về người dùng và nhóm từ điểm cuối LDAP. Sau đây là mẫu ldapsearch lệnh:

#Customize these 6 variables
LDAPS_CERTIFICATE=/path/to/ldaps_cert.pem
LDAPS_ENDPOINT=DC1.awsemr.com
BINDUSER="CN=binduser,CN=Users,DC=awsemr,DC=com"
BINDUSER_PASSWORD=binduserpassword
SEARCH_BASE=DC=awsemr,DC=com
USER_TO_SEARCH=john
FILTER=(sAMAccountName=${USER_TO_SEARCH})
INFO_TO_SEARCH="*"

#Search user
LDAPTLS_CACERT=${LDAPS_CERTIFICATE} ldapsearch -LLL -x -H ldaps://${LDAPS_ENDPOINT} -v -D "${BINDUSER}" -w "${BINDUSER_PASSWORD}" -b "${SEARCH_BASE}" "${FILTER}" "${INFO_TO_SEARCH}"

Chúng tôi sử dụng các tham số sau:

-x – Điều này cho phép xác thực đơn giản.
-D – Điều này cho biết người dùng thực hiện tìm kiếm.
-w – Phần này cho biết mật khẩu người dùng.
-H – Phần này cho biết URL của máy chủ LDAP.
-b – Đây là tìm kiếm cơ bản.
LDAPTLS_CACERT – Điều này biểu thị chứng chỉ công khai SSL PEM điểm cuối LDAPS hoặc chứng chỉ công khai SSL PEM của tổ chức phát hành chứng chỉ gốc điểm cuối LDAPS. Điều này có thể được lấy từ người dùng quản trị viên AD hoặc OpenLDAP.

Sau đây là đầu ra mẫu của lệnh trước:

filter: (sAMAccountName=john)
requesting: *
dn: CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: john
givenName: john
distinguishedName: CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=com
instanceType: 4
whenCreated: 20230804094021.0Z
whenChanged: 20230804094021.0Z
displayName: john
uSNCreated: 262459
memberOf: CN=data-engineers,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com
uSNChanged: 262466
name: john
objectGUID:: gTxn8qYvy0SVL+mYAAbb8Q==
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
pwdLastSet: 133356156212864439
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAIKyNe7Dn3azp7Sh+rgQAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: john
sAMAccountType: 805306368
userPrincipalName: john@awsemr.com
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=awsemr,DC=com
dSCorePropagationData: 20230804094021.0Z
dSCorePropagationData: 16010101000000.0Z

Như chúng ta có thể thấy từ đầu ra mẫu, người dùng john được xác định bằng tên phân biệt CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=com, và data-engineers nhóm mà người dùng thuộc về (memberOf value) được xác định bằng tên phân biệt CN=data-engineers,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com.

Chúng tôi có thể chạy ldapsearch truy vấn để truy xuất thông tin người dùng và nhóm bằng cách sử dụng cơ sở tìm kiếm được thu hẹp:

#Customize these 9 variables
LDAPS_CERTIFICATE=/path/to/ldaps_cert.pem
LDAPS_ENDPOINT=DC1.awsemr.com
BINDUSER="CN=binduser,CN=Users,DC=awsemr,DC=com"
BINDUSER_PASSWORD=binduserpassword
SEARCH_BASE=DC=awsemr,DC=com
USER_SEARCH_BASE=OU=users,OU=italy,OU=emr,DC=awsemr,DC=com
GROUPS_SEARCH_BASE=OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com
USER_TO_SEARCH=john
GROUP_TO_SEARCH=data-engineers

#Search User
LDAPTLS_CACERT=${LDAPS_CERTIFICATE} ldapsearch -LLL -x -H ldaps://${LDAPS_ENDPOINT} -v -D "${BINDUSER}" -w "${BINDUSER_PASSWORD}" -b "${USER_SEARCH_BASE}" "(sAMAccountName=${USER_TO_SEARCH})" "*"

#Search Group
LDAPTLS_CACERT=${LDAPS_CERTIFICATE} ldapsearch -LLL -x -H ldaps://${LDAPS_ENDPOINT} -v -D "${BINDUSER}" -w "${BINDUSER_PASSWORD}" -b "${GROUPS_SEARCH_BASE}" "(sAMAccountName=${GROUP_TO_SEARCH})" "*"

Bạn cũng có thể áp dụng các bộ lọc khác trong khi tìm kiếm. Để biết thêm thông tin về cách tạo bộ lọc LDAP, hãy tham khảo Bộ lọc LDAP.

Bằng cách chạy ldapsearch lệnh, bạn có thể kiểm tra kết nối LDAP và thuộc tính LDAP, đồng thời xác định thiết lập cần thiết.

Kiểm tra giải pháp

Sau khi bạn xác minh rằng kết nối với điểm cuối LDAP đang mở và cấu hình LDAP chính xác, hãy tiến hành thiết lập môi trường để khởi chạy cụm hỗ trợ EMR LDAP.

Tạo bí mật AWS Secret Manager

Trước khi tạo cấu hình bảo mật EMR, bạn cần tạo hai Người quản lý bí mật AWS bí mật. Bạn sử dụng những thông tin xác thực này để tương tác với điểm cuối LDAP và truy xuất thông tin chi tiết của người dùng như tên người dùng và tư cách thành viên nhóm.

Trên bảng điều khiển Secrets Manager, chọn Bí mật trong khung điều hướng.
Chọn Lưu trữ một bí mật mới.
Trong Loại bí mật, lựa chọn Loại bí mật khác.
Tạo một bí mật mới chỉ định binduser tên phân biệt là chìa khóa và binduser mật khẩu làm giá trị.
Tạo bí mật thứ hai chỉ định trong văn bản gốc chứng chỉ công khai SSL điểm cuối LDAPS hoặc chứng chỉ công khai của cơ quan cấp chứng chỉ gốc LDAPS.
Chứng chỉ này đáng tin cậy, cho phép liên lạc an toàn giữa cụm EMR và điểm cuối LDAPS.

Tạo cấu hình bảo mật EMR

Hoàn thành các bước sau để tạo cấu hình bảo mật EMR:

Trên bảng điều khiển Amazon EMR, hãy chọn Cấu hình bảo mật Dưới EMR trên EC2 trong khung điều hướng.
Chọn Tạo.
Trong Tên cấu hình bảo mật, nhập tên.
Trong Tùy chọn thiết lập cấu hình bảo mật, lựa chọn Chọn cài đặt tùy chỉnh.
Trong Encryption, lựa chọn Bật tính năng mã hóa khi chuyển tiếp.
Trong Loại nhà cung cấp chứng chỉlựa chọn PEM.
Trong Chọn vị trí chứng chỉ PEM, hãy nhập gói PEM nằm trong Dịch vụ lưu trữ đơn giản của Amazon (Amazon S3) hoặc nhà cung cấp chứng chỉ tùy chỉnh Java.
Lưu ý rằng mã hóa khi truyền là bắt buộc để sử dụng tính năng xác thực LDAP. Để biết thêm thông tin về mã hóa khi chuyển tiếp, hãy tham khảo Cung cấp chứng chỉ mã hóa dữ liệu khi truyền bằng mã hóa Amazon EMR.
Chọn Sau.
Chọn LDAP cho Giao thức xác thực.
Trong Vị trí máy chủ LDAP, nhập điểm cuối LDAPS (ldaps://<ldap_endpoint_DNS_name>).
Trong Chứng chỉ SSL LDAP, hãy nhập bí mật thứ hai mà bạn đã tạo trong Trình quản lý bí mật.
Trong Bộ lọc truy cập LDAP, hãy nhập bộ lọc LDAP được áp dụng để hạn chế quyền truy cập vào một nhóm nhỏ người dùng được truy xuất từ cơ sở tìm kiếm người dùng LDAP. Nếu để trống trường này thì sẽ không có bộ lọc nào được áp dụng và tất cả người dùng thuộc cơ sở tìm kiếm người dùng LDAP có thể truy cập vào các điểm cuối được bảo vệ bởi EMR LDAP bằng thông tin xác thực công ty của họ. Sau đây là các bộ lọc mẫu và chức năng của chúng:
- (objectClass=người) – Lọc người dùng bằng thuộc tính objectClass thiết lập như person
- (memberOf=CN=admins,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com) – Lọc người dùng thuộc về admins nhóm
- (|(memberof=CN=data-engineers,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com)(memberof=CN=admins,OU=groups,OU=italy,OU=emr, DC=awsemr,DC=com)) – Lọc người dùng thuộc một trong hai data-engineers hoặc là admins nhóm (mà chúng tôi sử dụng cho bài viết này)
Nhập giá trị cho Cơ sở tìm kiếm người dùng LDAP và Cơ sở tìm kiếm nhóm LDAP. Lưu ý rằng hai cơ sở tìm kiếm không hỗ trợ các bộ lọc nội tuyến (ví dụ: cơ sở sau không được hỗ trợ: OU=users,OU=italy,OU=emr,DC=awsemr,DC=com?subtree?(|(memberof=CN=data-engineers,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com)(memberof=CN=admins,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com))).
Chọn Bật đăng nhập SSH. Điều này chỉ cần thiết nếu bạn muốn người dùng LDAP của mình có thể SSH bên trong các phiên bản cụm bằng thông tin xác thực công ty của họ. Nếu đăng nhập SSH được bật thì cần có bộ lọc truy cập LDAP—nếu không, xác thực SSH sẽ không thành công.
Trong Thông tin xác thực liên kết máy chủ LDAP, hãy nhập bí mật đầu tiên bạn đã tạo trong Trình quản lý bí mật.
Trong tạp chí cho phép phần này, hãy giữ nguyên các giá trị mặc định được chọn:
- Trong Vai trò IAM cho các ứng dụng, lựa chọn Hồ sơ cá thể.
- Trong Phương pháp kiểm soát truy cập chi tiết, lựa chọn Không áp dụng.
Chọn Sau.
Xem lại tóm tắt cấu hình và chọn Tạo.

Khởi chạy cụm EMR

Bạn có thể khởi chạy cụm EMR bằng cách sử dụng Bảng điều khiển quản lý AWS, Các Giao diện dòng lệnh AWS (AWS CLI) hoặc bất kỳ SDK AWS.

Khi bạn tạo EMR trên cụm EC2, hãy đảm bảo chỉ định các cấu hình sau:

Phiên bản EMR – Sử dụng Amazon EMR 6.12.0 trở lên.
Ứng dụng – Chọn Hadoop, Spark, Hive, Hue, Livy và Presto/Trino.
Cấu hình bảo mật – Chỉ định cấu hình bảo mật bạn đã tạo ở bước trước.
Cặp khóa EC2 – Sử dụng cặp khóa hiện có.
Nhóm mạng và bảo mật – Sử dụng cấu hình cho phép phiên bản EMR EC2 tương tác với điểm cuối LDAPS. bên trong Tìm thông số LDAP thích hợp phần này, bạn phải xác nhận thiết lập hợp lệ.

Xác nhận xác thực LDAP đang hoạt động

Khi cụm thiết lập và chạy, bạn có thể kiểm tra xác thực LDAP có hoạt động bình thường không.

If Đăng nhập SSH đã được kích hoạt như một phần của Xác thực LDAP Bên trong Cấu hình bảo mật EMR, bạn có thể SSH vào cụm của mình bằng cách chỉ định người dùng LDAP, nhắc mật khẩu liên quan khi được yêu cầu:

ssh myldapuser@<emr_primary_node>

Nếu đăng nhập SSH bị tắt, bạn có thể SSH bên trong cụm bằng cách sử dụng cặp khóa EC2 được chỉ định trong quá trình tạo cụm:

ssh -i mykeypair.pem ec2-user@<emr_primary_node>

Một cách khác để truy cập phiên bản chính, nếu bạn thích, là sử dụng Quản lý phiên, một khả năng của Người quản lý hệ thống AWS. Để biết thêm thông tin, hãy tham khảo Kết nối với phiên bản Linux của bạn bằng Trình quản lý phiên của Trình quản lý hệ thống AWS.

Khi đang ở trong phiên bản chính, bạn có thể kiểm tra xem người dùng và nhóm LDAP có được truy xuất đúng cách hay không bằng cách sử dụng id yêu cầu. Sau đây là lệnh mẫu để kiểm tra xem người dùng có john được truy xuất đúng cách với các nhóm liên quan:

[ec2-user@ip-10-0-2-237 ~]# id john
uid=941601122(john) gid=941600513(users-group) groups=941600513(users-group),941601123(data-engineers)

Sau đó, bạn có thể kiểm tra xác thực trên các khung được cài đặt khác nhau.

Trước tiên, hãy truy xuất chứng chỉ công khai của khung và lưu trữ nó bên trong kho ủy thác. Tất cả các khung đều có chung chứng chỉ công khai (chứng chỉ chúng tôi đã sử dụng để thiết lập mã hóa chuyển tiếp), vì vậy bạn có thể sử dụng bất kỳ điểm cuối nào được bảo vệ SSL (cổng Hive 10000, cổng Presto/Trino 8446, cổng Livy 8998) để truy xuất nó . Lấy chứng chỉ từ điểm cuối HiveServer2 (cổng 10000):

#Export Hive Server 2 public SSL certificate to a PEM file
openssl s_client -showcerts -connect $(hostname -f):10000 </dev/null 2>/dev/null|openssl x509 -outform PEM > certificate.pem

#Import the PEM certificate inside a truststore
echo "yes" | keytool -import -alias hive_cert -file certificate.pem -storetype JKS -keystore truststore.jks -storepass myStrongPassword

Sau đó, sử dụng kho tin cậy này để liên lạc an toàn với các khung khác nhau.

Sử dụng đoạn mã sau để kiểm tra xác thực HiveServer2 với beeline:

#Use the truststore to connect to the Hive Server 2
beeline -u "jdbc:hive2://$(hostname -f):10000/default;ssl=true;sslTrustStore=truststore.jks;trustStorePassword=myStrongPassword" -n john -p johnPassword

Nếu sử dụng Presto, hãy kiểm tra xác thực Presto bằng presto CLI (cung cấp mật khẩu người dùng khi được yêu cầu):

#Use the truststore to connect to the Presto coordinator
presto-cli 
--user john 
--password 
--catalog hive 
--server https://$(hostname -f):8446 
--truststore-path truststore.jks 
--truststore-password myStrongPassword

Nếu sử dụng Trino, hãy kiểm tra xác thực Trino bằng trino CLI (cung cấp mật khẩu người dùng khi được yêu cầu):

#Use the truststore to connect to the Trino coordinator
trino-cli 
--user john 
--password 
--catalog hive 
--server https://$(hostname -f):8446 
--truststore-path truststore.jks 
--truststore-password myStrongPassword

Thử nghiệm Livy xác thực với cuộn tròn:

#Trust the PEM certificte to connect to the Livy server

#Start session
curl --cacert certificate.pem -X POST 
-u "john:johnPassword" 
--data '{"kind": "spark"}' 
-H "Content-Type: application/json" 
https://$(hostname -f):8998/sessions 
-c cookies.txt

#Example of output
#{"id":0,"name":null,"appId":null,"owner":"john","proxyUser":"john","state":"starting","kind":"spark","appInfo":{"driverLogUrl":null,"sparkUiUrl":null},"log":["stdout: ","nstderr: ","nYARN Diagnostics: "]}

Kiểm tra các lệnh Spark với pyspark:

#SSH inside the primary instance with the specific user
ssh john@<emr-primary-node>
#Or impersonate the user
sudo su - john

#Create a keytab and obtain a kerberos ticket running the ldap-kinit tool
$ ldap-kinit
Username: john
Password: 

#Output
{"message":"ok","contents":{"username":"john","expirationTime":"2023-09-14T15:24:06.303Z[UTC]"}}

#Check the kerberos ticket has been created
$ klist

# Test spark CLIs
$ pyspark

>>> spark.sql("show databases").show()
>>> quit()

Lưu ý rằng ở đây, chúng tôi đã kiểm tra xác thực từ bên trong cụm, nhưng chúng tôi có thể tương tác với Trino, Hive, Presto và Livy ngay cả từ bên ngoài cụm nếu khả năng kết nối và độ phân giải DNS được định cấu hình đúng. Spark CLI là những cái duy nhất chỉ có thể được sử dụng từ bên trong cụm.

Để kiểm tra xác thực Hue, hãy hoàn thành các bước sau:

Điều hướng đến giao diện người dùng web Huế được lưu trữ trên http://<emr_primary_node>:8888/ và cung cấp tên người dùng và mật khẩu LDAP.
Kiểm tra các truy vấn SQL bên trong trình soạn thảo Hive và Trino/Presto.

Để kiểm tra bằng công cụ SQL bên ngoài (chẳng hạn như thợ lặn kết nối với Trino), hãy hoàn thành các bước sau. Đảm bảo định cấu hình nhóm bảo mật nút chính EMR để nhóm này cho phép lưu lượng TCP từ IP DBeaver đến cổng điểm cuối khung mong muốn (ví dụ: 10000 cho HiveServer2, 8446 cho Trino/Presto) và định cấu hình đúng độ phân giải DNS trên máy khách DBeaver máy để phân giải chính xác tên máy chủ của nút chính EMR.

Từ phiên bản chính của cụm EMR của bạn, hãy sao chép các tệp vào bộ chứa S3 truststore.jks (đã tạo trước đó) và /usr/lib/trino/trino-jdbc/trino-jdbc-XXX-amzn-0.jar (thay đổi phiên bản XXX tùy thuộc vào phiên bản EMR).
Tải xuống máy khách DBeaver của bạn truststore.jks và trino-jdbc-XXX-amzn-0.jar các tập tin.
Mở DBeaver và chọn Cơ sở dữ liệu, sau đó chọn Quản lý tài xế.
Chọn Mới để tạo một trình điều khiển mới.
trên Cài đặt tab, cung cấp các thông tin sau:
- Trong Tên driver, đi vào EMR Trino.
- Trong Tên lớp, đi vào io.trino.jdbc.TrinoDriver.
- Trong Mẫu URL, đi vào jdbc:trino://{host}:{port}.
trên Thư viện tab, hãy hoàn thành các bước sau:
- Chọn Thêm tập tin.
- Chọn tệp JAR trình điều khiển Trino JDBC từ hệ thống tệp cục bộ (trino-jdbc-XXX-amzn-0.jar).
Chọn OK để tạo trình điều khiển.
Chọn Cơ sở dữ liệu và Kết nối cơ sở dữ liệu mới.
trên Chủ yếu tab, chỉ định những điều sau:
- Trong Kết nối bằng, lựa chọn Máy chủ.
- Trong Máy chủ, nhập nút chính EMR.
- Trong Hải cảng, nhập cổng Trino (8446 theo mặc định).
trên Thuộc tính trình điều khiển , thêm các thuộc tính sau:
- Thêm SSL với True làm giá trị
- Thêm SSLTrustStorePath với truststore.jks vị trí tập tin làm giá trị.
- Thêm SSLTrustStorePassword với truststore.jks mật khẩu mà bạn đã sử dụng để tạo nó làm giá trị.
Chọn Kết thúc.
Chọn kết nối đã tạo và chọn Kết nối biểu tượng.
Nhập tên người dùng và mật khẩu LDAP của bạn, sau đó chọn OK.

Nếu mọi thứ đều hoạt động, bạn sẽ có thể duyệt các danh mục, cơ sở dữ liệu và bảng Trino trong ngăn điều hướng. Để chạy truy vấn, hãy chọn Trình soạn thảo SQL, sau đó chọn Mở trình soạn thảo SQL.

Từ Trình soạn thảo SQL, bạn có thể truy vấn các bảng của mình.

Các bước tiếp theo

Tính năng xác thực LDAP mới của Amazon EMR đơn giản hóa cách người dùng có thể truy cập vào các khung được cài đặt EMR. Khi người dùng đang sử dụng một khung, bạn có thể muốn quản lý dữ liệu họ có thể truy cập. Đối với chủ đề cụ thể này, bạn có thể sử dụng xác thực LDAP kết hợp với tích hợp EMR Apache Ranger gốc. Để biết thêm thông tin, hãy tham khảo Tích hợp Amazon EMR với Apache Ranger.

Làm sạch

Hoàn thành các hành động dọn dẹp sau để xóa tài nguyên bạn đã tạo sau bài đăng này và tránh phát sinh thêm chi phí. Đối với bài đăng này, chúng tôi sẽ dọn dẹp bằng AWS CLI. Bạn cũng có thể dọn dẹp bằng các hành động tương tự thông qua bảng điều khiển.

Nếu bạn đã khởi chạy một phiên bản EC2 để kiểm tra kết nối LDAP và không cần đến nó nữa, hãy xóa phiên bản đó bằng lệnh sau (chỉ định ID phiên bản của bạn):
```
aws ec2 terminate-instances 
--instance-ids i-XXXXXXXX 
--region <your-aws-region>
```
Nếu bạn đã khởi chạy một phiên bản EC2 để kiểm tra DBeaver và không cần nó nữa, bạn có thể sử dụng lệnh trước đó để xóa phiên bản đó.
Xóa cụm EMR bằng lệnh sau (chỉ định ID cụm EMR của bạn):
```
aws emr terminate-clusters 
--cluster-ids j-XXXXXXXXXXXXX 
--region <your-aws-region>
```
Lưu ý rằng nếu cụm EMR có Bảo vệ chấm dứt được bật trước khi bạn chạy phần trước terminate-clusters lệnh, bạn phải vô hiệu hóa nó. Bạn có thể làm như vậy bằng lệnh sau (chỉ định ID cụm EMR của bạn):
```
aws emr modify-cluster-attributes 
--cluster-ids j-XXXXXXXXXXXXX 
--no-termination-protected 
--region eu-west-1
```

Xóa cấu hình bảo mật EMR bằng lệnh sau:

aws emr delete-security-configuration 
--name <your-security-configuration> 
--region <your-aws-region>

Xóa các bí mật của Secrets Manager bằng các lệnh sau:

aws secretsmanager delete-secret 
--secret-id <first-secret-name> 
--force-delete-without-recovery 
--region <your-aws-region>

aws secretsmanager delete-secret 
--secret-id <second-secret-name> 
--force-delete-without-recovery 
--region <your-aws-region>

Kết luận

Trong bài đăng này, chúng tôi đã thảo luận về cách bạn có thể định cấu hình và kiểm tra xác thực LDAP trên EMR trên cụm EC2. Chúng ta đã thảo luận cách truy xuất các cài đặt LDAP cần thiết, kiểm tra khả năng kết nối với điểm cuối LDAP, định cấu hình cấu hình bảo mật EMR của bạn và kiểm tra xem xác thực LDAP có hoạt động bình thường hay không. Bài đăng này cũng nêu bật cách đơn giản hóa luồng xác thực so với cấu hình tin cậy đa lĩnh vực Active Directory tiêu chuẩn. Để tìm hiểu thêm về tính năng này, hãy tham khảo Sử dụng máy chủ Active Directory hoặc LDAP để xác thực bằng Amazon EMR.

Về các tác giả

Stefano Sandona là Kiến trúc sư giải pháp dữ liệu lớn cấp cao tại AWS. Anh ấy yêu thích dữ liệu, hệ thống phân tán và bảo mật. Anh giúp khách hàng trên toàn thế giới xây dựng nền tảng dữ liệu lớn an toàn, có thể mở rộng và đáng tin cậy.

Adnan Hemani là Kỹ sư phát triển phần mềm tại AWS làm việc với nhóm EMR. Ông tập trung vào tình hình bảo mật của các ứng dụng chạy trên cụm EMR. Anh ấy quan tâm đến các ứng dụng Dữ liệu lớn hiện đại và cách khách hàng tương tác với chúng.

Phân phối nội dung và PR được hỗ trợ bởi SEO. Được khuếch đại ngay hôm nay.
PlatoData.Network Vertical Generative Ai. Trao quyền cho chính mình. Truy cập Tại đây.
PlatoAiStream. Thông minh Web3. Kiến thức khuếch đại. Truy cập Tại đây.
Trung tâmESG. Than đá, công nghệ sạch, Năng lượng, Môi trường Hệ mặt trời, Quản lý chất thải. Truy cập Tại đây.
PlatoSức khỏe. Tình báo thử nghiệm lâm sàng và công nghệ sinh học. Truy cập Tại đây.
nguồn: https://aws.amazon.com/blogs/big-data/simplify-authentication-with-native-ldap-integration-on-amazon-emr/

Trí thông minh dữ liệu tạo

Đơn giản hóa việc xác thực bằng tích hợp LDAP gốc trên Amazon EMR | Dịch vụ web của Amazon

Cách tích hợp LDAP của Amazon EMR hoạt động

Tìm thông số LDAP thích hợp

Kiểm tra giải pháp

Tạo bí mật AWS Secret Manager

Tạo cấu hình bảo mật EMR

Khởi chạy cụm EMR

Xác nhận xác thực LDAP đang hoạt động

Các bước tiếp theo

Làm sạch

Kết luận

Về các tác giả

Cách sử dụng túi tùy chỉnh ở Vương quốc Anh để chuyển đổi doanh nghiệp của bạn

Giao thức đặt cược Ethereum Lido Finance vượt qua 1 triệu trình xác thực

Tin tức mới nhất

Giới thiệu QuantoSwap: Một DEX dựa trên Ethereum mang tính đột phá với nhiều luồng doanh thu

Công cụ khai thác Bitcoin Solo đảm bảo toàn bộ phần thưởng khối 3.125 BTC

OpenAI trong các cuộc đàm phán hợp tác với Worldcoin (WLD)

Lệnh cấm tiền điện tử của Nga: Chỉ cho phép tài sản kỹ thuật số trong nước từ ngày 1 tháng XNUMX

Pháp đề nghị mua tài sản chiến lược từ công ty CNTT Atos đang gặp khó khăn

Avraham Eisenberg, Kẻ khai thác thị trường xoài, bị buộc tội tàng trữ nội dung khiêu dâm trẻ em