ProHoster > Blogs > Administrācija > Ievads Hashicorp konsula Kubernetes pilnvarojumā

Ievads Hashicorp konsula Kubernetes pilnvarojumā

Ievads Hashicorp konsula Kubernetes pilnvarojumā

TieÅ”i tā, pēc atbrÄ«voÅ”anas Hashicorp Consul 1.5.0 2019. gada maija sākumā vietnē Consul varat autorizēt lietojumprogrammas un pakalpojumus, kas darbojas Kubernetes.

Å ajā apmācÄ«bā mēs izveidosim soli pa solim POC (Proof of Concept, PoC), kas demonstrē Å”o jauno funkciju. Jums ir jābÅ«t pamatzināŔanām par Kubernetes un Hashicorp konsulu. Lai gan varat izmantot jebkuru mākoņa platformu vai lokālo vidi, Å”ajā apmācÄ«bā mēs izmantosim Google mākoņu platformu.

Pārskatiet

Ja mēs ejam uz Konsulāta dokumentācija par tā autorizācijas metodi, mēs iegÅ«sim ātru pārskatu par tā mērÄ·i un lietoÅ”anas gadÄ«jumu, kā arÄ« dažas tehniskas detaļas un vispārÄ«gu loÄ£ikas pārskatu. Es ļoti iesaku to izlasÄ«t vismaz vienu reizi, pirms turpināt, jo tagad es to visu izskaidroÅ”u un koŔļāŔu.

Ievads Hashicorp konsula Kubernetes pilnvarojumā

1. diagramma: Oficiālais pārskats par konsula autorizācijas metodi

Ieskatīsimies dokumentācija konkrētai Kubernetes autorizācijas metodei.

Protams, tur ir noderÄ«ga informācija, taču nav ceļveža, kā to visu izmantot. Tātad, kā jebkurÅ” saprātÄ«gs cilvēks, jÅ«s meklējat padomus internetā. Un tad... Jums neizdodas. Tas notiek. Labosim Å”o.

Pirms pārejam pie mūsu POC izveides, atgriezīsimies pie konsula autorizācijas metožu pārskata (1. diagramma) un precizēsim to Kubernetes kontekstā.

Arhitektūra

Å ajā apmācÄ«bā mēs izveidosim Consul serveri atseviŔķā maŔīnā, kas sazināsies ar Kubernetes klasteru ar instalētu Consul klientu. Pēc tam mēs podā izveidosim savu fiktÄ«vo lietojumprogrammu un izmantosim mÅ«su konfigurēto autorizācijas metodi, lai lasÄ«tu no mÅ«su Consul atslēgu/vērtÄ«bu krātuves.

Tālāk esoÅ”ajā diagrammā ir detalizēti aprakstÄ«ta arhitektÅ«ra, ko veidojam Å”ajā apmācÄ«bā, kā arÄ« autorizācijas metodes loÄ£ika, kas tiks izskaidrota vēlāk.

Ievads Hashicorp konsula Kubernetes pilnvarojumā

2. diagramma: Kubernetes autorizācijas metodes pārskats

ÄŖsa piezÄ«me: lai tas darbotos, Consul serverim nav jādzÄ«vo ārpus Kubernetes klastera. Bet jā, viņŔ var tā un Å”itā.

