Các loại Token trên Openstack
Token là một phương thức dùng để định danh và xác thực người dùng trong Openstack (OPS). Một user muốn gọi tới bất kì API nào của OPS, họ cần được chứng minh rằng họ là ai và họ được phép gọi API nào. User nhận được token này khi đã được Keystone xác thực thành công.
Trên thực tế có 4 loại token đã và đang được sử dụng trên Openstack, bài viết này, Bizfly Cloud sẽ phân tích chi tiết về các loại Token trên Openstack, cách thức từng loại token được sinh ra, xác thực và thu hồi đồng thời cũng phân tích về ưu nhược điểm của từng loại token.
1. UUID Token
Là loại token đầu tiên của keystone, sử dụng phương pháp sinh chuỗi sử dụng các chữ số hệ hexa. Điều này làm UUID token trở nên thân thiện và an toàn cho việc truyền giữa các môi trường non-binary. Nhưng UUID có một nhược điểm là mỗi khi user gọi đến bất kỳ service nào khác trên Openstack thì service đó lại phải gọi về Keystone (Database của Keystone) để validate token, điều này dẫn tới việc keystone bị thắt núi cổ chai ảnh hưởng tới hoạt động của toàn hệ thống cloud.
1.1. Quá trình sinh UUID token
- Bước 1: User gửi tới keystone thông tin yêu cầu xác thực gồm User name, Password, và Scope (Domain hoặc Project)
- Bước 2: Keystone sẽ yêu cầu Backend Identity (Ở đây là LDAP) định danh và xác thực User vừa gửi request nếu user được xác thực thì sẽ lấy ra User ID. Không được xác thực thì kết thúc quá trình cấp token
- Bước 3: Keystone sẽ yêu cầu backend Resources kiểm tra xem User ID kia thuộc domain nào và có vai trò trên Project nào rồi lấy ra các thông tin Domain ID, Project ID
- Bước 4: Keystone sẽ kiểm tra xem User có vai trò gì trên Project và Domain lấy ra role của user đó, nếu user không có vai trò gì trên Project thì kết thúc quá trình cấp phát token
- Bước 5: Từ việc xác định vai trò của User trên Project sẽ đưa ra các Endpoint mà User được phép sử dụng
- Bước 6: Tổng hợp lại các thông tin trên vào payload token và gửi về cho User Token để user sử dụng các dịch vụ khác.
1.2. Quá trình Validate Token
- Bước 1: Khi dịch vụ nhận được 1 yêu cầu sử dụng dịch vụ của User gửi tới thì dịch vụ cần phải xác thức xem liệu token này có an toàn và hợp lệ không vì vậy nó cần gọi tới Keystone để yêu cầu Validate token. Như đã phân tích ở phần đầu chính vì lý do này mà UUID dẫn đến tình trạng tắc nghẽn cổ chai ở keystone
- Bước 2: Keystone kiểm tra trong database nếu có token như vậy thì là hợp lệ nếu không thì thông báo Token Not Found
- Bước 3: Kiểm tra các thông tin có trong token kiểm tra thời gian hết hạn và kiểm tra xem token có trong danh sách thu hổi không nếu tất cả đều thỏa mãn thì quá trình xác thực hoàn thành
1.3. Quá trình thu hồi token
Khi nhận được 1 yêu cầu thu hồi token thì Keystone trước hết sẽ thực hiện bước validate token sau đó mới tạo các Event Revoke và Update trong bảng revoke table trong database của keystone với các thông tin như User ID, Project ID, Revoke At …
2. PKI và PKIZ Token
PKI token chứa toàn bộ thông tin xác thực nhận được từ Keystone. Điều này có nghĩa là token chứa lượng lớn các thông tin: như là thời gian cấp phát, thời gian hết hạn, định danh user, thông tin project, domain và role cho user, catalog dịch vụ, và nhiều thông tin khác. Chính vì mang quá nhiều thông tin nên nó lại là điểm yếu của loại token này vì khi hệ thống được mở rộng các thông tin user và catalog càng nhiều trong khi đó HTTP Header chỉ giới hạn 8KB.
Để khác phục điều này thì Openstack cũng đưa ra một loại token PKIZ với khả năng nén token xuống kích thước tối thiểu. Mặc dù đã được nén nhưng PKIZ vẫn bị cộng đồng Openstack đánh giá là kích thước quá lớn. Ưu điểm của loại token này là các OpenStack services có thể cache lại token này để đưa ra quyết định ủy quyền mà không phải liên hệ lại keystone nên đã giải quyết được vấn đề tắc nghẽn cổ chai của UUID token.
2.1. Quá trình sinh token PKI và PKIZ
Cũng giống như UUID token với PKI và PKIZ token thì User cần gửi các thông tin để Keystone xác thực và cấp token, nhưng có một điểm khác là loại token này sử dụng hệ mật mã khóa bất đối xứng tức là dùng khóa Private Key của keystone để mã hóa Payload token, khi user sử dụng token này thì các service trong Openstack sẽ sử dụng Public Key để giải mã và lấy ra các thông tin. Các bước khởi tạo token PKI được thể hiện rất rõ ở hình ảnh trên.
2.2. Quá trình validate và thu hồi PKI và PKIZ token
Quá trình này hoàn toàn tương tự vơi UUID token. Quá trình thu hồi cũng hoàn toàn tương tự UUID token.
3. Fernet Token
Là loại token mới nhất của keystone khắc phục được tất cả các nhược điểm của 2 loại token trên, nó mang vừa đủ thông tin cần thiết trên token và đồng thời cũng cho phép các Service có thể cache các token giải quyết vấn đề tắc nghẽn cổ chai của UUID token, Fernet Token sử dụng Hệ mật mã khóa đối xứng tức là key mã hóa cũng chính là key giải mã.
Nhưng trong môi trường Production việc sử dụng lâu dài 1 khóa là một mối nguy hại tiềm tàng cho hệ thống chính vì vậy Fernet token mang trong nó một cơ chế xoay vòng khóa để đảm bảo khóa chỉ tồn tại trong một khoảng thời gian nhất định mà vẫn giải mã token được trước thời gian token hết hạn. Có 3 loại khóa được sử dụng trong Fernet Token (nhưng vẫn dựa trên hệ mật khóa đối xứng)
- Loại 1 - Primary Key: sử dụng cho cả 2 mục đích mã hóa và giải mã fernet tokens. Các key được đặt tên theo số nguyên bắt đầu từ 0. Trong đó Primary Key có chỉ số cao nhất.
- Loại 2 - Secondary Key: chỉ dùng để giải mã. -> Lowest Index < Secondary Key Index < Highest Index
- Loại 3 - Stagged Key: - tương tự như secondary key trong trường hợp nó sử dụng để giải mã token. Tuy nhiên nó sẽ trở thành Primary Key trong lần luân chuyển khóa tiếp theo. Stagged Key có chỉ số 0
Quá trình xoay vòng khóa được mô tả như sau.
3.1. Quá trình sinh Fernet Token
Giống như các loại token User phải gửi các thông tin định danh và xác thực để Keystone xác thức và cấp Token. Fernet token sử dụng hệ mã khóa đối xứng để ký và giải mã nên ta có thể thấy trong hình các thông tin của token được ký để tạo ra một Cipher Text ( Bản mã) kết hợp với HMAC để đảm bảo tính toàn vẹn và bí mật cho Token.
3.2. Quá trình validate Fernet Token
Quá trình validate Fernet token cũng tương tự như các Token khác chỉ có một vài điểm khác ở giai đoạn đầu của quá trình validate service sẽ sử dụng khóa đối xứng để giải mã và lấy ra các thông tin của token như Current Time, Expiry Time ... để xác minh tính hợp lệ cuả Token.
3.3. Quá trình thu hồi
Quá trình thu hồi hoàn toàn tương tự như các loại token khác.
Trước khi thu hồi Fernet Token Keystone cần thực hiện bước Validate Token, khi Token được xác minh tính hợp lệ, keystone sẽ khởi tạo sự kiện thu hồi token và Update các thông tin cần thiết (User ID, Project ID, Rovoke At ...) vào bảng Revoke trong Database của keystone.
4. So sánh giữa các loại token
>> Xem thêm: Hướng dẫn sao lưu cơ sở dữ liệu MySQL