Giới thiệu về Keystone.

1. Keystone là gì?

Keystone là một Openstack project cung cấp các dịch vụ Identify, Token, Catalog, Policy cho các dịch vụ khác trong Openstack. Keystone Gồm hai phiên bản:

• v2: sử dụng UUID
• v3: sử dụng PKI, sử dụng một cặp key mở và đóng để xác minh chéo và xác thực. Hai tính năng chính của Keystone:
• User Managerment: Keystone giúp xác thực tài khoản người dụng và chỉ định xem người dùng có quyền gì.
• Service Catalog: Cung cấp một danh mục các dịch vụ sẵn sàng cùng với các API endpoint để truy cập các dịch vụ đó.

2. Một số khái niệm liên quan.

• Authentication: Là quá trình xác nhận danh tính của người dùng dựa trên thông tin đăng nhập của người đó(credential)). Khi xác thực được danh tính người dùng, nó cấp cho người dùng một token xác thực. Người dùng sẽ cung cấp token đó cho mỗi yêu cầu sau đó.
• Credentials: Là thông tin dùng để xác thực người dùng. Ví dụ như username, password và API key, hay là token mà được cung cấp.
• Domain: Là một thực thể API v3 dịch vụ nhận dạng, tập hợp của các project cà người dùng để xác định danh giới để quản trị xác thực. Có thể là một cá nhân hay tổ chức, hoặc của nhà quản trị.
• Endpoint: Là một địa chỉ truy cập mạng, thường là địa chỉ URL của một dịch vụ để từ đó truy cập vào dịch vụ.
• Group: Là một thực thể API v3 dịch vụ nhận dạng, là một nhóm những người dùng nằm trong một domain. Quyền của một group được thêm vào một domain hay một project sẽ được áp dụng cho tất cả user của group đó.
• Openstackclient: Là một công cụ dòng lệnh cung cấp giao diện để truy cập các dịch vụ Openstack.
• Project: sử dụng để nhóm hoặc cô lập tài nguyên, hoặc định danh các đối tượng. Tùy thuộc vào nhà quản lý
• Region: Là một thực thể API v3 dịch vụ nhận dạng, đại diện cho một bộ phận chung trong triển khai Openstack. Có thể tạo và liên kết chúng với các region phụ để tạo cấu trúc dạng cây. Region không có ý nghĩa về mặt địa lý nhưng tên của region thường được đặt theo tên khu vực địa lý(vd: asia-east)
• Roles: Là tập hợp các quyền hạn và đặc quyền của người dùng để thực hiện các hành động cụ thể. Token được gửi đến người dùng sau khi xác thực sẽ bao gồm cả một tập hợp các quyền. Khi người dùng yêu cầu một dịch vụ, dịch vụ này sẽ kiểm tra quyền hạn của người dùng và cung cấp dịch vụ trong quyền hạn đó.
• Service: Một dịch vụ Openstack, như Compute (nova), Object Storage (swift), hay Image service (glance), là một hay nhiều endpoint mà qua đó người dùng có thể truy cập tài nguyên và thực hiện các hành động.

• Token: Một chuỗi gồm chữ và chữ số cho phép truy cập vào các tài nguyên và API Openstack. Token có thể bị thu hồi bất kỳ lúc nào và có giá trị trong thời gian hữu hạn.

• User: Đại diện cho một người dùng, hệ thống hay dịch vụ mà sử dụng dịch vụ Openstack

3.Identify service

Identify service(dịch vụ xác thực) trong keystone được cung cấp bởi các Actors. Nó có thể tới từ nhiều dịch vụ như SQL, LDAP và Federated Identify Providers.

3.1. SQL

• Keystone có tùy chọn cho phép lưu các actor trong SQL. Nó hỗ trợ các database như MySQL, PostgreSQL,…
• Keystone sẽ lưu trữ thông tin như username, password, mô tả,…
• Cài đặt cho database này sẽ nằm trong file config của keystone.
• Về bản chất, Keystone sẽ hoạt động như 1 Identity Provider. Vì thế đây sẽ không phải là lựa chọn tốt nhất trong một vài trường hợp, nhất là đối với các khách hàng là doanh nghiệp
• Ưu điểm:
  • Dễ cài đặt.
  • Quản lý user, group thông qua Openstack API.
