Kibana Space ve Role ile Çok Kullanıcılı Yapı Kurulumu

Kibana’yı ilk kurduğumuzda genellikle herkes her şeyi görür, herkes her şeyi yapabilir durumda olur. Küçük ekiplerde bu pek sorun çıkarmaz ama ortam büyüdükçe, farklı takımlar devreye girdikçe bu durum kaosa dönüşür. Geliştirici takımı production loglarını görüyor, güvenlik ekibi uygulama metriklerine erişebiliyor, finans departmanı yanlışlıkla bir dashboard siliyor… Bunların hepsini yaşadıktan sonra Kibana’nın Space ve Role mekanizmasını ciddiye almaya başlarsınız. Ben de bu noktadan sonra bu konuya kafa yormaya başladım ve şimdi öğrendiklerimi aktarıyorum.

Kibana Space Nedir, Neden Kullanırız?

Kibana Space’i en basit şekilde şöyle tarif edebilirim: Aynı Elasticsearch cluster’ı kullanan ama birbirinden izole edilmiş, bağımsız Kibana çalışma alanları. Her Space’in kendi dashboard’ları, kendi index pattern’ları, kendi saved search’leri ve kendi visualizasyonları var. Bir Space’de yaptığınız değişiklikler diğerini etkilemiyor.

Şöyle düşünün: Tek bir fiziksel ofis binasında farklı şirket departmanları için ayrı ayrı odalar oluşturuyorsunuz. Herkes aynı binadayken (aynı cluster) kendi odasında çalışıyor ve diğer odaları görmüyor.

Bunu gerçek bir senaryoyla somutlaştırayım. 200 kişilik bir yazılım şirketinde şu yapıyı kurmanız gerektiğini düşünün:

• Backend takımı uygulama loglarını izliyor
• DevOps ekibi altyapı metriklerini takip ediyor
• Güvenlik ekibi audit loglarını inceliyor
• Yönetim katmanı özet dashboard’ları görüyor

Bunların hepsini tek bir Kibana instance üzerinde, düzenli ve izole şekilde yönetmek için Space tam olarak ihtiyacınız olan şey.

Default Space’in Sınırlamalarını Anlamak

Kibana kurulumunda “default” adında bir Space otomatik oluşur ve tüm içerik buraya düşer. Çoğu kurulumda sysadminler yıllarca bu default Space ile devam eder. Ancak bu yaklaşımın ciddi dezavantajları var.

İlk sorun görünürlük karmaşası. 50 farklı ekip 50 farklı amaç için dashboard oluşturduğunda tek bir Space içinde yüzlerce nesne birikir. Birini bulmak başlı başına bir iş olur.

İkinci sorun izolasyon eksikliği. Bir kullanıcı yanlışlıkla başkasının dashboard’unu sildiğinde tüm ekip etkilenir.

Üçüncü sorun RBAC’ın (Role-Based Access Control) granüler çalışmaması. Space olmadan rol bazlı yetkilendirmeyi gereği gibi uygulayamazsınız.

Space Oluşturma: API ve UI Yöntemleri

Kibana arayüzünden Space oluşturmak için Stack Management > Spaces yolunu izleyebilirsiniz. Ama production ortamlarında her şeyi kod olarak yönetmek istiyorsanız Kibana API’sini kullanmanız gerekiyor. Bu hem tekrarlanabilirlik hem de versiyon kontrolü açısından çok daha sağlıklı.

Kibana API ile space oluşturma:

curl -X POST "http://localhost:5601/api/spaces/space" 
  -H "kbn-xsrf: true" 
  -H "Content-Type: application/json" 
  -u elastic:your_password 
  -d '{
    "id": "backend-team",
    "name": "Backend Takımı",
    "description": "Backend geliştirici ekibi için uygulama log analizi",
    "color": "#E8478B",
    "initials": "BT",
    "disabledFeatures": ["ml", "apm"]
  }'

Bu örnekte disabledFeatures parametresi dikkat çekici. Backend takımının Machine Learning veya APM özelliklerine erişmesine gerek yok, bu yüzden o sekmeleri tamamen kaldırıyoruz. Bu hem arayüzü sade tutuyor hem de yanlışlıkla bir şeyleri bozma ihtimalini azaltıyor.

Mevcut tüm space’leri listelemek için:

curl -X GET "http://localhost:5601/api/spaces/space" 
  -H "kbn-xsrf: true" 
  -u elastic:your_password | python3 -m json.tool

Birden fazla space’i toplu oluşturmanız gerektiğinde bu işlemi bir script’e dökmek mantıklı:

#!/bin/bash

KIBANA_URL="http://localhost:5601"
CREDENTIALS="elastic:your_password"

declare -A SPACES
SPACES["devops-team"]="DevOps Ekibi|Altyapı ve sistem metrikleri|#1BA9F5|DO"
SPACES["security-team"]="Güvenlik Ekibi|Audit ve güvenlik logları|#F5A623|SE"
SPACES["backend-team"]="Backend Takımı|Uygulama logları ve hata analizi|#E8478B|BT"
SPACES["management"]="Yönetim|Özet KPI dashboard'ları|#6CD75F|YN"

for space_id in "${!SPACES[@]}"; do
  IFS='|' read -r name description color initials <<< "${SPACES[$space_id]}"
  
  echo "Space oluşturuluyor: $space_id"
  
  curl -s -X POST "$KIBANA_URL/api/spaces/space" 
    -H "kbn-xsrf: true" 
    -H "Content-Type: application/json" 
    -u "$CREDENTIALS" 
    -d "{
      "id": "$space_id",
      "name": "$name",
      "description": "$description",
      "color": "$color",
      "initials": "$initials"
    }" | python3 -m json.tool
  
  echo "---"
done

Elasticsearch ve Kibana Rolleri

Space yapısını oturtmak tek başına yeterli değil. Kullanıcıların hangi Space’e girebileceğini, o Space içinde neler yapabileceğini ve hangi Elasticsearch index’lerine erişebileceğini kontrol eden rol yapısını da kurmanız gerekiyor.

Kibana’da rol yönetimi iki katmandan oluşur:

• Elasticsearch katmanı: Hangi index’lere okuma/yazma yetkisi var?
• Kibana katmanı: Hangi Space’lerde hangi özellikleri kullanabilir?

Önce Elasticsearch’te bir rol tanımlayalım. Bu rolü “backend-readonly” olarak oluşturacağız, yani backend loglarını sadece okuyabilecek bir rol:

curl -X PUT "http://localhost:9200/_security/role/backend-readonly" 
  -H "Content-Type: application/json" 
  -u elastic:your_password 
  -d '{
    "cluster": ["monitor"],
    "indices": [
      {
        "names": ["app-logs-backend-*", "app-errors-*"],
        "privileges": ["read", "view_index_metadata"],
        "field_security": {
          "grant": ["*"],
          "except": ["sensitive_field", "internal_data"]
        }
      }
    ],
    "applications": [
      {
        "application": "kibana-.kibana",
        "privileges": ["feature_dashboard.read", "feature_discover.read", "feature_visualize.read"],
        "resources": ["space:backend-team"]
      }
    ]
  }'

Bu rol tanımında birkaç önemli nokta var. field_security kısmıyla belirli alanları hariç tutabiliyorsunuz. Örneğin log kayıtlarında hassas müşteri bilgileri varsa bu alanları except listesine alarak o role sahip kullanıcıların bu alanları görmesini engelleyebilirsiniz. GDPR ve KVKK uyumluluğu açısından bu özellik gerçekten değerli.

resources kısmındaki space:backend-team ifadesi ise bu Kibana yetkilerinin yalnızca “backend-team” Space’i için geçerli olduğunu belirtiyor.

Şimdi bir de yazma yetkisi olan editör rolü oluşturalım:

curl -X PUT "http://localhost:9200/_security/role/backend-editor" 
  -H "Content-Type: application/json" 
  -u elastic:your_password 
  -d '{
    "cluster": ["monitor"],
    "indices": [
      {
        "names": ["app-logs-backend-*", "app-errors-*"],
        "privileges": ["read", "view_index_metadata", "write"]
      }
    ],
    "applications": [
      {
        "application": "kibana-.kibana",
        "privileges": [
          "feature_dashboard.all",
          "feature_discover.all",
          "feature_visualize.all",
          "feature_indexPatterns.all"
        ],
        "resources": ["space:backend-team"]
      }
    ]
  }'

Kullanıcı Oluşturma ve Rol Atama

Rol yapısını kurduktan sonra kullanıcı oluşturma ve bu rolleri atama işlemine geçiyoruz. Elasticsearch native realm kullanıyorsanız kullanıcıları doğrudan Elasticsearch API üzerinden yönetebilirsiniz:

curl -X PUT "http://localhost:9200/_security/user/ahmet.yilmaz" 
  -H "Content-Type: application/json" 
  -u elastic:your_password 
  -d '{
    "password": "SecurePass123!",
    "roles": ["backend-editor"],
    "full_name": "Ahmet Yılmaz",
    "email": "[email protected]",
    "metadata": {
      "department": "backend",
      "team": "core-services"
    }
  }'

Bir kullanıcıya birden fazla rol atayabilirsiniz. Örneğin birisi hem backend hem de devops Space’lerine erişmesi gerekiyorsa:

curl -X PUT "http://localhost:9200/_security/user/mehmet.kaya" 
  -H "Content-Type: application/json" 
  -u elastic:your_password 
  -d '{
    "password": "SecurePass456!",
    "roles": ["backend-readonly", "devops-editor"],
    "full_name": "Mehmet Kaya",
    "email": "[email protected]"
  }'

LDAP/Active Directory Entegrasyonu

Şirkette zaten bir Active Directory altyapısı varsa her kullanıcıyı tek tek Elasticsearch’te oluşturmak yerine AD ile entegrasyon kurmak çok daha mantıklı. Bu entegrasyon elasticsearch.yml veya Elasticsearch keystore üzerinden yapılandırılıyor ama rol eşlemesini ayrıca tanımlamanız gerekiyor.

AD grup ile Elasticsearch rolünü eşleştirme:

curl -X PUT "http://localhost:9200/_security/role_mapping/backend-team-mapping" 
  -H "Content-Type: application/json" 
  -u elastic:your_password 
  -d '{
    "roles": ["backend-editor"],
    "enabled": true,
    "rules": {
      "all": [
        {
          "field": {
            "groups": "CN=Backend-Developers,OU=Teams,DC=sirket,DC=com"
          }
        },
        {
          "field": {
            "realm.name": "ldap1"
          }
        }
      ]
    },
    "metadata": {
      "version": 1
    }
  }'

Bu yapıyla Active Directory’de “Backend-Developers” grubuna eklediğiniz her kullanıcı otomatik olarak backend-editor rolünü alıyor. İnsan kaynakları bir kişiyi o AD grubuna eklediğinde Kibana’da da otomatik yetkilendirilmiş oluyor. Personel değişikliklerini iki sistemde ayrı ayrı takip etmek zorunda kalmıyorsunuz.

Space’ler Arası Nesne Paylaşımı

Bir dashboard’u her Space’de ayrı ayrı oluşturmak istemeyebilirsiniz. Kibana bunu “Share to space” özelliğiyle çözüyor. Bir nesneyi birden fazla Space’de paylaşabiliyorsunuz.

API üzerinden bir saved object’i birden fazla Space’e paylaştırmak için:

curl -X POST "http://localhost:5601/api/spaces/_share_saved_object_add" 
  -H "kbn-xsrf: true" 
  -H "Content-Type: application/json" 
  -u elastic:your_password 
  -d '{
    "object": {
      "type": "dashboard",
      "id": "general-infra-overview-dashboard-id"
    },
    "spaces": ["devops-team", "management", "backend-team"]
  }'

Bu özelliği özellikle yönetim katmanı için hazırladığınız özet dashboard’larını ilgili ekiplere de göstermek istediğinizde kullanabilirsiniz.

Index Pattern’ı Space’e Göre Kısıtlama

Her Space’in kendi index pattern’larını görmesi gerekiyor. Bu noktada dikkatli olmak lazım; Elasticsearch’teki index yetkileri ile Kibana’daki index pattern’ların uyumlu olması gerekiyor.

Kibana API üzerinden belirli bir Space’e index pattern oluşturmak için önce o Space’in URL prefix’ini kullanıyorsunuz:

curl -X POST "http://localhost:5601/s/backend-team/api/index_patterns/index_pattern" 
  -H "kbn-xsrf: true" 
  -H "Content-Type: application/json" 
  -u elastic:your_password 
  -d '{
    "index_pattern": {
      "title": "app-logs-backend-*",
      "timeFieldName": "@timestamp",
      "fields": {}
    }
  }'

URL’deki /s/backend-team/ kısmına dikkat edin. Bu prefix hangi Space’de işlem yaptığınızı belirtiyor. Bu sayede her Space için ayrı ayrı index pattern oluşturabiliyorsunuz.

Rol Tabanlı Dashboard Kısıtlamaları

Gerçek hayatta karşılaştığım ilginç bir senaryo: Güvenlik ekibinin production ortamındaki tüm sunuculara ait güvenlik loglarını görebilmesi ama uygulama loglarına erişememesi, aynı zamanda güvenlik dashboard’larını düzenleyebilmesi ama silemememesi gerekiyordu.

Bu senaryoyu çözmek için granüler bir rol yapısı kurduk:

curl -X PUT "http://localhost:9200/_security/role/security-team-role" 
  -H "Content-Type: application/json" 
  -u elastic:your_password 
  -d '{
    "cluster": ["monitor", "read_ilm"],
    "indices": [
      {
        "names": ["audit-logs-*", "security-events-*", "firewall-logs-*"],
        "privileges": ["read", "view_index_metadata"]
      },
      {
        "names": ["wazuh-alerts-*"],
        "privileges": ["read", "view_index_metadata", "write"]
      }
    ],
    "applications": [
      {
        "application": "kibana-.kibana",
        "privileges": [
          "feature_dashboard.read",
          "feature_discover.all",
          "feature_visualize.all",
          "feature_savedObjectsManagement.read"
        ],
        "resources": ["space:security-team"]
      }
    ]
  }'

Dikkat ettiyseniz feature_dashboard.read verdim ama feature_dashboard.all vermedim. Bu sayede güvenlik ekibi dashboard’ları görüntüleyebiliyor ve yeni vizualizasyon oluşturabiliyor ama mevcut dashboard’ları silemiyor ya da düzenleyemiyor.

Space Durumunu İzleme ve Audit

Üretim ortamında kim hangi Space’e ne zaman girdi, hangi rolleri kullandı, neleri değiştirdi gibi soruları yanıtlayabilmeniz için audit logging’i aktif etmeniz gerekiyor.

kibana.yml içinde:

xpack.security.audit.enabled: true
xpack.security.audit.appender:
  type: rolling-file
  fileName: /var/log/kibana/kibana_audit.log
  policy:
    type: time-interval
    interval: 24h
  strategy:
    type: numeric
    max: 10
  layout:
    type: json

logging.appenders.audit_log:
  type: rolling-file
  fileName: /var/log/kibana/kibana_audit.log

Bu ayarla birlikte Kibana her önemli kullanıcı işlemini JSON formatında logluyor. Bu logları da Elasticsearch’e göndererek izleyebilirsiniz, tabii bu loglar için ayrı bir index ve Space ayarlamayı unutmayın.

Sık Yapılan Hatalar

Yıllarca bu yapıları kurarken gördüğüm en yaygın hatalar şunlar:

• Rol kümülasyonunu gözardı etmek: Bir kullanıcıya çok sayıda rol atadığınızda yetkiler birleşerek beklenmedik geniş erişimlere yol açabilir. Düzenli rol denetimleri şart.

• Default Space’i temizlememek: Tüm Space yapısını kurduğunuzda eski içerikler hala default Space’de duruyor olabilir. Bunu temizlemeden sistemi devreye almak karışıklığa neden olur.

• Space başına index pattern kontrolü yapmamak: Bir kullanıcı yanlış Space’de doğru Elasticsearch yetkisine sahipse oradan index pattern oluşturabilir. Index bazlı Elasticsearch rol kısıtlamaları her zaman aktif olmalı.

• Servis hesaplarını unutmak: Metricbeat, Filebeat ve diğer shipper’ların kullandığı servis hesaplarını da rol yapısına dahil etmek gerekiyor. Bu hesaplara sadece gerekli yazma ve cluster yönetim yetkilerini verin, fazlasını değil.

Terraform ile Space ve Rol Yönetimini Otomatikleştirmek

Ortam büyüdükçe değişiklikleri manuel API çağrılarıyla yönetmek sürdürülemez hale gelir. Terraform’un Elasticsearch provider’ı bu noktada işe giriyor:

terraform {
  required_providers {
    elasticstack = {
      source  = "elastic/elasticstack"
      version = "~> 0.5"
    }
  }
}

resource "elasticstack_elasticsearch_security_role" "backend_readonly" {
  name    = "backend-readonly"
  cluster = ["monitor"]

  indices {
    names      = ["app-logs-backend-*"]
    privileges = ["read", "view_index_metadata"]
  }

  applications {
    application = "kibana-.kibana"
    privileges  = ["feature_dashboard.read", "feature_discover.read"]
    resources   = ["space:backend-team"]
  }
}

Bu yaklaşımla Space ve rol tanımlarınızı Git repository’sinde versiyonlayabilirsiniz. Değişiklikler pull request süreci üzerinden geçiyor, her değişikliğin ne zaman kim tarafından yapıldığı izlenebiliyor. DevOps ekibini mutlu eden bir kurulum.

Sonuç

Kibana Space ve Role yapısını doğru kurduğunuzda, büyük ekiplerde log analizini gerçekten ölçeklenebilir hale getirebiliyorsunuz. Her ekip kendi alanında özgürce çalışabiliyor, yanlışlıkla birinin ortamını bozma riski azalıyor, güvenlik ve uyumluluk gereksinimlerini karşılamak kolaylaşıyor.

Bu sistemin en büyük getirisi aslında teknik değil, organizasyonel. Ekipler “bu benim Space’im” duygusunu edindiklerinde log altyapısını daha aktif kullanmaya başlıyorlar. Dashboard’larını kendileri düzenliyor, alert’lerini kendileri kuruyor, sorunları kendileri keşfediyorlar. Sysadmin olarak siz de sürekli “şuna yetkisi ver, bunu düzelt” talepleriyle boğulmak yerine gerçekten önemli işlere odaklanabiliyorsunuz.

Kurarken en fazla zaman harcayacağınız yer rol tasarımı olacak. Başta “en kısıtlayıcı” politikayla başlayın, sonra ihtiyaç duydukça gevşetin. Tam tersi yönde gitmek, yani geniş yetkiyle başlayıp sonradan kısıtlamaya çalışmak hem teknik hem de organizasyonel açıdan çok daha sancılı oluyor.