Đúng vậy, sau khi phát hành vào đầu tháng 2019 năm XNUMX, tại Consul, bạn có thể ủy quyền cho các ứng dụng và dịch vụ chạy nguyên bản trên Kubernetes.
Trong hướng dẫn này, chúng ta sẽ tạo từng bước (Bằng chứng về khái niệm, PoC) thể hiện tính năng mới này. Bạn cần có kiến thức cơ bản về Kubernetes và Lãnh sự của Hashicorp. Mặc dù bạn có thể sử dụng bất kỳ nền tảng đám mây hoặc môi trường tại chỗ nào, nhưng trong hướng dẫn này, chúng tôi sẽ sử dụng Nền tảng đám mây của Google.
Xem xét
Nếu chúng ta đi đến , chúng ta sẽ có cái nhìn tổng quan nhanh về mục đích và trường hợp sử dụng của nó, cũng như một số chi tiết kỹ thuật và tổng quan chung về logic. Tôi thực sự khuyên bạn nên đọc nó ít nhất một lần trước khi tiếp tục, vì bây giờ tôi sẽ giải thích và nghiền ngẫm tất cả.
Sơ đồ 1: Tổng quan chính thức về phương thức ủy quyền Lãnh sự
Hãy nhìn vào .
Chắc chắn là có thông tin hữu ích ở đó nhưng không có hướng dẫn nào về cách sử dụng tất cả những thông tin đó. Vì vậy, giống như bất kỳ người tỉnh táo nào, bạn lùng sục trên Internet để tìm hướng dẫn. Và rồi... Bạn thất bại. Nó xảy ra. Hãy khắc phục điều này.
Trước khi chuyển sang tạo POC, hãy quay lại tổng quan về các phương thức ủy quyền của Consul (Sơ đồ 1) và tinh chỉnh nó trong bối cảnh Kubernetes.
kiến trúc
Trong hướng dẫn này, chúng ta sẽ tạo một máy chủ Consul trên một máy riêng biệt sẽ giao tiếp với cụm Kubernetes đã cài đặt ứng dụng khách Consul. Sau đó, chúng tôi sẽ tạo ứng dụng giả của mình trong nhóm và sử dụng phương thức ủy quyền đã định cấu hình của chúng tôi để đọc từ kho lưu trữ khóa/giá trị Consul của chúng tôi.
Sơ đồ bên dưới mô tả chi tiết kiến trúc mà chúng ta đang tạo trong hướng dẫn này, cũng như logic đằng sau phương thức ủy quyền, điều này sẽ được giải thích sau.
Sơ đồ 2: Tổng quan về phương thức ủy quyền Kubernetes
Lưu ý nhanh: máy chủ Lãnh sự không cần phải nằm bên ngoài cụm Kubernetes để hoạt động. Nhưng vâng, anh ấy có thể làm theo cách này và cách kia.
Vì vậy, lấy sơ đồ tổng quan Consul (Sơ đồ 1) và áp dụng Kubernetes vào đó, chúng ta có được sơ đồ trên (Sơ đồ 2) và logic ở đây như sau:
- Mỗi nhóm sẽ có một tài khoản dịch vụ được đính kèm với nó chứa mã thông báo JWT do Kubernetes tạo và biết. Mã thông báo này cũng được chèn vào nhóm theo mặc định.
- Ứng dụng hoặc dịch vụ của chúng tôi bên trong nhóm sẽ khởi tạo lệnh đăng nhập vào ứng dụng khách Lãnh sự của chúng tôi. Yêu cầu đăng nhập cũng sẽ bao gồm mã thông báo và tên của chúng tôi được tạo ra đặc biệt phương thức ủy quyền (loại Kubernetes). Bước số 2 này tương ứng với bước 1 của sơ đồ Lãnh sự (Kế hoạch 1).
- Sau đó, khách hàng Lãnh sự của chúng tôi sẽ chuyển tiếp yêu cầu này đến máy chủ Lãnh sự của chúng tôi.
- ẢO THUẬT! Đây là nơi máy chủ Lãnh sự xác minh tính xác thực của yêu cầu, thu thập thông tin về danh tính của yêu cầu và so sánh nó với bất kỳ quy tắc liên quan nào được xác định trước. Dưới đây là một sơ đồ khác để minh họa điều này. Bước này tương ứng với bước 3, 4 và 5 của Sơ đồ tổng quan Lãnh sự (Sơ đồ 1).
- Máy chủ Lãnh sự của chúng tôi tạo mã thông báo Lãnh sự với các quyền theo quy tắc phương thức ủy quyền được chỉ định của chúng tôi (mà chúng tôi đã xác định) liên quan đến danh tính của người yêu cầu. Sau đó nó sẽ gửi lại mã thông báo đó. Điều này tương ứng với bước 6 của sơ đồ Lãnh sự (Sơ đồ 1).
- Khách hàng Lãnh sự của chúng tôi chuyển tiếp mã thông báo đến ứng dụng hoặc dịch vụ yêu cầu.
Ứng dụng hoặc dịch vụ của chúng tôi hiện có thể sử dụng mã thông báo Lãnh sự này để liên lạc với dữ liệu Lãnh sự của chúng tôi, như được xác định bởi các đặc quyền của mã thông báo.
Phép thuật được tiết lộ!
Dành cho những ai không hài lòng với việc chỉ có một con thỏ đội mũ và muốn biết nó hoạt động như thế nào... hãy để tôi "chỉ cho bạn thấy nó sâu sắc đến mức nào" hang thỏ'.
Như đã đề cập trước đó, bước "ma thuật" của chúng tôi (Hình 2: Bước 4) là nơi máy chủ Lãnh sự xác thực yêu cầu, thu thập thông tin về yêu cầu và so sánh nó với bất kỳ quy tắc liên quan nào được xác định trước. Bước này tương ứng với bước 3, 4 và 5 của Sơ đồ tổng quan Lãnh sự (Sơ đồ 1). Dưới đây là sơ đồ (Biểu đồ 3), mục đích là thể hiện rõ ràng những gì đang thực sự xảy ra dưới mui xe phương pháp ủy quyền Kubernetes cụ thể.
Sơ đồ 3: Điều kỳ diệu được tiết lộ!
- Để bắt đầu, ứng dụng khách Consul của chúng tôi chuyển tiếp yêu cầu đăng nhập đến máy chủ Consul của chúng tôi bằng mã thông báo tài khoản Kubernetes và tên phiên bản cụ thể của phương thức ủy quyền đã được tạo trước đó. Bước này tương ứng với bước 3 trong phần giải thích mạch trước đó.
- Bây giờ máy chủ Lãnh sự (hoặc người lãnh đạo) cần xác minh tính xác thực của mã thông báo nhận được. Do đó, nó sẽ tham khảo cụm Kubernetes (thông qua ứng dụng Consul) và với các quyền thích hợp, chúng tôi sẽ tìm hiểu xem mã thông báo có phải là chính hãng hay không và nó thuộc về ai.
- Sau đó, yêu cầu được xác thực sẽ được trả về cho lãnh đạo Lãnh sự và máy chủ Lãnh sự tra cứu phiên bản phương thức ủy quyền với tên được chỉ định từ yêu cầu đăng nhập (và loại Kubernetes).
- Lãnh đạo lãnh sự xác định trường hợp phương thức ủy quyền được chỉ định (nếu tìm thấy) và đọc bộ quy tắc ràng buộc được đính kèm với nó. Sau đó, nó đọc các quy tắc này và so sánh chúng với các thuộc tính nhận dạng đã được xác minh.
- TA-dah! Hãy chuyển sang bước 5 trong phần giải thích mạch trước.
Chạy Consul-server trên máy ảo thông thường
Từ giờ trở đi, tôi chủ yếu sẽ đưa ra hướng dẫn về cách tạo POC này, thường bằng các dấu đầu dòng, không có giải thích đầy đủ bằng câu. Ngoài ra, như đã lưu ý trước đó, tôi sẽ sử dụng GCP để tạo tất cả cơ sở hạ tầng, nhưng bạn có thể tạo cơ sở hạ tầng tương tự ở bất kỳ nơi nào khác.
- Khởi động máy ảo (instance/server).
- Tạo quy tắc cho tường lửa (nhóm bảo mật trong AWS):
- Tôi muốn gán cùng một tên máy cho cả quy tắc và thẻ mạng, trong trường hợp này là "skywiz-consul-server-poc".
- Tìm địa chỉ IP máy tính cục bộ của bạn và thêm nó vào danh sách địa chỉ IP nguồn để chúng ta có thể truy cập vào giao diện người dùng (UI).
- Mở cổng 8500 cho giao diện người dùng. Nhấp vào Tạo. Chúng tôi sẽ sớm thay đổi lại tường lửa này [].
- Thêm quy tắc tường lửa vào phiên bản. Quay lại bảng điều khiển VM trên Máy chủ Consul và thêm “skywiz-consul-server-poc” vào trường thẻ mạng. Nhấp vào để lưu.
- Cài đặt Consul trên máy ảo, kiểm tra tại đây. Hãy nhớ rằng bạn cần phiên bản Lãnh sự ≥ 1.5 [link]
- Hãy tạo một nút Consul - cấu hình như sau.
groupadd --system consul
useradd -s /sbin/nologin --system -g consul consul
mkdir -p /var/lib/consul
chown -R consul:consul /var/lib/consul
chmod -R 775 /var/lib/consul
mkdir /etc/consul.d
chown -R consul:consul /etc/consul.d- Để có hướng dẫn chi tiết hơn về cách cài đặt Consul và thiết lập cụm 3 nút, hãy xem .
- Tạo một tệp /etc/consul.d/agent.json như sau []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- Bắt đầu máy chủ Lãnh sự của chúng tôi:
consul agent
-server
-ui
-client 0.0.0.0
-data-dir=/var/lib/consul
-bootstrap-expect=1
-config-dir=/etc/consul.d- Bạn sẽ thấy một loạt kết quả đầu ra và kết thúc bằng “... bản cập nhật bị chặn bởi ACL”.
- Tìm địa chỉ IP bên ngoài của máy chủ Lãnh sự và mở trình duyệt có địa chỉ IP này trên cổng 8500. Đảm bảo rằng giao diện người dùng mở ra.
- Hãy thử thêm cặp khóa/giá trị. Chắc chắn có sai sót. Điều này là do chúng tôi đã tải ACL vào máy chủ Lãnh sự và vô hiệu hóa tất cả các quy tắc.
- Quay trở lại shell của bạn trên máy chủ Lãnh sự và bắt đầu quá trình ở chế độ nền hoặc một số cách khác để chạy nó và nhập thông tin sau:
consul acl bootstrap- Tìm giá trị "SecretID" và quay lại giao diện người dùng. Trong tab ACL, nhập ID bí mật của mã thông báo bạn vừa sao chép. Sao chép SecretID ra nơi khác, sau này chúng ta sẽ cần.
- Bây giờ hãy thêm cặp khóa/giá trị. Đối với POC này, hãy thêm thông tin sau: key: “custom-ns/test_key”, value: “Tôi đang ở trong thư mục custom-ns!”
Khởi chạy cụm Kubernetes cho ứng dụng của chúng tôi với ứng dụng khách Consul dưới dạng Daemonset
- Tạo cụm K8s (Kubernetes). Chúng tôi sẽ tạo nó trong cùng vùng với máy chủ để truy cập nhanh hơn và vì vậy chúng tôi có thể sử dụng cùng một mạng con để dễ dàng kết nối với các địa chỉ IP nội bộ. Chúng tôi sẽ gọi nó là "skywiz-app-with-consul-client-poc".
- Xin lưu ý thêm, đây là một hướng dẫn hay mà tôi đã xem khi thiết lập cụm Lãnh sự POC với Consul Connect.
- Chúng tôi cũng sẽ sử dụng biểu đồ hỗ trợ Hashicorp với tệp giá trị mở rộng.
- Cài đặt và cấu hình Helm. Các bước cấu hình:
kubectl create serviceaccount tiller --namespace kube-system
kubectl create clusterrolebinding tiller-admin-binding
--clusterrole=cluster-admin --serviceaccount=kube-system:tiller
./helm init --service-account=tiller
./helm update- biểu đồ chỉ đạo:
- Sử dụng tệp giá trị sau (lưu ý tôi đã tắt hầu hết):
### poc-helm-consul-values.yaml
global:
enabled: false
image: "consul:latest"
# Expose the Consul UI through this LoadBalancer
ui:
enabled: false
# Allow Consul to inject the Connect proxy into Kubernetes containers
connectInject:
enabled: false
# Configure a Consul client on Kubernetes nodes. GRPC listener is required for Connect.
client:
enabled: true
join: ["<PRIVATE_IP_CONSUL_SERVER>"]
extraConfig: |
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}
# Minimal Consul configuration. Not suitable for production.
server:
enabled: false
# Sync Kubernetes and Consul services
syncCatalog:
enabled: false- Áp dụng biểu đồ helm:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- Khi nó cố chạy, nó sẽ cần có quyền đối với máy chủ Lãnh sự, vì vậy hãy thêm chúng.
- Lưu ý “Phạm vi địa chỉ Pod” nằm trên bảng điều khiển cụm và tham khảo lại quy tắc tường lửa “skywiz-consul-server-poc” của chúng tôi.
- Thêm dải địa chỉ cho nhóm vào danh sách địa chỉ IP và mở cổng 8301 và 8300.
- Đi tới Giao diện người dùng lãnh sự và sau vài phút, bạn sẽ thấy cụm của chúng tôi xuất hiện trong tab nút.
Định cấu hình Phương thức ủy quyền bằng cách tích hợp Lãnh sự với Kubernetes
- Quay lại shell máy chủ Lãnh sự và xuất mã thông báo bạn đã lưu trước đó:
export CONSUL_HTTP_TOKEN=<SecretID>- Chúng tôi sẽ cần thông tin từ cụm Kubernetes để tạo một phiên bản của phương thức xác thực:
- máy chủ kubernetes
kubectl get endpoints | grep kubernetes- kubernetes-service-tài khoản-jwt
kubectl get sa <helm_deployment_name>-consul-client -o yaml | grep "- name:"
kubectl get secret <secret_name_from_prev_command> -o yaml | grep token:- Mã thông báo được mã hóa base64, vì vậy hãy giải mã nó bằng công cụ yêu thích của bạn []
- kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:- Lấy chứng chỉ “ca.crt” (sau khi giải mã base64) và ghi vào file “ca.crt”.
- Bây giờ khởi tạo phương thức xác thực, thay thế phần giữ chỗ bằng các giá trị bạn vừa nhận được.
consul acl auth-method create
-type "kubernetes"
-name "auth-method-skywiz-consul-poc"
-description "This is an auth method using kubernetes for the cluster skywiz-app-with-consul-client-poc"
-kubernetes-host "<k8s_endpoint_retrieved earlier>"
[email protected]
-kubernetes-service-account-
jwt="<decoded_token_retrieved_earlier>"- Tiếp theo chúng ta cần tạo một quy tắc và gắn nó vào vai trò mới. Đối với phần này, bạn có thể sử dụng Consul UI, nhưng chúng tôi sẽ sử dụng dòng lệnh.
- Viết quy tắc
### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
policy = "write"
}- Áp dụng quy tắc
consul acl policy create
-name kv-custom-ns-policy
-description "This is an example policy for kv at custom-ns/"
-rules @kv-custom-ns-policy.hcl- Tìm ID của quy tắc bạn vừa tạo từ đầu ra.
- Tạo một vai trò với một quy tắc mới.
consul acl role create
-name "custom-ns-role"
-description "This is an example role for custom-ns namespace"
-policy-id <policy_id>- Bây giờ chúng ta sẽ liên kết vai trò mới của mình với phiên bản phương thức xác thực. Lưu ý rằng cờ "selector" xác định xem yêu cầu đăng nhập của chúng tôi có nhận được vai trò này hay không. Kiểm tra ở đây để biết các tùy chọn bộ chọn khác:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'Cấu hình cuối cùng
Quyền truy cập
- Tạo quyền truy cập. Chúng tôi cần cấp cho Lãnh sự quyền xác minh và xác định danh tính của mã thông báo tài khoản dịch vụ K8s.
- Viết nội dung sau vào tập tin :
###skywiz-poc-consul-server_rbac.yaml
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: review-tokens
namespace: default
subjects:
- kind: ServiceAccount
name: skywiz-app-with-consul-client-poc-consul-client
namespace: default
roleRef:
kind: ClusterRole
name: system:auth-delegator
apiGroup: rbac.authorization.k8s.io
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: service-account-getter
namespace: default
rules:
- apiGroups: [""]
resources: ["serviceaccounts"]
verbs: ["get"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: get-service-accounts
namespace: default
subjects:
- kind: ServiceAccount
name: skywiz-app-with-consul-client-poc-consul-client
namespace: default
roleRef:
kind: ClusterRole
name: service-account-getter
apiGroup: rbac.authorization.k8s.io- Hãy tạo quyền truy cập
kubectl create -f skywiz-poc-consul-server_rbac.yamlKết nối với khách hàng Lãnh sự
- Như đã nêu Có một số tùy chọn để kết nối với daemonset, nhưng chúng ta sẽ chuyển sang giải pháp đơn giản sau:
- Áp dụng tệp sau [].
### poc-consul-client-ds-svc.yaml
apiVersion: v1
kind: Service
metadata:
name: consul-ds-client
spec:
selector:
app: consul
chart: consul-helm
component: client
hasDNS: "true"
release: skywiz-app-with-consul-client-poc
ports:
- protocol: TCP
port: 80
targetPort: 8500- Sau đó sử dụng lệnh dựng sẵn sau để tạo configmap []. Xin lưu ý rằng chúng tôi đang đề cập đến tên dịch vụ của chúng tôi, hãy thay thế nó nếu cần thiết.
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
labels:
addonmanager.kubernetes.io/mode: EnsureExists
name: kube-dns
namespace: kube-system
data:
stubDomains: |
{"consul": ["$(kubectl get svc consul-ds-client -o jsonpath='{.spec.clusterIP}')"]}
EOFKiểm tra phương pháp xác thực
Bây giờ chúng ta hãy xem sự kỳ diệu trong hành động!
- Tạo thêm một số thư mục khóa có cùng khóa cấp cao nhất (ví dụ: /sample_key) và giá trị bạn chọn. Tạo các chính sách và vai trò phù hợp cho các đường dẫn chính mới. Chúng ta sẽ thực hiện việc đóng bìa sau.
Kiểm tra không gian tên tùy chỉnh:
- Hãy tạo không gian tên của riêng chúng ta:
kubectl create namespace custom-ns- Hãy tạo một nhóm trong không gian tên mới của chúng ta. Viết cấu hình cho pod.
###poc-ubuntu-custom-ns.yaml
apiVersion: v1
kind: Pod
metadata:
name: poc-ubuntu-custom-ns
namespace: custom-ns
spec:
containers:
- name: poc-ubuntu-custom-ns
image: ubuntu
command: ["/bin/bash", "-ec", "sleep infinity"]
restartPolicy: Never- Tạo dưới:
kubectl create -f poc-ubuntu-custom-ns.yaml- Khi vùng chứa đang chạy, hãy đến đó và cài đặt cuộn tròn.
kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y- Bây giờ chúng tôi sẽ gửi yêu cầu đăng nhập tới Lãnh sự bằng phương thức ủy quyền mà chúng tôi đã tạo trước đó [].
- Để xem mã thông báo đã nhập từ tài khoản dịch vụ của bạn:
cat /run/secrets/kubernetes.io/serviceaccount/token- Viết nội dung sau vào một tệp bên trong vùng chứa:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- Đăng nhập!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- Để hoàn thành các bước trên trong một dòng (vì chúng tôi sẽ chạy nhiều thử nghiệm), bạn có thể thực hiện như sau:
echo "{
"AuthMethod": "auth-method-skywiz-consul-poc",
"BearerToken": "$(cat /run/secrets/kubernetes.io/serviceaccount/token)"
}"
| curl
--request POST
--data @-
consul-ds-client.default.svc.cluster.local/v1/acl/login- Làm! Ít nhất thì nó nên như vậy. Bây giờ hãy lấy SecretID và thử truy cập vào khóa/giá trị mà chúng ta có quyền truy cập.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”- Bạn có thể giải mã base64 "Giá trị" và thấy rằng nó khớp với giá trị trong custom-ns/test_key trong giao diện người dùng. Nếu bạn sử dụng cùng một giá trị ở trên trong hướng dẫn này, giá trị được mã hóa của bạn sẽ là IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.
Kiểm tra tài khoản dịch vụ người dùng:
- Tạo ServiceAccount tùy chỉnh bằng lệnh sau [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Tạo một tập tin cấu hình mới cho nhóm. Xin lưu ý rằng tôi đã bao gồm cài đặt cuộn tròn để tiết kiệm nhân công :)
###poc-ubuntu-custom-sa.yaml
apiVersion: v1
kind: Pod
metadata:
name: poc-ubuntu-custom-sa
namespace: default
spec:
serviceAccountName: custom-sa
containers:
- name: poc-ubuntu-custom-sa
image: ubuntu
command: ["/bin/bash","-ec"]
args: ["apt-get update && apt-get install curl -y; sleep infinity"]
restartPolicy: Never- Sau đó, chạy shell bên trong container.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- Đăng nhập!
echo "{
"AuthMethod": "auth-method-skywiz-consul-poc",
"BearerToken": "$(cat /run/secrets/kubernetes.io/serviceaccount/token)"
}"
| curl
--request POST
--data @-
consul-ds-client.default.svc.cluster.local/v1/acl/login- Quyền bị từ chối. Ồ, chúng ta đã quên thêm một quy tắc mới ràng buộc với các quyền thích hợp, hãy thực hiện điều đó ngay bây giờ.
Lặp lại các bước trước đó ở trên:
a) Tạo Chính sách giống hệt cho tiền tố “custom-sa/”.
b) Tạo một Role, gọi là “custom-sa-role”
c) Đính kèm Chính sách vào Vai trò.
- Tạo Ràng buộc quy tắc (chỉ có thể từ cli/api). Lưu ý ý nghĩa khác nhau của cờ chọn.
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-sa-role'
-selector='serviceaccount.name=="custom-sa"'- Đăng nhập lại từ vùng chứa "poc-ubuntu-custom-sa". Thành công!
- Kiểm tra quyền truy cập của chúng tôi vào đường dẫn khóa/sa tùy chỉnh.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”- Bạn cũng có thể đảm bảo rằng mã thông báo này không cấp quyền truy cập vào kv trong "custom-ns/". Chỉ cần lặp lại lệnh trên sau khi thay thế "custom-sa" bằng tiền tố "custom-ns".
Quyền bị từ chối.
Ví dụ về lớp phủ:
- Điều đáng lưu ý là tất cả ánh xạ ràng buộc quy tắc sẽ được thêm vào mã thông báo có các quyền này.
- Vùng chứa "poc-ubuntu-custom-sa" của chúng tôi nằm trong không gian tên mặc định - vì vậy hãy sử dụng nó cho một ràng buộc quy tắc khác.
- Lặp lại các bước trước đó:
a) Tạo Chính sách giống hệt cho tiền tố khóa “mặc định/”.
b) Tạo một Role, đặt tên là “default-ns-role”
c) Đính kèm Chính sách vào Vai trò. - Tạo ràng buộc quy tắc (chỉ có thể từ cli/api)
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='default-ns-role'
-selector='serviceaccount.namespace=="default"'- Quay lại vùng chứa "poc-ubuntu-custom-sa" của chúng tôi và thử truy cập vào đường dẫn kv "default/".
- Quyền bị từ chối.
Bạn có thể xem thông tin xác thực được chỉ định cho từng mã thông báo trong giao diện người dùng trong ACL > Mã thông báo. Như bạn có thể thấy, mã thông báo hiện tại của chúng tôi chỉ có một “vai trò tùy chỉnh” được đính kèm. Mã thông báo mà chúng tôi hiện đang sử dụng đã được tạo khi chúng tôi đăng nhập và khi đó chỉ có một ràng buộc quy tắc phù hợp. Chúng tôi cần đăng nhập lại và sử dụng mã thông báo mới. - Đảm bảo bạn có thể đọc từ cả hai đường dẫn kv "custom-sa/" và "default/".
Thành công!
Điều này là do “poc-ubuntu-custom-sa” của chúng tôi khớp với các ràng buộc quy tắc “custom-sa” và “default-ns”.
Kết luận
Quản lý mã thông báo TTL?
Tại thời điểm viết bài này, không có cách tích hợp nào để xác định TTL cho mã thông báo được tạo bằng phương thức ủy quyền này. Đây sẽ là một cơ hội tuyệt vời để cung cấp sự tự động hóa an toàn cho việc ủy quyền Lãnh sự.
Có một tùy chọn để tạo mã thông báo bằng TTL theo cách thủ công:
Thời gian hết hạn - Thời điểm mã thông báo này sẽ bị thu hồi. (Tùy chọn; được thêm vào Consul 1.5.0)- Chỉ tồn tại để tạo/cập nhật thủ công
Hy vọng rằng trong tương lai gần, chúng tôi sẽ có thể kiểm soát cách tạo mã thông báo (theo quy tắc hoặc phương thức ủy quyền) và thêm TTL.
Cho đến lúc đó, bạn nên sử dụng điểm cuối đăng xuất trong logic của mình.
Cũng đọc các bài viết khác trên blog của chúng tôi:
Nguồn: www.habr.com