• Nhược điểm:
  • Keystone không nên là Identify service.
  • Hỗ trợ cả mật khấu yếu.
  • Hầu hết các doanh nghiệp đều dùng LDAP.
  • Phải ghi nhớ username và password.

3.2. LDAP.

• Keystone cũng có tuỳ chọn cho phép lưu trữ actors trong LDAP
• Keystone sẽ truy cập tới LDAP như bất kỳ ứng dụng khác (System Login, Email, Web Application,…)
• Các cài đặt kết nối sẽ được lưu trong file config của Keystone. Các cài đặt này cũng bao gồm tuỳ chọn cho phép Keystone được ghi hoặc chỉ đọc dữ liệu từ LDAP.
• Thông thường LDAP chỉ nên cho phép các câu lệnh đọc, ví dụ như tìm kiếm user, group và xác thực
• Nếu sử dụng LDAP như một read-only Identity Backends thì Keystone cần có quyền sử dụng LDAP
• Ưu điểm:
  • Không cần sao lưu tài khoản người dùng
  • Keystone không hoạt động như một Identity Provider
• Nhược điểm:
  • Account của các dịch vụ sẽ lưu ở đâu đó và người quản trị LDAP không muốn có tài khoản này trong LDAP
  • Keystone có thể thấy mật khẩu người dùng, lúc mật khẩu được yêu cầu authentication.

    3.3. Multiple backends.

• Kể từ bản Juno thì Keystone đã hỗ trợ nhiều Identity backends cho V3 Identity API. Nhờ vậy mà mỗi một domain có thể có một identity source (backend) khác nhau.
• Domain mặc định thường sử dụng SQL backend bởi nó được dùng để lưu các host service accounts. Service accounts là các tài khoản được dùng bởi các dịch vụ OpenStack khác nhau để tương tác với Keystone.
• Việc sử dụng Multiple Backends được lấy cảm hứng trong các môi trường doanh nghiệp, LDAP chỉ được sử dụng để lưu thông tin của các nhân viên bởi LDAP admin có thể không ở cùng một công ty với nhóm triển khai OpenStack. Bên cạnh đó, nhiều LDAP cũng có thể được sử dụng trong trường hợp công ty có nhiều phòng ban.
• Ưu điểm:
  • Cho phép việc sử dụng nhiều LDAP để lưu tài khoản người dùng và SQL để lưu tài khoản dịch vụ -Sử dụng lại LDAP đã có.
• Nhược điểm:
  • Phức tạp trong khâu set up
  • Xác thực tài khoản người dùng phải trong miền scoped

3.4. Identity Providers

• Kể từ bản Icehouse thì Keystone đã có thể sử dụng các liên kết xác thực thông qua module Apache cho các Identity Providers(nhà cung cấp dịch vụ xác thực) khác nhau.
• Cơ bản thì Keystone sẽ sử dụng một bên thứ 3 để xác thực, nó có thể là những phần mềm sử dụng các backends (LDAP, AD, MongoDB) hoặc mạng xã hội (Google, Facebook, Twitter).
• Ưu điểm:
  • Có thể tận dụng phần mềm và cơ sở hạ tầng cũ để xác thực cũng như lấy thông tin của users.
  • Tách biệt keystone và nhiệm vụ định danh, xác thực thông tin.
  • Mở ra cánh cửa mới cho những khả năng mới ví dụ như single signon và hybrid cloud
  • Keystone không thể xem mật khẩu, mọi thứ đều không còn liên quan tới keystone.
• Nhược điểm:
  • Phức tạp nhất về việc setup

Identity Source	Use Cases
SQL	- Testing hoặc developing với OpenStack - Ít users - OpenStack specific accounts
LDAP	- Nếu có sẵn LDAP trong công ty - Sử dụng một mình LDAP nếu bạn có thể tạo service accounts trong LDAP
Multiple Backends	- Được sử dụng nhiều trong các doanh nghiệp - Dùng nếu service user không được cho phép trong LDAP
Identity Provider	- Nếu bạn muốn có những lợi ích từ cơ chế mới Federated Identity - Nếu đã có sẵn identity provider - Keystone không thể kết nối tới LDAP - Non-LDAP identity source

4. User management

• Một số ví dụ về quản lý người dùng trong Keystone sử dụng Openstack client:
  • Tạo user tên là lamth:

    openstack user create --password=123 --email tranhuulam@example.com lamth
    

  • Tạo project:

    openstack project create acme --domain default
    

  • Tạo domain:

    openstack domain create emea
    

  • Tạo role:

    openstack role create compute-user
    

• Lưu ý:
  • Các dịch vụ riêng lẻ được gán nghĩa cho các role, từ đó giới hạn hoặc ủy quyền truy cập cho user với role đó đến các dịch vụ. Role được cấu hình trong file policy.json của mỗi dịch vụ. Ví dụ, để giới hạn quyền truy cập dịch vụ Compute cho role compute-user vừa tạo, sửa file policy.json của dịch vụ Compute.
• Dịch vụ Identity sẽ gán một project và một role cho một user. Nghĩa là role này sẽ ủy quyền truy cập các dịch vụ cho user nhưng chỉ trong phạm vi của project được cấu hình. Ví dụ về gán role:

    openstack role add --project acme --user lamth compute-user
  

• User có thể có các role khác nhau trong các project khác nhau. Cũng có thể có nhiều role trong cùng một project. Ví dụ user lamth có thể có role admin trong project lamth-project và role compute-user trong project acme.

File /etc/[SERVICE_CODENAME]/policy.json quản lý các tác vụ mà user có thể thực hiện cho service đó. Ví dụ /etc/nova/policy.conf chỉ định quyền truy cập vào dịch vụ Compute, /etc/glance/policy.json chỉ định quyền truy cập vào dịch vụ Image.

Mặc định file policy.json của các dịch vụ thường chỉ nhận ra role admin, bất kỳ user với bất kỳ role nào trong một project đều có thể truy cập mọi hoạt động mà không cần role admin.

Để hạn chế quyền thực hiện các hành động trong, ví dụ, Compute Service, đầu tiên cần tạo một role trong dịch vụ Identity, gán role cho user sau đó sửa file /etc/nova/policy.json để cấu hình quyền truy cập compute cho role này.

• Ví dụ
  • Cấu hình sau sẽ không giới hạn quyền tạo máy ảo cho một role nào, tức là bất kỳ user nào co role nào cũng có thể thực hiện tạo máy ảo:

    "compute:create": "",
    

  • Cấu hình sau sẽ chỉ cho phép user có role compute-user mới có thể tạo máy ảo:

    "compute:create": "role:compute-user",
    

    Tìm hiểu thêm về cú pháp và các ví dụ về policy.json

Lưu ý: Ở các phiên bản Openstack mới, file policy.yaml được sử dụng, tuy nhiên file policy.json vẫn đang được hỗ trợ.

5. Authentication.

Có nhiều các để xác thực với keystone nhưng có hai cách phổ biến nhất là dùng password và dùng token.

5.1. Password

• Phương thức phổ biến nhất cho người dùng hay dịch vụ để xác thực là dùng password. Đoạn payload sau là ví dụ về một POST request đến Keystone với xác thực bằng password. Người dùng cso thể nhận được nhưng thông tin cần thiết cho việc xác thực.

• Payload phải chứa đủ thông tin để tìm kiếm, xác thực user và lấy danh sách catalog service dựa theo quyền của user theo project cụ thể.
• User section nhận diện thông tin domain trừ khi user globally unique ID được sử dụng để tránh nhầm lẫn giữa các user trùng tên.
• Scope section là tuỳ chọn nhưng thường được sử dụng để user thu thập service catalog. Scope được sử dụng để xác định project nào user được làm việc. Nếu user không có role trên project, request sẽ bị loại bỏ. Tương tự như user section, scope section phải có đủ thông tin về project để tìm nó, domain phải được chỉ định, bởi project name cũng có thể trùng nhau giữa các domain khác nhau. Trừ khi cung cấp project ID, khi đó không cần thông tin domain nữa.
• User request token bằng username, password và project scope. Token sau đó sẽ được sử dụng ở các OpenStack service khác.

5.2. Token

• Tương tự như password, user có thể yêu cầu một token mới từ token hiện tại. Payload của POST request:

6. Keystone WorkFlow.

Tài liệu tham khảo

• https://docs.openstack.org/keystone/stein/admin/identity-concepts.html
• https://github.com/hungnt1/Openstack_Research/blob/master/Keystone/1.%20Introduction-Keystone.md
• https://github.com/thaonguyenvan/meditech-thuctap/blob/master/ThaoNV/Tim%20hieu%20OpenStack/docs/keystone/Fundamental-keystone.md#authentication2