درست است، پس از آزادی در ابتدای ماه مه 2019، در Consul می‌توانید برنامه‌ها و سرویس‌های در حال اجرا در Kubernetes را به صورت بومی مجاز کنید.
در این آموزش گام به گام ایجاد خواهیم کرد (اثبات مفهوم، PoC) این ویژگی جدید را نشان می دهد. انتظار می رود شما دانش اولیه Kubernetes و کنسول Hashicorp را داشته باشید. در حالی که می توانید از هر پلتفرم ابری یا محیط داخلی استفاده کنید، در این آموزش ما از پلتفرم ابری Google استفاده خواهیم کرد.
مرور
اگر بریم به ، یک مرور کلی سریع از هدف و مورد استفاده آن و همچنین برخی جزئیات فنی و یک نمای کلی از منطق دریافت خواهیم کرد. من به شدت توصیه می کنم حداقل یک بار قبل از ادامه آن را بخوانید، زیرا اکنون همه آن را توضیح می دهم و می جوم.
نمودار 1: نمای کلی از روش مجوز کنسول
بیایید نگاه کنیم .
مطمئناً، اطلاعات مفیدی در آنجا وجود دارد، اما هیچ راهنمایی در مورد نحوه استفاده واقعی از همه آنها وجود ندارد. بنابراین، مانند هر فرد عاقلی، شما اینترنت را برای راهنمایی جستجو می کنید. و سپس ... شما شکست می خورید. اتفاق می افتد. بیایید این را درست کنیم.
قبل از اینکه به ایجاد POC خود بپردازیم، اجازه دهید به مرور کلی روش‌های مجوز کنسول (نمودار 1) برگردیم و آن را در چارچوب Kubernetes اصلاح کنیم.
معماری
در این آموزش، ما یک سرور Consul را در یک ماشین جداگانه ایجاد می کنیم که با یک کلاستر Kubernetes با مشتری Consul نصب شده ارتباط برقرار می کند. سپس ما برنامه ساختگی خود را در غلاف ایجاد می کنیم و از روش مجوز پیکربندی شده خود برای خواندن از فروشگاه کلید/مقدار کنسول خود استفاده می کنیم.
نمودار زیر جزئیات معماری ای که ما در این آموزش ایجاد می کنیم و همچنین منطق پشت روش مجوز را که بعدا توضیح داده خواهد شد، نشان می دهد.
نمودار 2: مروری بر روش مجوز Kubernetes
یک نکته سریع: سرور Consul برای این کار لازم نیست خارج از خوشه Kubernetes زندگی کند. اما بله، او می تواند این کار را به این صورت انجام دهد.
بنابراین، با گرفتن نمودار نمای کلی کنسول (نمودار 1) و اعمال Kubernetes بر روی آن، نمودار بالا (نمودار 2) را دریافت می کنیم، و منطق در اینجا به شرح زیر است:
- هر پاد دارای یک حساب سرویس متصل به آن است که حاوی یک توکن JWT است که توسط Kubernetes تولید و شناخته شده است. این توکن نیز به صورت پیش فرض در پاد قرار می گیرد.
- برنامه یا سرویس ما در داخل پاد، یک فرمان ورود به سیستم را برای مشتری کنسول ما آغاز می کند. درخواست ورود همچنین شامل رمز و نام ما خواهد بود به طور خاص ایجاد شده است روش مجوز (نوع Kubernetes). این مرحله شماره 2 با مرحله 1 نمودار کنسول (طرح 1) مطابقت دارد.
- مشتری کنسول ما سپس این درخواست را به سرور کنسول ما ارسال می کند.
- شعبده بازي! اینجاست که سرور کنسول صحت درخواست را تأیید می کند، اطلاعات مربوط به هویت درخواست را جمع آوری می کند و آن را با قوانین از پیش تعریف شده مرتبط مقایسه می کند. در زیر نمودار دیگری برای نشان دادن این موضوع وجود دارد. این مرحله با مراحل 3، 4 و 5 نمودار نمای کلی کنسول (نمودار 1) مطابقت دارد.
- سرور کنسول ما یک توکن Consul با مجوزهای مطابق با قوانین روش مجوز مشخص شده ما (که ما تعریف کرده ایم) در مورد هویت درخواست کننده تولید می کند. سپس آن توکن را پس می فرستد. این مربوط به مرحله 6 از نمودار کنسول (نمودار 1) است.
- مشتری کنسول ما توکن را به برنامه یا خدمات درخواست کننده ارسال می کند.
برنامه یا سرویس ما اکنون می‌تواند از این رمز کنسول برای برقراری ارتباط با داده‌های کنسول ما، همانطور که توسط امتیازات رمز تعیین می‌شود، استفاده کند.
جادو آشکار شد!
برای آنهایی از شما که فقط با یک خرگوش از کلاه راضی نیستید و می خواهید بدانید که چگونه کار می کند ... اجازه دهید "به شما نشان دهم که چقدر عمیق است. لانه خرگوش'.
همانطور که قبلاً ذکر شد، مرحله "جادویی" ما (شکل 2: مرحله 4) جایی است که سرور کنسول درخواست را تأیید می کند، اطلاعات مربوط به درخواست را جمع آوری می کند و آن را با قوانین از پیش تعریف شده مرتبط مقایسه می کند. این مرحله با مراحل 3، 4 و 5 نمودار نمای کلی کنسول (نمودار 1) مطابقت دارد. در زیر یک نمودار (نمودار 3) وجود دارد که هدف آن نشان دادن واضح آنچه در واقع اتفاق می افتد است. در زیر کاپوت روش خاص مجوز Kubernetes.
نمودار 3: جادو آشکار شد!
- به عنوان نقطه شروع، مشتری کنسول ما درخواست ورود به سیستم را با رمز حساب Kubernetes و نام نمونه خاص روش مجوزی که قبلا ایجاد شده بود به سرور کنسول ما ارسال می کند. این مرحله مطابق با مرحله 3 در توضیحات مدار قبلی است.
- اکنون سرور کنسول (یا رهبر) باید صحت توکن دریافتی را تأیید کند. بنابراین، با خوشه Kubernetes (از طریق مشتری Consul) مشورت خواهد کرد و با مجوزهای مناسب، متوجه خواهیم شد که آیا توکن واقعی است و به چه کسی تعلق دارد.
- سپس درخواست تایید شده به رهبر کنسول بازگردانده می شود و سرور کنسول نمونه روش مجوز را با نام مشخص شده از درخواست ورود (و نوع Kubernetes) جستجو می کند.
- رهبر کنسول نمونه روش تعیین شده مجوز را (در صورت یافتن) شناسایی می کند و مجموعه قوانین الزام آور را که به آن ضمیمه شده است می خواند. سپس این قوانین را می خواند و آنها را با ویژگی های هویت تأیید شده مقایسه می کند.
- TA-dah! بیایید به مرحله 5 در توضیحات مدار قبلی برویم.
Consul-server را روی یک ماشین مجازی معمولی اجرا کنید
از این به بعد، من عمدتاً دستورالعمل هایی را در مورد نحوه ایجاد این POC، اغلب در نقاط گلوله، بدون توضیحات کامل جمله ارائه خواهم کرد. همچنین، همانطور که قبلا ذکر شد، من از GCP برای ایجاد تمام زیرساخت ها استفاده خواهم کرد، اما شما می توانید همان زیرساخت را در هر جای دیگری ایجاد کنید.
- ماشین مجازی (نمونه/سرور) را راه اندازی کنید.
- یک قانون برای فایروال (گروه امنیتی در AWS) ایجاد کنید:
- من دوست دارم یک نام ماشین را هم به قانون و هم به تگ شبکه اختصاص دهم، در این مورد "skywiz-consul-server-poc".
- آدرس IP رایانه محلی خود را پیدا کنید و آن را به لیست آدرس های IP منبع اضافه کنید تا بتوانیم به رابط کاربری (UI) دسترسی پیدا کنیم.
- پورت 8500 را برای رابط کاربری باز کنید. روی ایجاد کلیک کنید. ما به زودی دوباره این فایروال را تغییر خواهیم داد [].
- یک قانون فایروال را به نمونه اضافه کنید. به داشبورد VM در Consul Server برگردید و "skywiz-consul-server-poc" را به قسمت برچسب های شبکه اضافه کنید. روی ذخیره کلیک کنید.
- Consul را روی ماشین مجازی نصب کنید، اینجا را بررسی کنید. به یاد داشته باشید که به نسخه کنسول ≥ 1.5 نیاز دارید [لینک]
- بیایید یک Node Consul ایجاد کنیم - پیکربندی به شرح زیر است.
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- برای راهنمای دقیق تر در مورد نصب کنسول و راه اندازی یک کلاستر از 3 گره، نگاه کنید .
- یک فایل /etc/consul.d/agent.json به صورت زیر ایجاد کنید []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- سرور کنسول ما را راه اندازی کنید:
consul agent
-server
-ui
-client 0.0.0.0
-data-dir=/var/lib/consul
-bootstrap-expect=1
-config-dir=/etc/consul.d- شما باید یک دسته از خروجی ها را ببینید و در نهایت با "... به روز رسانی مسدود شده توسط ACLs" خاتمه دهید.
- آدرس IP خارجی سرور Consul را پیدا کنید و یک مرورگر با این آدرس IP در پورت 8500 باز کنید. مطمئن شوید که UI باز است.
- سعی کنید یک جفت کلید/مقدار اضافه کنید. حتما اشتباهی هست این به این دلیل است که ما سرور Consul را با یک ACL بارگذاری کردیم و همه قوانین را غیرفعال کردیم.
- به پوسته خود در سرور Consul برگردید و فرآیند را در پس زمینه یا روش دیگری برای اجرای آن شروع کنید و موارد زیر را وارد کنید:
consul acl bootstrap- مقدار "SecretID" را پیدا کنید و به UI برگردید. در برگه ACL، شناسه مخفی رمزی را که به تازگی کپی کرده اید وارد کنید. SecretID را در جای دیگری کپی کنید، بعداً به آن نیاز خواهیم داشت.
- حالا یک جفت کلید/مقدار اضافه کنید. برای این POC، کلید زیر را اضافه کنید: "custom-ns/test_key"، مقدار: "I'm in the custom-ns folder!"
راه اندازی یک خوشه Kubernetes برای برنامه ما با مشتری Consul به عنوان Daemonset
- یک خوشه K8s (Kubernetes) ایجاد کنید. برای دسترسی سریع‌تر، آن را در همان ناحیه سرور ایجاد می‌کنیم، و بنابراین می‌توانیم از همان زیرشبکه برای اتصال آسان با آدرس‌های IP داخلی استفاده کنیم. ما آن را "skywiz-app-with-consul-client-poc" می نامیم.
- به عنوان نکته جانبی، در اینجا یک آموزش خوب است که من هنگام راه اندازی یک کلاستر POC Consul با Consul Connect با آن مواجه شدم.
- ما همچنین از نمودار فرمان Hashicorp با یک فایل مقادیر توسعه یافته استفاده خواهیم کرد.
- Helm را نصب و پیکربندی کنید. مراحل پیکربندی:
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- نمودار فرمان:
- از فایل مقدار زیر استفاده کنید (توجه داشته باشید که من بیشتر آن را غیرفعال کرده ام):
### 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- اعمال نمودار فرمان:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- وقتی سعی می کند اجرا شود، به مجوزهایی برای سرور Consul نیاز دارد، بنابراین اجازه دهید آنها را اضافه کنیم.
- به "محدوده آدرس پاد" واقع در داشبورد خوشه توجه کنید و به قانون فایروال "skywiz-consul-server-poc" ما مراجعه کنید.
- محدوده آدرس پاد را به لیست آدرس های IP اضافه کنید و پورت های 8301 و 8300 را باز کنید.
- به Consul UI بروید و بعد از چند دقیقه می بینید که خوشه ما در تب nodes ظاهر می شود.
پیکربندی یک روش مجوز با ادغام کنسول با Kubernetes
- به پوسته سرور Consul برگردید و رمزی را که قبلاً ذخیره کرده اید صادر کنید:
export CONSUL_HTTP_TOKEN=<SecretID>- برای ایجاد نمونه ای از متد احراز هویت، به اطلاعاتی از خوشه Kubernetes نیاز داریم:
- kubernetes-host
kubectl get endpoints | grep kubernetes- kubernetes-service-account-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:- این توکن دارای کد base64 است، بنابراین با استفاده از ابزار مورد علاقه خود، آن را رمزگشایی کنید []
- kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:- گواهی “ca.crt” را بردارید (پس از رمزگشایی base64) و آن را در فایل “ca.crt” بنویسید.
- اکنون متد auth را نمونه‌سازی کنید، جای جای‌بان‌ها را با مقادیری که تازه دریافت کرده‌اید جایگزین کنید.
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>"- در مرحله بعد باید یک قانون ایجاد کنیم و آن را به نقش جدید متصل کنیم. برای این قسمت می توانید از Consul UI استفاده کنید، اما ما از خط فرمان استفاده می کنیم.
- یک قانون بنویس
### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
policy = "write"
}- قانون را اعمال کنید
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- شناسه قانونی را که به تازگی ایجاد کرده اید از خروجی پیدا کنید.
- با یک قانون جدید یک نقش ایجاد کنید.
consul acl role create
-name "custom-ns-role"
-description "This is an example role for custom-ns namespace"
-policy-id <policy_id>- اکنون نقش جدید خود را با نمونه روش auth مرتبط می کنیم. توجه داشته باشید که پرچم "انتخاب کننده" تعیین می کند که آیا درخواست ورود ما این نقش را دریافت می کند یا خیر. برای سایر گزینه های انتخابگر اینجا را بررسی کنید:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'آخرین تنظیمات
حقوق دسترسی
- ایجاد حقوق دسترسی ما باید به کنسول اجازه دهیم تا هویت توکن حساب سرویس K8s را تأیید و شناسایی کند.
- موارد زیر را در فایل بنویسید :
###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- بیایید حقوق دسترسی ایجاد کنیم
kubectl create -f skywiz-poc-consul-server_rbac.yamlاتصال به مشتری کنسول
- همانطور که اشاره شد چندین گزینه برای اتصال به daemonset وجود دارد، اما ما به راه حل ساده زیر می رویم:
- فایل زیر را اعمال کنید [].
### 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- سپس از دستور داخلی زیر برای ایجاد یک configmap استفاده کنید []. لطفا توجه داشته باشید که ما به نام سرویس خود اشاره می کنیم، در صورت لزوم آن را جایگزین کنید.
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}')"]}
EOFتست روش auth
حالا بیایید جادو را در عمل ببینیم!
- چندین پوشه کلید دیگر را با همان کلید سطح بالا ایجاد کنید (یعنی /sample_key) و مقدار دلخواه شما. سیاست ها و نقش های مناسب برای مسیرهای کلیدی جدید ایجاد کنید. ما بعداً اتصالات را انجام می دهیم.
تست فضای نام سفارشی:
- بیایید فضای نام خود را ایجاد کنیم:
kubectl create namespace custom-ns- بیایید یک 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- ایجاد تحت:
kubectl create -f poc-ubuntu-custom-ns.yaml- هنگامی که ظرف در حال اجرا است، به آنجا بروید و curl را نصب کنید.
kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y- اکنون با استفاده از روش مجوزی که قبلا ایجاد کردیم، یک درخواست ورود به کنسول ارسال می کنیم [].
- برای مشاهده رمز وارد شده از حساب سرویس خود:
cat /run/secrets/kubernetes.io/serviceaccount/token- موارد زیر را در یک فایل داخل ظرف بنویسید:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- وارد شدن!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- برای تکمیل مراحل بالا در یک خط (از آنجایی که ما چندین تست را اجرا خواهیم کرد)، می توانید موارد زیر را انجام دهید:
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- آثار! حداقل باید. اکنون SecretID را بردارید و سعی کنید به کلید/مقداری که باید به آن دسترسی داشته باشیم دسترسی پیدا کنید.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”- می‌توانید در base64 «Value» را رمزگشایی کنید و ببینید که با مقدار custom-ns/test_key در رابط کاربری مطابقت دارد. اگر از همان مقدار بالا در این آموزش استفاده کرده اید، مقدار کدگذاری شده شما IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi خواهد بود.
تست حساب سرویس کاربر:
- با استفاده از دستور زیر یک ServiceAccount سفارشی ایجاد کنید [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- یک فایل پیکربندی جدید برای pod ایجاد کنید. لطفاً توجه داشته باشید که من نصب curl را برای صرفه جویی در کار اضافه کردم :)
###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- پس از آن، یک پوسته را در داخل ظرف اجرا کنید.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- وارد شدن!
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- اجازه رد شد. اوه، ما فراموش کرده‌ایم یک قوانین جدید الزام آور با مجوزهای مناسب اضافه کنیم، بیایید این کار را اکنون انجام دهیم.
مراحل قبلی بالا را تکرار کنید:
الف) یک سیاست یکسان برای پیشوند "custom-sa/" ایجاد کنید.
ب) یک نقش ایجاد کنید، آن را "نقش سفارشی" نامید.
ج) خط مشی را به نقش ضمیمه کنید.
- یک Rule-Binding ایجاد کنید (فقط از cli/api امکان پذیر است). به معنی متفاوت پرچم انتخاب توجه کنید.
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-sa-role'
-selector='serviceaccount.name=="custom-sa"'- دوباره از ظرف "poc-ubuntu-custom-sa" وارد شوید. موفقیت!
- دسترسی ما به مسیر کلید سفارشی-sa/ را بررسی کنید.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”- همچنین می توانید اطمینان حاصل کنید که این توکن به kv در "custom-ns/" دسترسی نمی دهد. فقط بعد از جایگزینی "custom-sa" با پیشوند "custom-ns" دستور بالا را تکرار کنید.
اجازه رد شد.
مثال همپوشانی:
- شایان ذکر است که تمامی نگاشت‌های الزام‌آور قوانین با این حقوق به توکن اضافه خواهند شد.
- ظرف ما "poc-ubuntu-custom-sa" در فضای نام پیش‌فرض قرار دارد - بنابراین بیایید از آن برای یک قاعده‌بندی متفاوت استفاده کنیم.
- مراحل قبلی را تکرار کنید:
الف) یک سیاست یکسان برای پیشوند کلید "پیش فرض/" ایجاد کنید.
ب) یک نقش ایجاد کنید، نام آن را "default-ns-role" بگذارید.
ج) خط مشی را به نقش ضمیمه کنید. - ایجاد یک Rule-Binding (فقط از 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"'- به ظرف "poc-ubuntu-custom-sa" خود برگردید و سعی کنید به مسیر kv "default/" دسترسی پیدا کنید.
- اجازه رد شد.
می توانید اعتبار مشخص شده برای هر نشانه را در UI در زیر ACL > Tokens مشاهده کنید. همانطور که می بینید، توکن فعلی ما فقط یک «نقش سفارشی» به آن متصل است. رمزی که ما در حال حاضر از آن استفاده می کنیم، هنگام ورود به سیستم ایجاد شد و تنها یک قانون الزام آور وجود داشت که با آن زمان مطابقت داشت. باید دوباره لاگین کنیم و از توکن جدید استفاده کنیم. - مطمئن شوید که می توانید از هر دو مسیر kv "custom-sa/" و "default/" بخوانید.
انجام شد!
این به این دلیل است که "poc-ubuntu-custom-sa" ما با قوانین "custom-sa" و "default-ns" مطابقت دارد.
نتیجه
توکن TTL mgmt؟
در زمان نگارش این مقاله، هیچ روش یکپارچه ای برای تعیین TTL برای توکن های تولید شده توسط این روش مجوز وجود ندارد. این یک فرصت فوق العاده برای ارائه اتوماسیون ایمن مجوز کنسول خواهد بود.
گزینه ای برای ایجاد دستی توکن با TTL وجود دارد:
زمان انقضا - زمانی که این توکن باطل می شود. (اختیاری؛ اضافه شده در کنسول 1.5.0)- فقط برای ایجاد/به‌روزرسانی دستی وجود دارد
امیدواریم در آینده نزدیک بتوانیم نحوه تولید توکن‌ها (بر اساس قانون یا روش مجوز) را کنترل کرده و TTL را اضافه کنیم.
تا آن زمان، پیشنهاد می شود از یک نقطه پایان خروج در منطق خود استفاده کنید.
همچنین سایر مقالات وبلاگ ما را بخوانید:
منبع: www.habr.com