Tātad, ņemot Consul pārskata diagrammu (1. diagramma) un piemērojot tai Kubernetes, mēs iegÅ«stam iepriekÅ” redzamo diagrammu (2. diagramma), un loÄ£ika Å”eit ir Ŕāda:

  1. Katram podam būs pievienots pakalpojuma konts, kurā būs Kubernetes ģenerēts un zināms JWT marķieris. Šis marķieris pēc noklusējuma tiek ievietots arī podā.
  2. MÅ«su lietojumprogramma vai pakalpojums podā uzsāk pieteikÅ”anās komandu mÅ«su Consul klientam. PieteikÅ”anās pieprasÄ«jumā bÅ«s arÄ« mÅ«su pilnvara un vārds Ä«paÅ”i izveidots autorizācijas metode (Kubernetes tips). Å is 2. solis atbilst konsula diagrammas 1. solim (1. shēma).
  3. MÅ«su Consul klients pēc tam pārsÅ«tÄ«s Å”o pieprasÄ«jumu uz mÅ«su konsula serveri.
  4. MAÄ¢IJA! Å eit Consul serveris pārbauda pieprasÄ«juma autentiskumu, apkopo informāciju par pieprasÄ«juma identitāti un salÄ«dzina to ar jebkuriem saistÄ«tajiem iepriekÅ” definētajiem noteikumiem. Zemāk ir cita diagramma, kas to ilustrē. Å is solis atbilst 3., 4. un 5. solim konsulu pārskata diagrammā (1. diagramma).
  5. MÅ«su Consul serveris Ä£enerē Consul marÄ·ieri ar atļaujām saskaņā ar mÅ«su norādÄ«tajiem autorizācijas metodes noteikumiem (ko esam definējuÅ”i) attiecÄ«bā uz pieprasÄ«tāja identitāti. Pēc tam tas nosÅ«tÄ«s Å”o marÄ·ieri atpakaļ. Tas atbilst konsula diagrammas 6. solim (1. diagramma).
  6. Mūsu konsula klients pārsūta marķieri pieprasītājai lietojumprogrammai vai pakalpojumam.

MÅ«su lietojumprogramma vai pakalpojums tagad var izmantot Å”o Consul pilnvaru, lai sazinātos ar mÅ«su konsula datiem, kā noteikts pilnvaras privilēģijās.

Maģija ir atklāta!

Tiem no jums, kuri nav apmierināti ar truÅ”u no cepures un vēlas uzzināt, kā tas darbojas... ļaujiet man parādÄ«t, cik dziļi truÅ”a ala'.

Kā minēts iepriekÅ”, mÅ«su "maÄ£iskais" solis (2. attēls: 4. darbÄ«ba) ir tas, kurā Consul serveris autentificē pieprasÄ«jumu, apkopo informāciju par pieprasÄ«jumu un salÄ«dzina to ar jebkuriem saistÄ«tajiem iepriekÅ” definētajiem noteikumiem. Å is solis atbilst 3., 4. un 5. solim konsulu pārskata diagrammā (1. diagramma). Zemāk ir diagramma (3. diagramma), kuras mērÄ·is ir skaidri parādÄ«t, kas patiesÄ«bā notiek zem kapuces specifiska Kubernetes autorizācijas metode.

Ievads Hashicorp konsula Kubernetes pilnvarojumā

3. diagramma: Maģija ir atklāta!

  1. Sākumā mÅ«su Consul klients pārsÅ«ta pieteikÅ”anās pieprasÄ«jumu uz mÅ«su Consul serveri ar Kubernetes konta pilnvaru un iepriekÅ” izveidotās autorizācijas metodes konkrētu instances nosaukumu. Å is solis atbilst 3. darbÄ«bai iepriekŔējā ķēdes skaidrojumā.
  2. Tagad konsula serverim (vai vadÄ«tājam) ir jāpārbauda saņemtā marÄ·iera autentiskums. Tāpēc tā konsultēsies ar Kubernetes klasteru (ar Consul klienta starpniecÄ«bu) un ar atbilstoŔām atļaujām noskaidrosim, vai marÄ·ieris ir Ä«sts un kam tas pieder.
  3. Pēc tam apstiprinātais pieprasÄ«jums tiek atgriezts konsula vadÄ«tājam, un Consul serveris meklē autorizācijas metodes gadÄ«jumu ar norādÄ«to nosaukumu no pieteikÅ”anās pieprasÄ«juma (un Kubernetes veida).
  4. Konsula vadÄ«tājs identificē norādÄ«to autorizācijas metodes gadÄ«jumu (ja ir atrasts) un nolasa tai pievienoto saistoÅ”o noteikumu kopumu. Pēc tam tas nolasa Å”os noteikumus un salÄ«dzina tos ar pārbaudÄ«tajiem identitātes atribÅ«tiem.
  5. TA-dah! Pārejam uz 5. darbÄ«bu iepriekŔējā shēmas skaidrojumā.

Palaidiet Consul-serveri parastā virtuālajā maŔīnā

Turpmāk es galvenokārt sniegÅ”u norādÄ«jumus, kā izveidot Å”o POC, bieži vien aizzÄ«mju punktos, bez pilniem teikumu paskaidrojumiem. Tāpat, kā minēts iepriekÅ”, es izmantoÅ”u GCP, lai izveidotu visu infrastruktÅ«ru, taču jÅ«s varat izveidot tādu paÅ”u infrastruktÅ«ru jebkur citur.

  • Sāciet virtuālo maŔīnu (instance/serveris).

Ievads Hashicorp konsula Kubernetes pilnvarojumā

  • Izveidojiet kārtulu ugunsmÅ«rim (droŔības grupa AWS):
  • Man patÄ«k gan kārtulai, gan tÄ«kla tagam pieŔķirt vienu un to paÅ”u maŔīnas nosaukumu, Å”ajā gadÄ«jumā "skywiz-consul-server-poc".
  • Atrodiet sava lokālā datora IP adresi un pievienojiet to avota IP adreÅ”u sarakstam, lai mēs varētu piekļūt lietotāja interfeisam (UI).
  • Atveriet 8500. portu lietotāja interfeisam. NoklikŔķiniet uz Izveidot. DrÄ«zumā mēs atkal mainÄ«sim Å”o ugunsmÅ«ri [saite].
  • Pievienojiet instancē ugunsmÅ«ra kārtulu. Dodieties atpakaļ uz VM informācijas paneli vietnē Consul Server un tÄ«kla tagu laukā pievienojiet ā€œskywiz-consul-server-pocā€. NoklikŔķiniet uz Saglabāt.

Ievads Hashicorp konsula Kubernetes pilnvarojumā

  • Instalējiet Consul virtuālajā maŔīnā, pārbaudiet Å”eit. Atcerieties, ka jums ir nepiecieÅ”ama Consul versija ā‰„ 1.5 [saite]
  • Izveidosim vienu mezglu Consul - konfigurācija ir Ŕāda.

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

  • Detalizētāku rokasgrāmatu par Consul instalÄ“Å”anu un 3 mezglu kopas iestatÄ«Å”anu skatiet Å”eit.
  • Izveidojiet failu /etc/consul.d/agent.json Ŕādi [saite]:

### /etc/consul.d/agent.json
{
 "acl" : {
 "enabled": true,
 "default_policy": "deny",
 "enable_token_persistence": true
 }
}

  • Sāciet mÅ«su Consul serveri:

consul agent 
-server 
-ui 
-client 0.0.0.0 
-data-dir=/var/lib/consul 
-bootstrap-expect=1 
-config-dir=/etc/consul.d

  • Jums vajadzētu redzēt virkni izvadu, un beigās tiks parādÄ«ts ziņojums ā€œ... atjauninājumu bloķē ACLā€.
  • Atrodiet Consul servera ārējo IP adresi un atveriet pārlÅ«kprogrammu ar Å”o IP adresi portā 8500. Pārliecinieties, vai tiek atvērts lietotāja interfeiss.
  • Mēģiniet pievienot atslēgas/vērtÄ«bas pāri. Ir jābÅ«t kļūdai. Tas ir tāpēc, ka mēs ielādējām Consul serveri ar ACL un atspējojām visus noteikumus.
  • Atgriezieties pie sava apvalka Consul serverÄ« un sāciet procesu fonā vai kādā citā veidā, lai to palaistu, un ievadiet Å”o:

consul acl bootstrap

  • Atrodiet "SecretID" vērtÄ«bu un atgriezieties lietotāja saskarnē. Cilnē ACL ievadiet tikko nokopētā marÄ·iera slepeno ID. Kopējiet SecretID kaut kur citur, mums tas bÅ«s vajadzÄ«gs vēlāk.
  • Tagad pievienojiet atslēgas/vērtÄ«bas pāri. Å im POC pievienojiet Ŕādu: atslēga: ā€œcustom-ns/test_keyā€, vērtÄ«ba: ā€œEs esmu mapē custom-ns!ā€

Kubernetes klastera palaiŔana mūsu lietojumprogrammai ar Consul klientu kā Daemonset

  • Izveidojiet K8s (Kubernetes) kopu. Mēs to izveidosim tajā paŔā zonā, kur atrodas serveris, lai nodroÅ”inātu ātrāku piekļuvi, un tādējādi mēs varam izmantot to paÅ”u apakÅ”tÄ«klu, lai viegli izveidotu savienojumu ar iekŔējām IP adresēm. Mēs to sauksim par "skywiz-app-with-consul-client-poc".

Ievads Hashicorp konsula Kubernetes pilnvarojumā

  • Kā sānu piezÄ«mi, Å”eit ir laba apmācÄ«ba, ar kuru es saskāros, izveidojot POC Consul kopu ar Consul Connect.
  • Mēs izmantosim arÄ« Hashicorp stÅ«res diagrammu ar paplaÅ”inātu vērtÄ«bu failu.
  • Instalējiet un konfigurējiet Helm. Konfigurācijas soļi:

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

  • Izmantojiet stÅ«res diagrammu:

./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc

  • Kad tas mēģina palaist, tam bÅ«s nepiecieÅ”amas Consul servera atļaujas, tāpēc pievienosim tās.
  • Ņemiet vērā ā€œPod Address Rangeā€, kas atrodas klastera informācijas panelÄ«, un skatiet mÅ«su ugunsmÅ«ra noteikumu ā€œskywiz-consul-server-pocā€.
  • Pievienojiet podziņas adreÅ”u diapazonu IP adreÅ”u sarakstam un atveriet portus 8301 un 8300.

Ievads Hashicorp konsula Kubernetes pilnvarojumā

  • Dodieties uz Consul lietotāja interfeisu, un pēc dažām minÅ«tēm mezglu cilnē redzēsit mÅ«su kopu.

Ievads Hashicorp konsula Kubernetes pilnvarojumā

Autorizācijas metodes konfigurÄ“Å”ana, integrējot konsulu ar Kubernetes

  • Atgriezieties Consul servera apvalkā un eksportējiet iepriekÅ” saglabāto marÄ·ieri:

export CONSUL_HTTP_TOKEN=<SecretID>

  • Lai izveidotu autentifikācijas metodes gadÄ«jumu, mums bÅ«s nepiecieÅ”ama informācija no mÅ«su Kubernetes klastera:
  • 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:

  • Tokens ir kodēts base64, tāpēc atÅ”ifrējiet to, izmantojot savu iecienÄ«tāko rÄ«ku [saite]
  • kubernetes-ca-cert

kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:

  • Paņemiet ā€œca.crtā€ sertifikātu (pēc base64 dekodÄ“Å”anas) un ierakstiet to failā ā€œca.crtā€.
  • Tagad izveidojiet autentifikācijas metodi, aizstājot vietturus ar tikko saņemtajām vērtÄ«bām.

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>"

  • Tālāk mums ir jāizveido noteikums un jāpievieno tā jaunajai lomai. Å ai daļai varat izmantot Consul UI, bet mēs izmantosim komandrindu.
  • Uzrakstiet noteikumu

### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
 policy = "write"
}

  • Piemērot noteikumu

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

  • Atrodiet no izvades tikko izveidotās kārtulas ID.
  • Izveidojiet lomu ar jaunu noteikumu.

consul acl role create 
-name "custom-ns-role" 
-description "This is an example role for custom-ns namespace" 
-policy-id <policy_id>

consul acl binding-rule create 
-method=auth-method-skywiz-consul-poc 
-bind-type=role 
-bind-name='custom-ns-role' 
-selector='serviceaccount.namespace=="custom-ns"'

Visbeidzot konfigurācijas

Piekļuves tiesības

  • Izveidojiet piekļuves tiesÄ«bas. Mums ir jādod konsulam atļauja pārbaudÄ«t un identificēt K8s pakalpojuma konta pilnvaras identitāti.
  • Ierakstiet failā sekojoÅ”o [saite]:

###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

  • Izveidosim piekļuves tiesÄ«bas

kubectl create -f skywiz-poc-consul-server_rbac.yaml

Savienojuma izveide ar konsula klientu

  • Kā atzÄ«mēts Å”eitIr vairākas iespējas, kā izveidot savienojumu ar daemonset, taču mēs pāriesim pie Ŕāda vienkārŔā risinājuma:
  • Lietojiet Ŕādu failu [saite].

### 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

  • Pēc tam izmantojiet Å”o iebÅ«vēto komandu, lai izveidotu konfigurācijas karti [saite]. LÅ«dzu, ņemiet vērā, ka mēs atsaucamies uz mÅ«su pakalpojuma nosaukumu, vajadzÄ«bas gadÄ«jumā nomainiet to.

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

Autentifikācijas metodes pārbaude

Tagad redzēsim burvību darbībā!

  • Izveidojiet vēl vairākas atslēgu mapes ar to paÅ”u augstākā lÄ«meņa taustiņu (t.i., /sample_key) un vērtÄ«bu pēc jÅ«su izvēles. Izveidojiet atbilstoÅ”as ā€‹ā€‹politikas un lomas jauniem galvenajiem ceļiem. IesieÅ”anu veiksim vēlāk.

Ievads Hashicorp konsula Kubernetes pilnvarojumā

Pielāgotas nosaukumvietas pārbaude:

  • Izveidosim savu nosaukumvietu:

kubectl create namespace custom-ns

  • Izveidosim aplikumu mÅ«su jaunajā nosaukumvietā. Uzrakstiet podziņas konfigurāciju.

###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

  • Izveidot zem:

kubectl create -f poc-ubuntu-custom-ns.yaml

  • Kad konteiners darbojas, dodieties uz turieni un instalējiet curl.

kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y

  • Tagad mēs nosÅ«tÄ«sim pieteikÅ”anās pieprasÄ«jumu konsulam, izmantojot iepriekÅ” izveidoto autorizācijas metodi [saite].
  • Lai skatÄ«tu ievadÄ«to marÄ·ieri no sava pakalpojuma konta:

cat /run/secrets/kubernetes.io/serviceaccount/token

  • Ierakstiet tālāk norādÄ«to failu konteinerā:

### payload.json
{
 "AuthMethod": "auth-method-test",
 "BearerToken": "<jwt_token>"
}

  • Pieslēgties!

curl 
--request POST 
--data @payload.json 
consul-ds-client.default.svc.cluster.local/v1/acl/login

  • Lai veiktu iepriekÅ” minētās darbÄ«bas vienā rindā (jo mēs veiksim vairākus testus), varat rÄ«koties Ŕādi:

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

  • Darbojas! Vismaz vajadzētu. Tagad paņemiet SecretID un mēģiniet piekļūt atslēgai/vērtÄ«bai, kurai mums vajadzētu piekļūt.

curl 
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header ā€œX-Consul-Token: <SecretID_from_prev_response>ā€

  • Varat base64 atÅ”ifrēt vērtÄ«bu ā€œVērtÄ«baā€ un pārbaudÄ«t, vai tā atbilst vērtÄ«bai lietotāja interfeisa sadaļā custom-ns/test_key. Ja Å”ajā apmācÄ«bā izmantojāt to paÅ”u vērtÄ«bu, jÅ«su kodētā vērtÄ«ba bÅ«tu IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.

Lietotāja pakalpojuma konta pārbaude:

  • Izveidojiet pielāgotu ServiceAccount, izmantojot Å”o komandu [saite].

kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
 name: custom-sa
EOF

  • Izveidojiet jaunu konfigurācijas failu podam. LÅ«dzu, ņemiet vērā, ka es iekļāvu loku uzstādÄ«Å”anu, lai ietaupÄ«tu darbu :)

###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

  • Pēc tam palaidiet čaulu konteinera iekÅ”pusē.

kubectl exec -it poc-ubuntu-custom-sa /bin/bash

  • Pieslēgties!

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

  • Atļauja liegta. Ak, mēs aizmirsām pievienot jaunus noteikumus, kas ir saistoÅ”i ar atbilstoŔām atļaujām, darÄ«sim to tÅ«lÄ«t.

Atkārtojiet iepriekÅ” minētās darbÄ«bas:
a) Izveidojiet identisku politiku prefiksam ā€œcustom-sa/ā€.
b) Izveidojiet lomu, nosauciet to par ā€œpielāgotu lomuā€
c) Pievienojiet lomai politiku.

  • Izveidojiet kārtulu saistoÅ”o elementu (iespējams tikai no cli/api). Ņemiet vērā atlasÄ«tāja karoga atŔķirÄ«go nozÄ«mi.

consul acl binding-rule create 
-method=auth-method-skywiz-consul-poc 
-bind-type=role 
-bind-name='custom-sa-role' 
-selector='serviceaccount.name=="custom-sa"'

  • Piesakieties vēlreiz no konteinera "poc-ubuntu-custom-sa". Veiksmi!
  • Apskatiet mÅ«su piekļuvi pielāgotajam-sa/ atslēgas ceļam.

curl 
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header ā€œX-Consul-Token: <SecretID>ā€

  • Varat arÄ« nodroÅ”ināt, ka Å”is marÄ·ieris nepieŔķir piekļuvi kv failā "custom-ns/". VienkārÅ”i atkārtojiet iepriekÅ” minēto komandu pēc "custom-sa" aizstāŔanas ar prefiksu "custom-ns".
    Atļauja liegta.

Pārklājuma piemērs:

  • Ir vērts atzÄ«mēt, ka visi kārtulu saistoÅ”ie kartējumi tiks pievienoti pilnvarai ar Ŕīm tiesÄ«bām.
  • MÅ«su konteiners ā€œpoc-ubuntu-custom-saā€ atrodas noklusējuma nosaukumvietā ā€” tāpēc izmantosim to citai noteikumu saistÄ«Å”anai.
  • Atkārtojiet iepriekŔējās darbÄ«bas:
    a) Izveidojiet identisku politiku ā€œnoklusējuma/ā€ atslēgas prefiksam.
    b) Izveidojiet lomu, nosauciet to par ā€œdefault-ns-roleā€
    c) Pievienojiet lomai politiku.
  • Izveidojiet kārtulu saistoÅ”u elementu (iespējams tikai no 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"'

  • Atgriezieties mÅ«su "poc-ubuntu-custom-sa" konteinerā un mēģiniet piekļūt "noklusējuma/" kv ceļam.
  • Atļauja liegta.
    Katrai pilnvarai norādÄ«tos akreditācijas datus varat skatÄ«t UI sadaļā ACL > Tokens. Kā redzat, mÅ«su paÅ”reizējam marÄ·ierim ir pievienota tikai viena ā€œpielāgota lomaā€. PaÅ”laik izmantojamais marÄ·ieris tika Ä£enerēts, kad mēs pieteicāmies, un tajā brÄ«dÄ« bija tikai viens kārtulu saistoÅ”ais elements. Mums vēlreiz jāpiesakās un jāizmanto jaunais marÄ·ieris.
  • Pārliecinieties, vai varat lasÄ«t gan no kv ceļiem "custom-sa/", gan "default/".
    Veiksme!
    Tas ir tāpēc, ka mÅ«su ā€œpoc-ubuntu-custom-saā€ atbilst ā€œcustom-saā€ un ā€œdefault-nsā€ kārtulu saistÄ«jumiem.

Secinājums

TTL pilnvaras mgmt?

Å Ä«s rakstÄ«Å”anas laikā nebija integrēta veida, kā noteikt TTL marÄ·ieriem, kas Ä£enerēti ar Å”o autorizācijas metodi. Tā bÅ«tu lieliska iespēja nodroÅ”ināt droÅ”u konsulu autorizācijas automatizāciju.

Ir iespēja manuāli izveidot marķieri ar TTL:

Cerams, ka tuvākajā nākotnē mēs varēsim kontrolēt, kā tiek ģenerēti marķieri (pēc kārtulas vai autorizācijas metodes), un pievienot TTL.

Līdz tam ir ieteicams savā loģikā izmantot atteikŔanās galapunktu.

Lasiet arī citus rakstus mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru