Openstack Domain,Project,UserGroup,User,Role,Token,Quota

Openstack Identity API (Keystone) degistikce yeni kavramlar ortaya cikiyor , en son version 3 ile beraber (v2 artik kullanilmasi onerilmiyor) Multi-Domain kavrami ortaya cikti. Daha once Openstack projelere yuklenen tenant yani organizasyon olabilme yetisi yerini Workspace , Departman , Alt-Departman gibi soylemlere birakiyor.

Keystone, sistemciler icin bir active directory olarak calisir, token yaratir , token dogrular , catalog bilgisi , policy servis bilgilerini saglar.

Domain : En buyuk izolasyon kavrami oluyor. Yazilimcilar icin bir namespace veya servis, saglayicilar icin Firma/Sirket tadinda, kullanici , kullanici guruplari ve projeleri barindirmaya basliyor. Genel Openstack kurulumlarinda ortamda henuz baska domain yaratilmadan once “Default” adinda bir domain yaratiliyor.

Domain kavrami olmadan once bir proje icin atanan admin rolundeki kullanici tum openstack namespace’inde admin oluyordu.

Default Domain yaratildiginda ilgili openstack servislerine ait hesaplarda bu domain icersinde yaratilir, ornegin neutron , glance , heat , cinder gibi …

Yaratilan tum domain adlari tekil olmalidir.

Domain’in diger bir ozelligide farkli dogrulama kaynaklarini devreye sokabilmesidir, mesela bir LDAP sunucunuz var ve tum kullanici bilgileriniz burada Openstack uzerinde yarattiginiz yeni domain’in bu LDAP sunucusunu kullanarak dogrulama yapmasini isteyebilirsiniz.

Project : Projeler icersinde kullanici ve kullanici guruplarini icermekle beraber ayni zamanda kaynak bilgisini icerirler, kota yonetimi bu katmadan baslar.

Ayni proje birden fazla domain’e uyesi olamaz.

Proje’ler daha onceleri tenant olarak adlandiriliyordu.

User/User Group : Kullanicilar kendilerine atanan role kapsaminda aktiviteleri gerceklestiren yine projelerden sonra kota yonetiminin uygulandigi bir diger katmandir. Kullanici guruplari ise iclerinde kullanicilari bulundurarak role atamalarini kolaylastirirlar.

Kurulum sirasinda default domain ile beraber domain_admin / cloud_admin olarak policy.json dosyalarinda gozuken bir element/kullanicida mevcuttur, bu kullanici sayesinde yeni domainler yaratilabilir , bunun icin kullanacaginiz ortam degiskenleride onemli olacaktir, bunu birazdan gorecegiz.

Role : Kullanicilara atanacak haklar role sayesinde belirlenir, herhangi bir role atanmamis kullanici islem yapamaz. Openstack role yonetimi diye baktiginizda karsiniza RBAC(Role-based Access Control) cikar ve ilgili her servis icin neutron , glance , identity veya digerleri icin konfigrasyon dosyalarinin bulundugu dizinde policy.json dosyalari mevcut olup (ornegin /etc/nova/policy.json) burada parca parca tum aktiviteler icin sinirlama yapilabilir , mesela sanal makine yaratabilsin fakat silemesin gibi.

Ornegin :

Asagida liberty versionundan alinma nova servisine ait policy.json dosyasindan bir ornek var, herkes sunucu yaratabilirken, silme islemini sadece admin role’une sahip veya ilgili instance’in sahibi silmesine izin veriyor.

"compute:create": "",
"compute:delete": "rule:admin_or_owner",

HP helion gibi ozellesmis kurulumlarda ilgili dosyalar icin bire template yaratilmis olup , bu template’ler uzerinde oynama yapip reconfigure yapmak gerekiyor.

~/helion/hos/ansible/roles/GLA-API/templates/policy.json.j2
~/helion/hos/ansible/roles/ironic-common/files/policy.json
~/helion/hos/ansible/roles/KEYMGR-API/templates/policy.json
~/helion/hos/ansible/roles/heat-common/files/policy.json
~/helion/hos/ansible/roles/CND-API/templates/policy.json
~/helion/hos/ansible/roles/nova-common/files/policy.json
~/helion/hos/ansible/roles/CEI-API/templates/policy.json.j2
~/helion/hos/ansible/roles/neutron-common/templates/policy.json.j2

ilgili policy.json dosyalari hem olsun cli olsun gui uzerinden calistirilan bir komut sirasinda tekrar tekrar okunur, dinamiktir herhangi bir servis reboot gerektirmez (htaccess dosyasi gibi).

Token : Domain , proje bazda dogrulama yaptiginiz kullanici adi ve sifre karsiliginda verilen , timeout suresi boyunca izniniz olan islemleri bir daha dogrulama yapmadan gerceklestirmenizi saglar. Domain Scope token’lar ile farkli domain yaratma veya proje yaratmak gibi islemler yaparken , proje scope’lu token’larda ilgili proje icin kullanici , kaynak ve instance bazli islemler yapabilirsiniz.

Openstack’de token alisverisini HPE guzel bir sekilde anlatmis.

Asagida cli’dan ornek domain scoped token almaya bir ornek bulabilirsiniz. Diger REST ornekleri

curl -i \

-H “Content-Type: application/json” \

-d ‘

{ “auth”: {

“identity”: {

“methods”: [“password”],

“password”: {

“user”: {

“name”: “admin”,

“domain”: { “id”: “default” },

“password”: “secret”

}

}

},

“scope”: {

      “domain”: {

        “id”: “default”

}

}

}

}’ \

http://localhost:5000/v3/auth/tokens ; echo

Catalog : Openstack uzerinde olan tum servisler , bu servislerin erisim (endpoint) bilgilerini ve region bilgilerini saglar. Islem yapmak icin bir token istediginizde bu bilgiler client’a verilecektir.

Catalog bilgisini listeleyelim

  • stack@helion-cp1-c0-m1-mgmt:~$ openstack catalog list

Cloud Admin olarak islem yapmak yani Domain yaratmak istiyor isek oncelikle kullandigimiz ortam degiskenlerine dikkat etmemiz gerekiyor. Eger daha oncesinden Openstack RC file kullanarak ortam degiskenlerini set ettiyseniz ya onlari silin yada “OS_PROJECT_NAME” ve “OS_PROJECT_DOMAIN_NAME” degiskenlerini kaldirin. Ornegin unset OS_PROJECT_NAME ve unset OS_PROJECT_DOMAIN_NAME gibi . Elinizde asagidaki gibi ortam degiskenleri olacak.

Helion Openstack kurulumunda keystone.osrc , RDO kurulumundada keystonerc_admin olarak gecen dosyalar var , bunlari source komutuyla calistirabilirsiniz.

stack@helion-cp1-c1-m1-mgmt:~$ env | grep OS

OS_USER_DOMAIN_NAME=Default

OS_AUTH_VERSION=3

OS_IDENTITY_API_VERSION=3

OS_PASSWORD=<SIFRENIZ>

OS_DOMAIN_NAME=Default

OS_AUTH_URL=https://10.111.45.3:5000/v3

OS_COMPUTE_API_VERSION=2

OS_USERNAME=admin

OS_ENDPOINT_TYPE=internalURL

OS_CACERT=/etc/ssl/certs/ca-certificates.crt

OS_INTERFACE=internal

Baslayalim …..

  • Baslamadan once tum komutara –debug paramteresi ekleyerek REST API kullanarak ayni islemeri nasil yapabileceginizi gorebilirsiniz
    • stack@helion-cp1-c1-m1-mgmt:~$ openstack –debug domain list
    • stack@helion-cp1-c1-m1-mgmt:~$ nova –debug list
  • Ayni sekilde asagida kullanilacak komutlar hakkinda daha fazla yardim icin her zaman help deyimini kullanabilirsiniz
    • stack@helion-cp1-c0-m1-mgmt:~$ nova help limits
  • Domain’leri bir listeleyelim , elimizde neler var
    • stack@helion-cp1-c1-m1-mgmt:~$ openstack domain list
    • Ufak bir not, eger cli ciktilarindan bir script veya degiskene atamak gibi bir islem yapicaksaniz -f value parametresini kullanabilirsiniz. Ayni zamanda json/xml ciktisi almakta mumkun
      • stack@helion-cp1-c0-m1-mgmt:~$ openstack domain list -f value
  • Diyelim Openstack RC dosyasini calistirmadiniz ve ortam degiskenlerini parametre olarak vermek istiyorsunuz
    • stack@helion-cp1-c0-m1-mgmt:~$ openstack –-os-identity-api-version 3 –os-username admin –os-auth-url https://10.111.45.3:5000/v3 –os-user-domain-name default –os-domain-id default –os-password <SIFRE> domain list
  • Kullanicilari listeleyelim
    • stack@helion-cp1-c0-m1-mgmt:~$ openstack user list
  • Role listelemek ister isek
    • stack@helion-cp1-c0-m1-mgmt:~$ openstack role list
  • Role, kullanici ve proje iliskisini gormek istiyorsaniz
    • stack@helion-cp1-c0-m1-mgmt:~$ openstack role assignment list
      • Filtreleyebilmek icin –user admin –domain default ilgili parametreleri kullanabilirsiniz.
  • Diyelim bir domain yaratmak istiyoruz , adinida “musteri1” diyecegiz
    • stack@helion-cp1-c0-m1-mgmt:~$ openstack domain create –description musteri1 musteri1
  • Musteri1 domain’ini yonetecek kullanici musteri1-admin olsun , burada sirayla musteri1 domaini altinda, ilgili aciklama ile ilgili email adresi ve bana kullanici sifresini soracak sekilde komut satirini ayarliyorum
    • stack@helion-cp1-c0-m1-mgmt:~$ openstack user create –domain musteri1 –description musteri1_admin –email musteri1_admin@musteri1 –password-prompt musteri1_admin
      • Email adresini dogru yazmaya ozen gosterin, cli ilgili e-mail formatini dikkat etmiyor ama Horizon ediyor.
    • Bundan sonra kullanicilari listelerken veya role listelerken , –domain parametresi kullanacagiz
      • stack@helion-cp1-c0-m1-mgmt:~$ openstack user list –domain musteri1
  • Ilgili kullaniciya ilgili role’u yani admin role’unu ekliyorum , burada –user-domain parametresine dikkat ! yoksa size kullanici yok diyebilir
    • Role eklemeden once, yarattiginiz kullanici/sifre ile domain’e login olamayacaksiniz , taki domain/proje’ye erisilebilirligi saglayincaya kadar, iste bir sonraki adimda bunu yapiyoruz
    • stack@helion-cp1-c0-m1-mgmt:~$ openstack role add –user-domain musteri1 –user musteri1_admin –domain musteri1 admin
    • Role’leri listeliyorum
      • stack@helion-cp1-c0-m1-mgmt:~$ openstack role assignment list –domain musteri1
      • veya
      • stack@helion-cp1-c0-m1-mgmt:~$ openstack role list –user-domain cm1 –domain cm1 –user cm1_user2
  • Simdi “musteri1” domain’i altinda bir iki proje yaratalim , ben ilgili projeyi yaratirken halen cloud_admin ile islemi yapiyorum.
    • stack@helion-cp1-c0-m1-mgmt:~$ openstack project create –domain musteri1 –description “project2” proje2
    • Buraya kadar gelmisken proje hakkinda mesela isim , aciklama veya projeyi aktif / pasif yapmak istiyorsaniz bunun icin set ile ilgili parametreyi vermelisiniz , ornegin proje1 adindaki proje’yi proje111 diye degistirelim
      • stack@helion-cp1-c0-m1-mgmt:~$ openstack project set d0fe745d1b264a9589f5b7a79386579e –name proje111
  • Daha sonra GUI ve musteri1_admin kullanicisi ile horizion’a login oldugunuzda sadece IDENTITY tab’ina eristiginizi goreceksiniz ;
    • Proje’ye , user ve group yaratma islemlerini yapabilirsiniz.
    • Proje’lere ait quota yonetimi yapamadiginizi goreceksiniz.
    • Ilgili domain admin kullanicisinin herhangi bir projeyi , yonetemedigini ve gerekir ise uyelikleri yonetebilieceginizi goreceksiniz.
  • Simdi proje2 icin bir kullanici ekleyip , _member_ role atmasi yaparak proje uzerinde islem yapabilir hale getirelim.
    • stack@helion-cp1-c0-m1-mgmt:~$ openstack user create –domain musteri1 –description musteri1_proje_member –email musteri1_proje_member@musteri1 –password-prompt musteri1_proje_member
    • stack@helion-cp1-c0-m1-mgmt:~$ openstack role add –user-domain musteri1 –user musteri1_proje_member –project proje2 _member_
    • GUI den veya elle asagidaki Openstack RC dosyasina erisip calistirinOS_PROJECT_ID=c4e21d9d500a4082b8079a3d0c1561a1OS_REGION_NAME=dorukistbesiktasOS_USER_DOMAIN_NAME=musteri1OS_PROJECT_NAME=proje2

      OS_PASSWORD=12qwaszxcv!

      OS_AUTH_URL=https://xxx.yyy.com:5000/v3

      OS_USERNAME=musteri1_proje_member

    • Daha sonra goreceksinizki network yaratma , silme , instance yaratma ve silme gibi islemleri bu kullanici ile yapabileceksiniz.
  • Bunda sonra kota olayina bakabiliriz, Openstack quota project ve user bazli
  • Project bazli gorebilmek icin ;
    • stack@helion-cp1-c1-m3-mgmt:~$ openstack quota show proje1
  • Ilgili proje’nin ilgili quota degisikligi yapmak istiyorsaniz
    • stack@helion-cp1-c1-m3-mgmt:~$ openstack quota set proje1 –instances 100
  • Quota islemini parcalara bolersek , elimizde compute , cinder ve network kisimlari var
    • Compute yani nova quota icin default bir tanim mevcut bunu asagidaki komutu calistirarak gorebilirsiniz
    • Asagidaki komutu calistirmadan once –os-project-name ve –os-project-id ortam degerlerini set edin veya direkt ilgili Openstack RC file’ini calistirin.
      • stack@helion-cp1-c1-m3-mgmt:~$ nova quota-defaults
    • Default quota degerini guncelleyebiliriz
      • stack@helion-cp1-c1-m3-mgmt:~$ nova quota-class-update –floating_ips 20 default
    • Veya belli bir proje’nin degerlerini guncelleyebiliriz , bu kez farkli bir projeyi seciyorum cm1_project2
      • stack@helion-cp1-c0-m1-mgmt:~$ nova quota-update –floating_ips 101 cm1_project2
    • Belli bir projeye atanmis compute quota degerlerini gormek icin
      • stack@helion-cp1-c0-m1-mgmt:~$ nova quota-show –tenant cm1_project2
    • Ilgili projedeki kullaniciya atanmis compute quota gormek icin
      • stack@helion-cp1-c0-m1-mgmt:~$ nova quota-show –user cm1_proje_member1 –tenant cm1_project2
    • Kullanici compute quota’sini guncellemek icin bir proje kotasini guncellemek icin kullandigimizi komuta –user ile kullaniciyi set etmekten baska bir fark yok
      • stack@helion-cp1-c0-m1-mgmt:~$ nova quota-update –user cm1_proje_member1 –instances 20 cm1_project2
      • Tabiki proje kaynaklarindan daha buyugunu kullaniciya atayamazsiniz
        • ERROR (BadRequest): Quota limit 205 for instances must be less than or equal to 200. (HTTP 400) (Request-ID: req-b1d0dfb9-f0af-4a4a-afa9-da3522ef468f)
      • Proje kaynaklarini guncellediginizde bu kullanicilara yansimayacaktir. Bunun icin kullanicinin kotasini gerekiyor ise tekrardan guncellemelisiniz.
    • En son kullanim oranlarini gormek icin
      • stack@helion-cp1-c0-m1-mgmt:~$ nova limits –tenant cm1_project2
    • Block icin
      • Varsayili Atanmis Degeri Gorelim
        • stack@helion-cp1-c1-m3-mgmt:~$ cinder quota-defaults cm1_project2
        • -1 olarak gordugunuz degerler unlimited demek
      • Ilgili projeye atanmis block
        • stack@helion-cp1-c0-m1-mgmt:~$ cinder quota-show cm1_project2
      • Degitirelim
        • stack@helion-cp1-c0-m1-mgmt:~$ cinder quota-update –volumes 999 cm1_project2
      • Simdi degisikligi gorelim
        • stack@helion-cp1-c0-m1-mgmt:~$ cinder quota-show cm1_project2
        • Bu arada oldu ki tenant/proje adini yanlis yazdiniz, komut hala size birtakim degerler dondurmeye devam ediyor, dikkat !
      • Kullanim oranlarini gormek icin
        • stack@helion-cp1-c0-m1-mgmt:~$ cinder quota-usage cm1_project2
      • Birde tum kota degerlerini sifirlamak ister isek, aslinda sifirlamakdan kastimiz varsayili degerlere cevirmek
        • stack@helion-cp1-c0-m1-mgmt:~$ cinder quota-delete cm1_project2
        • Yukardaki komut hata verebilir, bunun icin konsolda export OS_VOLUME_API_VERSION=1 calistirarak tekrar deneyin.
      • Default quota degisiklikleri icin cinder.conf dosyasinindada guncelleme yapilabilir. Ilgili link’den quota_ ile baslayanlarini arattirabilirsiniz.
    • Neutron icin
      • Proje’ye ait network kota degerlerini gorelim
        • stack@helion-cp1-c1-m3-mgmt:~$  neutron quota-show –tenant-id c4e21d9d500a4082b8079a3d0c1561a1
      • Simdi kotalari guncelleyelim, mesela projeye ait max network sayisini degistirelim
        • stack@helion-cp1-c1-m3-mgmt:~$  neutron quota-update –tenant-id c4e21d9d500a4082b8079a3d0c1561a1 –network 99
        • Birden fazla degeri ayni anda guncelleyelim
          • stack@helion-cp1-c1-m3-mgmt:~$  neutron quota-update –tenant-id c4e21d9d500a4082b8079a3d0c1561a1 –network 99 –port 99
      • Tum quota degerlerini sifirlamak ister isek
        • stack@helion-cp1-c0-m1-mgmt:~$ neutron quota-delete –tenant-id c4e21d9d500a4082b8079a3d0c1561a1
        • Goruceksinizki ilgili degerler varsayili olan degerlere donmus
      • Default quota degisiklikleri icin cinder.conf dosyasinindada guncelleme yapilabilir. Ilgili link’den quota_ ile baslayanlarini arattirabilirsiniz.

Guzel Linkler

https://wiki.openstack.org/wiki/Domains

http://docs.openstack.org/developer/keystone/index.html

http://docs.openstack.org/security-guide/identity.html

Mirantis training blog keystone domain

http://docs.openstack.org/admin-guide/cli-set-quotas.html

Posted on 25/10/2016, in Openstack and tagged , , , , , , , , , , . Bookmark the permalink. Leave a comment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: