🥇Chạy Keycloak ở chế độ HA trên Kubernetes

TL; DR: sẽ có phần mô tả về Keycloak, một hệ thống kiểm soát truy cập mã nguồn mở, phân tích cấu trúc bên trong, cấu hình chi tiết.

Giới thiệu và ý tưởng chính

Trong bài viết này, chúng ta sẽ thấy những ý tưởng cơ bản cần ghi nhớ khi triển khai cụm Keycloak trên Kubernetes.

Nếu bạn muốn biết thêm về Keycloak, hãy tham khảo các link ở cuối bài viết. Để say mê thực hành hơn, bạn có thể học kho lưu trữ của chúng tôi với một mô-đun thực hiện các ý chính của bài viết này (có hướng dẫn khởi chạy, bài viết này sẽ cung cấp cái nhìn tổng quan về thiết bị và cài đặt, khoảng người phiên dịch).

Keycloak là một hệ thống toàn diện được viết bằng Java và được xây dựng trên máy chủ ứng dụng Côn trung hoang da. Nói tóm lại, đó là một khuôn khổ ủy quyền cung cấp cho người dùng ứng dụng khả năng liên kết và SSO (đăng nhập một lần).

Mời các bạn đọc bản chính thức website hoặc Wikipedia để hiểu chi tiết.

Khởi chạy Keycloak

Keycloak yêu cầu hai nguồn dữ liệu liên tục để chạy:

Cơ sở dữ liệu được sử dụng để lưu trữ dữ liệu đã được thiết lập, chẳng hạn như thông tin người dùng
Bộ đệm dữ liệu, được sử dụng để lưu trữ dữ liệu từ cơ sở dữ liệu, cũng như để lưu trữ một số siêu dữ liệu có thời gian tồn tại ngắn và thường xuyên thay đổi, chẳng hạn như phiên của người dùng. Đã thực hiện vô tận, thường nhanh hơn đáng kể so với cơ sở dữ liệu. Nhưng trong mọi trường hợp, dữ liệu được lưu trong Infinispan chỉ là tạm thời - và nó không cần phải lưu ở bất kỳ đâu khi cụm được khởi động lại.

Keycloak hoạt động ở bốn chế độ khác nhau:

Bình thường - một và chỉ một tiến trình, được cấu hình thông qua một tập tin độc lập.xml
Cụm thông thường (tùy chọn tính sẵn sàng cao) - tất cả các quy trình phải sử dụng cùng một cấu hình, phải được đồng bộ hóa thủ công. Cài đặt được lưu trữ trong một tập tin độc lập-ha.xml, ngoài ra, bạn cần thực hiện quyền truy cập chung vào cơ sở dữ liệu và bộ cân bằng tải.
Cụm miền — khởi động một cụm ở chế độ bình thường nhanh chóng trở thành một công việc thường ngày và nhàm chán khi cụm phát triển, vì mỗi khi cấu hình thay đổi, tất cả các thay đổi phải được thực hiện trên mỗi nút cụm. Chế độ hoạt động của miền giải quyết vấn đề này bằng cách thiết lập một số vị trí lưu trữ dùng chung và xuất bản cấu hình. Các cài đặt này được lưu trữ trong tập tin tên miền.xml
Sao chép giữa các trung tâm dữ liệu — nếu bạn muốn chạy Keycloak trong một cụm gồm nhiều trung tâm dữ liệu, thường là ở các vị trí địa lý khác nhau. Trong tùy chọn này, mỗi trung tâm dữ liệu sẽ có cụm máy chủ Keycloak riêng.

Trong bài viết này, chúng tôi sẽ xem xét chi tiết tùy chọn thứ hai, đó là cụm thông thường, và chúng ta cũng sẽ đề cập một chút đến chủ đề sao chép giữa các trung tâm dữ liệu, vì việc chạy hai tùy chọn này trong Kubernetes là rất hợp lý. May mắn thay, trong Kubernetes không có vấn đề gì với việc đồng bộ hóa cài đặt của một số nhóm (nút Keycloak), vì vậy cụm miền Nó sẽ không quá khó để thực hiện.

Cũng xin lưu ý rằng từ cụm phần còn lại của bài viết sẽ chỉ áp dụng cho một nhóm nút Keycloak hoạt động cùng nhau, không cần tham khảo đến cụm Kubernetes.

Cụm Keycloak thông thường

Để chạy Keycloak ở chế độ này bạn cần:

cấu hình cơ sở dữ liệu chia sẻ bên ngoài
cài đặt cân bằng tải
có một mạng nội bộ có hỗ trợ phát đa hướng IP

Chúng tôi sẽ không thảo luận về việc thiết lập cơ sở dữ liệu bên ngoài vì đó không phải là mục đích của bài viết này. Giả sử rằng có một cơ sở dữ liệu đang hoạt động ở đâu đó - và chúng ta có một điểm kết nối với nó. Chúng tôi sẽ chỉ thêm dữ liệu này vào các biến môi trường.

Để hiểu rõ hơn về cách Keycloak hoạt động trong cụm chuyển đổi dự phòng (HA), điều quan trọng là phải biết mức độ phụ thuộc vào khả năng phân cụm của Wildfly.

Wildfly sử dụng một số hệ thống con, một số được dùng làm bộ cân bằng tải, một số dùng để chịu lỗi. Bộ cân bằng tải đảm bảo tính khả dụng của ứng dụng khi nút cụm bị quá tải và khả năng chịu lỗi đảm bảo tính khả dụng của ứng dụng ngay cả khi một số nút cụm bị lỗi. Một số hệ thống con sau:

mod_cluster: Hoạt động cùng với Apache như một bộ cân bằng tải HTTP, tùy thuộc vào TCP multicast để tìm máy chủ theo mặc định. Có thể được thay thế bằng một bộ cân bằng bên ngoài.
infinispan: Bộ đệm được phân phối sử dụng các kênh JGroups làm lớp truyền tải. Ngoài ra, nó có thể sử dụng giao thức HotRod để liên lạc với cụm Infinispan bên ngoài nhằm đồng bộ hóa nội dung bộ đệm.
jgroups: Cung cấp hỗ trợ liên lạc nhóm cho các dịch vụ có tính sẵn sàng cao dựa trên các kênh JGroups. Các đường ống được đặt tên cho phép các phiên bản ứng dụng trong một cụm được kết nối thành các nhóm để giao tiếp có các đặc tính như độ tin cậy, tính trật tự và độ nhạy với các lỗi.

Cân bằng tải

Khi cài đặt bộ cân bằng làm bộ điều khiển xâm nhập trong cụm Kubernetes, điều quan trọng là phải ghi nhớ những điều sau:

Keycloak giả định rằng địa chỉ từ xa của máy khách kết nối qua HTTP với máy chủ xác thực là địa chỉ IP thực của máy khách. Cài đặt cân bằng và xâm nhập phải đặt tiêu đề HTTP chính xác X-Forwarded-For и X-Forwarded-Proto, đồng thời lưu tiêu đề gốc HOST. Phiên bản mới nhất ingress-nginx (>0.22.0) mặc định tắt tính năng này

Kích hoạt cờ proxy-address-forwarding bằng cách đặt một biến môi trường PROXY_ADDRESS_FORWARDING в true giúp Keycloak hiểu rằng nó đang hoạt động sau một proxy.

Bạn cũng cần kích hoạt phiên dính trong sự xâm nhập. Keycloak sử dụng bộ đệm Infinispan phân tán để lưu trữ dữ liệu liên quan đến phiên xác thực hiện tại và phiên người dùng. Theo mặc định, bộ đệm hoạt động với một chủ sở hữu duy nhất, nói cách khác, phiên cụ thể đó được lưu trữ trên một số nút trong cụm và các nút khác phải truy vấn từ xa nếu chúng cần quyền truy cập vào phiên đó.

Cụ thể, trái với tài liệu, việc đính kèm phiên có tên cookie không có tác dụng đối với chúng tôi AUTH_SESSION_ID. Keycloak có vòng lặp chuyển hướng, vì vậy chúng tôi khuyên bạn nên chọn tên cookie khác cho phiên cố định.

Keycloak cũng đính kèm tên của nút phản hồi đầu tiên AUTH_SESSION_IDvà vì mỗi nút trong phiên bản có tính sẵn sàng cao sử dụng cùng một cơ sở dữ liệu nên mỗi nút trong số chúng nên có một mã định danh nút riêng biệt và duy nhất để quản lý giao dịch. Nên đưa vào JAVA_OPTS thông số jboss.node.name и jboss.tx.node.id duy nhất cho mỗi nút - ví dụ: bạn có thể đặt tên của nhóm. Nếu bạn đặt tên nhóm, đừng quên giới hạn 23 ký tự cho các biến jboss, vì vậy tốt hơn nên sử dụng StatefulSet thay vì Deployment.

Một cái cào khác - nếu nhóm bị xóa hoặc khởi động lại, bộ đệm của nó sẽ bị mất. Khi tính đến điều này, cần đặt số lượng chủ sở hữu bộ đệm cho tất cả các bộ đệm thành ít nhất là hai, để vẫn còn một bản sao của bộ đệm. Giải pháp là chạy kịch bản của Wildfly khi khởi động nhóm, đặt nó vào thư mục /opt/jboss/startup-scripts trong thùng chứa:

Nội dung tập lệnh

embed-server --server-config=standalone-ha.xml --std-out=echo
batch

echo * Setting CACHE_OWNERS to "${env.CACHE_OWNERS}" in all cache-containers

/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=authenticationSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=actionTokens:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})

run-batch
stop-embedded-server

sau đó đặt giá trị của biến môi trường CACHE_OWNERS đến mức cần thiết.

Mạng riêng có hỗ trợ phát đa hướng IP

Nếu bạn sử dụng Weavenet làm CNI, tính năng phát đa hướng sẽ hoạt động ngay lập tức - và các nút Keycloak của bạn sẽ nhìn thấy nhau ngay khi chúng được khởi chạy.

Nếu không có hỗ trợ ip multicast trong cụm Kubernetes, bạn có thể định cấu hình JGroups để hoạt động với các giao thức khác để tìm nút.

Tùy chọn đầu tiên là sử dụng KUBE_DNScái nào sử dụng headless service để tìm các nút Keycloak, bạn chỉ cần chuyển cho JGroups tên của dịch vụ sẽ được sử dụng để tìm các nút.

Một lựa chọn khác là sử dụng phương pháp KUBE_PING, hoạt động với API để tìm kiếm các nút (bạn cần định cấu hình serviceAccount có quyền list и get, sau đó định cấu hình các nhóm để hoạt động với điều này serviceAccount).

Cách JGroups tìm các nút được định cấu hình bằng cách đặt các biến môi trường JGROUPS_DISCOVERY_PROTOCOL и JGROUPS_DISCOVERY_PROPERTIES. Đối với KUBE_PING bạn cần chọn nhóm bằng cách hỏi namespace и labels.

️ Nếu bạn sử dụng multicast và chạy hai hoặc nhiều cụm Keycloak trong một cụm Kubernetes (giả sử một cụm trong không gian tên production, thứ hai - staging) - các nút của một cụm Keycloak có thể tham gia một cụm khác. Hãy đảm bảo sử dụng một địa chỉ multicast duy nhất cho mỗi cụm bằng cách đặt các biếnjboss.default.multicast.address и jboss.modcluster.multicast.address в JAVA_OPTS.

Sao chép giữa các trung tâm dữ liệu

Liên kết

Keycloak sử dụng nhiều cụm bộ đệm Infinispan riêng biệt cho mỗi trung tâm dữ liệu nơi đặt các cụm Keycloack được tạo thành từ các nút Keycloak. Nhưng không có sự khác biệt giữa các nút Keycloak ở các trung tâm dữ liệu khác nhau.

Các nút Keycloak sử dụng Lưới dữ liệu Java bên ngoài (máy chủ Infinispan) để liên lạc giữa các trung tâm dữ liệu. Truyền thông hoạt động theo giao thức HotRod Infinispan.

Bộ đệm Infinispan phải được cấu hình với thuộc tính remoteStore, để dữ liệu có thể được lưu trữ từ xa (ở một trung tâm dữ liệu khác, khoảng người phiên dịch) bộ nhớ đệm. Có các cụm infinispan riêng biệt giữa các máy chủ JDG, do đó dữ liệu được lưu trữ trên JDG1 tại chỗ site1 sẽ được sao chép sang JDG2 tại chỗ site2.

Và cuối cùng, máy chủ JDG nhận sẽ thông báo cho các máy chủ Keycloak về cụm của nó thông qua các kết nối máy khách, đây là một tính năng của giao thức HotRod. Các nút keycloak đang bật site2 cập nhật bộ đệm Infinispan của họ và phiên người dùng cụ thể cũng sẽ có sẵn trên các nút Keycloak trên site2.

Đối với một số bộ nhớ đệm, cũng có thể không tạo bản sao lưu và tránh ghi dữ liệu hoàn toàn qua máy chủ Infinispan. Để thực hiện việc này, bạn cần xóa cài đặt remote-store bộ đệm Infinispan cụ thể (trong tệp độc lập-ha.xml), sau đó một số cụ thể replicated-cache cũng sẽ không còn cần thiết ở phía máy chủ Infinispan.

Thiết lập bộ đệm

Có hai loại bộ đệm trong Keycloak:

Địa phương. Nó nằm bên cạnh cơ sở dữ liệu và có tác dụng giảm tải cho cơ sở dữ liệu cũng như giảm độ trễ phản hồi. Loại bộ đệm này lưu trữ vùng, ứng dụng khách, vai trò và siêu dữ liệu người dùng. Loại bộ đệm này không được sao chép, ngay cả khi bộ đệm là một phần của cụm Keycloak. Nếu một mục trong bộ đệm thay đổi, một thông báo về thay đổi sẽ được gửi đến các máy chủ còn lại trong cụm, sau đó mục đó sẽ bị loại khỏi bộ đệm. Xem mô tả work Xem bên dưới để biết mô tả chi tiết hơn về quy trình.
Nhân rộng. Xử lý các phiên của người dùng, mã thông báo ngoại tuyến và cũng giám sát các lỗi đăng nhập để phát hiện các nỗ lực lừa đảo mật khẩu và các cuộc tấn công khác. Dữ liệu được lưu trữ trong các bộ đệm này là tạm thời, chỉ được lưu trữ trong RAM nhưng có thể được sao chép trên toàn cụm.

Bộ nhớ đệm Infinispan

Phiên - một khái niệm trong Keycloak, bộ đệm riêng biệt được gọi là authenticationSessions, được sử dụng để lưu trữ dữ liệu của người dùng cụ thể. Các yêu cầu từ các bộ đệm này thường được trình duyệt và máy chủ Keycloak yêu cầu chứ không phải bởi các ứng dụng. Đây là lúc sự phụ thuộc vào các phiên cố định phát huy tác dụng và bản thân các bộ đệm như vậy không cần phải sao chép, ngay cả trong trường hợp chế độ Active-Active.

Mã thông báo hành động. Một khái niệm khác, thường được sử dụng cho nhiều tình huống khác nhau, chẳng hạn như khi người dùng phải thực hiện điều gì đó không đồng bộ qua thư. Ví dụ, trong quá trình làm thủ tục forget password bộ nhớ đệm actionTokens được sử dụng để theo dõi siêu dữ liệu của mã thông báo được liên kết - ví dụ: mã thông báo đã được sử dụng và không thể kích hoạt lại. Loại bộ đệm này thường cần được sao chép giữa các trung tâm dữ liệu.

Bộ nhớ đệm và lão hóa của dữ liệu được lưu trữ hoạt động để giảm tải cho cơ sở dữ liệu. Loại bộ nhớ đệm này cải thiện hiệu suất nhưng lại gây ra một vấn đề rõ ràng. Nếu một máy chủ Keycloak cập nhật dữ liệu thì các máy chủ khác phải được thông báo để chúng có thể cập nhật dữ liệu trong bộ đệm của mình. Keycloak sử dụng bộ đệm cục bộ realms, users и authorization để lưu trữ dữ liệu từ cơ sở dữ liệu.

Ngoài ra còn có một bộ đệm riêng work, được nhân rộng trên tất cả các trung tâm dữ liệu. Bản thân nó không lưu trữ bất kỳ dữ liệu nào từ cơ sở dữ liệu mà dùng để gửi thông báo về tình trạng lão hóa dữ liệu đến các nút cụm giữa các trung tâm dữ liệu. Nói cách khác, ngay sau khi dữ liệu được cập nhật, nút Keycloak sẽ gửi tin nhắn đến các nút khác trong trung tâm dữ liệu của nó, cũng như các nút trong các trung tâm dữ liệu khác. Sau khi nhận được tin nhắn như vậy, mỗi nút sẽ xóa dữ liệu tương ứng trong bộ đệm cục bộ của nó.

Phiên người dùng. Bộ nhớ đệm có tên sessions, clientSessions, offlineSessions и offlineClientSessions, thường được sao chép giữa các trung tâm dữ liệu và dùng để lưu trữ dữ liệu về các phiên người dùng đang hoạt động trong khi người dùng đang hoạt động trên trình duyệt. Các bộ đệm này hoạt động cùng với ứng dụng xử lý các yêu cầu HTTP từ người dùng cuối, do đó chúng được liên kết với các phiên cố định và phải được sao chép giữa các trung tâm dữ liệu.

Bảo vệ vũ lực. Bộ nhớ đệm loginFailures Được sử dụng để theo dõi dữ liệu lỗi đăng nhập, chẳng hạn như số lần người dùng nhập sai mật khẩu. Việc sao chép bộ đệm này là trách nhiệm của quản trị viên. Nhưng để tính toán chính xác, cần kích hoạt tính năng sao chép giữa các trung tâm dữ liệu. Nhưng mặt khác, nếu bạn không sao chép dữ liệu này, bạn sẽ cải thiện hiệu suất và nếu vấn đề này phát sinh, tính năng sao chép có thể không được kích hoạt.

Khi triển khai cụm Infinispan, bạn cần thêm định nghĩa bộ đệm vào tệp cài đặt:

<replicated-cache-configuration name="keycloak-sessions" mode="ASYNC" start="EAGER" batching="false">
</replicated-cache-configuration>

<replicated-cache name="work" configuration="keycloak-sessions" />
<replicated-cache name="sessions" configuration="keycloak-sessions" />
<replicated-cache name="offlineSessions" configuration="keycloak-sessions" />
<replicated-cache name="actionTokens" configuration="keycloak-sessions" />
<replicated-cache name="loginFailures" configuration="keycloak-sessions" />
<replicated-cache name="clientSessions" configuration="keycloak-sessions" />
<replicated-cache name="offlineClientSessions" configuration="keycloak-sessions" />

Bạn phải định cấu hình và khởi động cụm Infinispan trước khi khởi động cụm Keycloak

Sau đó, bạn cần phải cấu hình remoteStore cho bộ đệm Keycloak. Để làm điều này, chỉ cần một tập lệnh, được thực hiện tương tự như tập lệnh trước đó, được sử dụng để đặt biến CACHE_OWNERS, bạn cần lưu nó vào một tập tin và đặt nó vào một thư mục /opt/jboss/startup-scripts:

Nội dung tập lệnh

embed-server --server-config=standalone-ha.xml --std-out=echo
batch

echo *** Update infinispan subsystem ***
/subsystem=infinispan/cache-container=keycloak:write-attribute(name=module, value=org.keycloak.keycloak-model-infinispan)

echo ** Add remote socket binding to infinispan server **
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-cache:add(host=${remote.cache.host:localhost}, port=${remote.cache.port:11222})

echo ** Update replicated-cache work element **
/subsystem=infinispan/cache-container=keycloak/replicated-cache=work/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=work, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)

/subsystem=infinispan/cache-container=keycloak/replicated-cache=work:write-attribute(name=statistics-enabled,value=true)

echo ** Update distributed-cache sessions element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessions/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=sessions, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessions:write-attribute(name=statistics-enabled,value=true)

echo ** Update distributed-cache offlineSessions element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=offlineSessions, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions:write-attribute(name=statistics-enabled,value=true)

echo ** Update distributed-cache clientSessions element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=clientSessions, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions:write-attribute(name=statistics-enabled,value=true)

echo ** Update distributed-cache offlineClientSessions element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=offlineClientSessions, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions:write-attribute(name=statistics-enabled,value=true)

echo ** Update distributed-cache loginFailures element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    remote-servers=["remote-cache"], 
    cache=loginFailures, 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures:write-attribute(name=statistics-enabled,value=true)

echo ** Update distributed-cache actionTokens element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=actionTokens/store=remote:add( 
    passivation=false, 
    fetch-state=false, 
    purge=false, 
    preload=false, 
    shared=true, 
    cache=actionTokens, 
    remote-servers=["remote-cache"], 
    properties={ 
        rawValues=true, 
        marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory, 
        protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion} 
    } 
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=actionTokens:write-attribute(name=statistics-enabled,value=true)

echo ** Update distributed-cache authenticationSessions element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=authenticationSessions:write-attribute(name=statistics-enabled,value=true)

echo *** Update undertow subsystem ***
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=proxy-address-forwarding,value=true)

run-batch
stop-embedded-server

Đừng quên cài đặt JAVA_OPTS để các nút Keycloak chạy HotRod: remote.cache.host, remote.cache.port và tên dịch vụ jboss.site.name.

Liên kết và tài liệu bổ sung

Bài viết được nhân viên dịch và chuẩn bị cho Habr Trung tâm đào tạo Slurm — các khóa học chuyên sâu, khóa học video và đào tạo doanh nghiệp từ các chuyên gia thực hành (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE)

Nguồn: www.habr.com

Chạy Keycloak ở chế độ HA trên Kubernetes