Kebijakan akses yang tepat untuk Amazon Elastic Search Cluster


99

Saya baru-baru ini mulai menggunakan Amazon Elasticsearch Service baru dan sepertinya saya tidak dapat mengetahui kebijakan akses yang saya perlukan sehingga saya hanya dapat mengakses layanan dari instans EC2 saya yang memiliki peran IAM khusus yang ditetapkan padanya.

Berikut adalah contoh kebijakan akses yang saat ini saya tetapkan untuk domain ES:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::[ACCOUNT_ID]:role/my_es_role",
        ]
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:us-east-1:[ACCOUNT_ID]:domain/[ES_DOMAIN]/*"
    }
  ]
}

Tapi seperti yang saya katakan, ini tidak berhasil. Saya masuk ke instans EC2 (yang memiliki my_es_roleperan yang melekat padanya) dan mencoba menjalankan panggilan curl sederhana di titik akhir "https: //*.es.amazonaws.com", saya mendapatkan kesalahan berikut:

{"Message": "Pengguna: anonim tidak diizinkan melakukan: es: ESHttpDapatkan sumber daya: arn: aws: es: us-east-1: [ACCOUNT_ID]: domain / [ES_DOMAIN] /“}

Adakah yang tahu apa yang harus saya ubah dalam kebijakan akses agar ini berfungsi?


14
Hati-hati, perubahan kebijakan akses ElasticSearch membutuhkan waktu lama untuk diterapkan, tidak seperti perubahan IAM lainnya yang hampir seketika. Sangat mudah untuk hanya mengklik "terapkan" dan beralih tab tanpa memperhatikan "Memproses ..."
Cyril Duchon-Doris

Jawaban:


63

Anda dapat mengunci akses ke IAM saja, tetapi bagaimana Anda akan melihat Kibana di browser Anda? Anda dapat mengatur proxy ( lihat modul Inti dan / atau NPM ) atau mengaktifkan IAM dan akses berbasis IP untuk melihat hasil.

Saya bisa mendapatkan akses IP terbatas akses IAM dengan Kebijakan Akses berikut. Perhatikan bahwa urutannya penting: Saya tidak bisa membuatnya berfungsi dengan pernyataan berbasis IP sebelum pernyataan IAM.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::xxxxxxxxxxxx:root"
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:us-west-2:xxxxxxxxxxxx:domain/my-elasticsearch-domain/*"
    },
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:us-west-2:xxxxxxxxxxxx:domain/my-elasticsearch-domain/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "192.168.1.0",
            "192.168.1.1"
          ]
        }
      }
    }
  ]
}

Instans EC2 saya memiliki profil instans dengan arn:aws:iam::aws:policy/AmazonESFullAccess kebijakan. Logstash harus menandatangani permintaan menggunakan plugin output logstash-output-amazon-es . Logstash yang berjalan di instans EC2 saya menyertakan bagian keluaran seperti ini:

output {
    amazon_es {
        hosts => ["ELASTICSEARCH_HOST"]
        region => "AWS_REGION"
    }
    # If you need to do some testing & debugging, uncomment this line:
    # stdout { codec => rubydebug }
}

Saya dapat mengakses Kibana dari dua IP dalam kebijakan akses (192.168.1.0 dan 192.168.1.1).


Hai, Anda hanya perlu menggunakan plugin jika Anda menggunakan kebijakan berbasis IAM. Anda dapat menggunakan plugin elasticsearch standar di Logstash jika kebijakan akses Anda didasarkan pada alamat IP. Anda juga tidak memerlukan profil instance dalam kasus itu. Selain itu, layanan ES tidak tersedia di VPC. Anda harus menggunakan alamat ip publik untuk terhubung. Tidak yakin apakah referensi Anda ke alamat 192.168 adalah pengganti untuk sesuatu yang lain, tetapi dapat menyesatkan.
Garreth McDaid

Yang aws:SourceIpdi contoh saya dimaksudkan untuk menjadi IP workstation pribadi Anda sehingga Anda dapat menggunakan Kibana. Akses terbatas IAM memungkinkan satu atau beberapa instans EC2 untuk menulis ke Elasticsearch tanpa mengkhawatirkan IP mana yang termasuk dalam instans atau blok CIDR tertentu.
Pete

1
Perlu dicatat bahwa membatasi ke rentang IP CIDR pribadi VPC Anda tampaknya tidak berhasil. ES tidak beroperasi dalam VPC atau semacamnya.
sventechie

Terima kasih telah memberikan contoh kebijakan dalam jawaban Anda; Saya tidak bisa membuat Kibana melewati kesalahan "User: anonymous" yang ditakuti sampai saya beralih aws:SourceIpdari nilai skalar ke array, seperti pada contoh yang Anda berikan. (Saya notasi CIDR, jika itu membantu orang lain.) Seluruh proses pengaturan kebijakan untuk AWS ES tidak akan terlalu membuat frustrasi jika setiap perubahan kebijakan tidak menempatkan cluster ke dalam status "pemrosesan" misterius selama 20 menit karena polis itu dengan hati-hati ditorehkan pada loh batu, atau apa pun yang mereka lakukan.
Robert Calhoun

38

Menurut dokumen AWS dan saat Anda (dan saya) baru saja menguji, Anda tidak dapat membatasi akses ke domain AWS ES untuk peran / akun / pengguna / ... dan cukup cURL!

Klien standar, seperti curl, tidak dapat melakukan penandatanganan permintaan yang diperlukan untuk kebijakan akses berbasis identitas. Anda harus menggunakan kebijakan akses berbasis alamat IP yang memungkinkan akses anonim berhasil melakukan instruksi untuk langkah ini. ( http://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-gsg-search.html )

Jadi pada dasarnya Anda memiliki dua solusi:

Menandatangani permintaan Anda mungkin merupakan solusi terbaik jika Anda ingin mempertahankan kebijakan akses sebagaimana adanya (yang lebih fleksibel daripada membatasi ke IP), tetapi tampaknya sedikit lebih rumit. Saya belum mencoba sejauh ini dan saya tidak dapat menemukan dokumen apa pun untuk membantu.


3
Saya menggunakan alamat IP publik laptop saya dan mencoba mengakses titik akhir dengan curl / browser, tetapi saya masih mendapatkan User: kesalahan anonim.
Anant Gupta

7
saya berurusan dengan masalah yang sama. dan saya perhatikan bahwa memproses perubahan dengan aws elasticsearch membutuhkan waktu yang sangat lama.
nemo

Tetapkan Kebijakan Akses dengan dua pernyataan: satu untuk akses IAM untuk menulis log, yang lainnya dengan akses terbatas IP untuk melihat KIbana. Lihat jawaban saya untuk detailnya
Pete

2
Aku bertanya-tanya apakah "loooong" berarti menit, jam, atau hari. Sepertinya 10-15 menit. Anda dapat melihat itu ketika memeriksa status ES Anda (hijau 'aktif' jika pembaruan selesai, jika tidak, sesuatu seperti oranye 'persiapan'.
Balmipour

Saya memiliki masalah yang sama dan setelah mencari saya menemukan perpustakaan yang berguna ini .
gmajivu

6

Agak terlambat ke pesta, tetapi saya dapat menangani masalah yang sama persis dengan menambahkan tanda tangan ke permintaan saya.

Jika Anda menggunakan Python (seperti yang saya lakukan), Anda dapat menggunakan pustaka berikut untuk membuatnya sangat mudah diterapkan: https://github.com/DavidMuller/aws-requests-auth

Ini bekerja dengan sempurna untuk saya.


1

Anda hanya perlu nama pengguna lengkap dalam kebijakan pencarian elastis.

Dalam kasus ini, Anda bisa mendapatkan nama pengguna lengkap Anda dari pesan kesalahan itu sendiri. Dalam kasus saya: "arn: aws: sts :: [ACCOUNT_ID]: diasumsikan-peran / [LAMBDA_POLICY_NAME] / [LAMBDA_NAME]"

    {
        "Version": "2012-10-17",
        "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "AWS": [
              "arn:aws:sts::xxxxxxxxxxxx:assumed-role/[lambda-role]/[full-lambda-name]"
            ]
          },
          "Action": "es:*",
          "Resource": "arn:aws:es:[region]:xxxxxxxxxxxxx:domain/[elasticsearch-domain-name]/*"
        }
      ]

    }


0

Peran ARN perlu diubah. akan terlihat seperti "arn: aws: iam :: [ACCOUNT_ID]: role / service-role / my_es_role"


-2

Saya juga mencoba melakukan ini, dan saya membuatnya berfungsi menggunakan Allow access to the domain from specific IP(s)opsi dengan IP Elastis dari instans EC2 saya (juga dapat bekerja menggunakan IP pribadi instans, tetapi saya tidak terlalu yakin)

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.