AWS ElasticSearch Logsta sh 403 Запрещенный доступ - PullRequest
Новая
       8

AWS ElasticSearch Logsta sh 403 Запрещенный доступ

2 голосов
/ 08 апреля 2020

MySQL иasticsearch размещены на aws. И logsta sh работает на ec2. Я не использую VP C. Я могу подключиться к MySQL локально или на моем ec2.

Немного изменив вопрос. Вот новый файл logsta sh в моем ec2. Мой экземпляр es2 не сертифицирован по SSL, это проблема ? 

input {
    jdbc {
        jdbc_connection_string => "jdbc:mysql://aws.xxxxx.us-east-1.rds.amazonaws.com:3306/stuffed?user=admin&password=pword"
        jdbc_user => "admin"
        jdbc_password => "pword"
        schedule => "* * * * *"
        jdbc_validate_connection => true
        jdbc_driver_library => "mysql-connector-java-8.0.19.jar"
        jdbc_driver_class => "com.mysql.cj.jdbc.Driver"
        statement => "SELECT * from foo"
        type => "foo"
        tags => ["foo"]
    }

    jdbc {
        jdbc_connection_string => "jdbc:mysql://aws.xxxxx.us-east-1.rds.amazonaws.com:3306/stuffed?user=admin&password=pword"
        jdbc_user => "admin"
        jdbc_password => "pword"
        schedule => "* * * * *"
        jdbc_validate_connection => true
        jdbc_driver_library => "mysql-connector-java-8.0.19.jar"
        jdbc_driver_class => "com.mysql.cj.jdbc.Driver"
        statement => "SELECT * from cat"
        type => "cat"
        tags => ["cat"]
    }

    jdbc {
        jdbc_connection_string => "jdbc:mysql://aws.xxxxx.us-east-1.rds.amazonaws.com:3306/stuffed?user=admin&password=pword"
        jdbc_user => "admin"
        jdbc_password => "pword"
        schedule => "* * * * *"
        jdbc_validate_connection => true
        jdbc_driver_library => "mysql-connector-java-8.0.19.jar"
        jdbc_driver_class => "com.mysql.cj.jdbc.Driver"
        statement => "SELECT * from rest"
        type => "rest"
        tags => ["rest"]
    }
}
output {
    stdout { codec => json_lines }

    if "foo" in [tags] {
        amazon_es {
            hosts => ["https://es1.stuffed-es-mysql.us-east-1.es.amazonaws.com"]
            index => "foo"
            region => "us-east-1"
        aws_access_key_id => "id"
        aws_secret_access_key => "key"
            document_type => "foo-%{+YYYY.MM.dd}"
        }
    }

    if "cat" in [tags] {
        amazon_es {
            hosts => ["https://es1.stuffed-es-mysql.us-east-1.es.amazonaws.com"]
            index => "cat"
            region => "us-east-1"
        aws_access_key_id => "id"
        aws_secret_access_key => "key"
            document_type => "cat-%{+YYYY.MM.dd}"
        }
    }

    if "rest" in [tags] {
        amazon_es {
            hosts => ["https://es1.stuffed-es-mysql.us-east-1.es.amazonaws.com"]
            index => "rest"
            region => "us-east-1"
        aws_access_key_id => "id"
        aws_secret_access_key => "key"            
        document_type => "rest-%{+YYYY.MM.dd}"
        }
    }
}

Теперь я получаю сообщение об ошибке 403.

Я создал пользователь в AWS с разрешением AmazonESFullAccess (AWS управляемая политика). Я не уверен, что еще делать. Я не использую VP C, я пытался избежать этого. Поэтому я хочу придерживаться доступа publi c.

Я пытался создать новую службу ElasticSearch на основе этого руководства: https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-gsg.html

, но я получаю ошибку error_type=>LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError, :error=>"Elasticsearch Unreachable: [https://user:xxxxxx@mysql-abcdefghijkl.us-east-1.es.amazonaws.com:9200/]

и выход logsta sh для этого экземпляра: 

elasticsearch {
        hosts => ["https://es-mysql.us-east-1.es.amazonaws.com/"]
        index => "category"
        user => "user"
        password => "password"
        document_type => "cat-%{+YYYY.MM.dd}"
    }

Очевидно, что это не предпочтительный метод, но я просто пытаюсь настроить dev / личная среда.

Кроме того, я могу войти в Kibana с этим экземпляром.

ПОЛИТИКА ДОСТУПА

Для первой службы поиска elasti c: 

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111:user/root"
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:us-east-1:11111111:domain/stuffed-es-mysql/*"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:us-east-1:166216189490:domain/stuffed-es-mysql/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "11.11.11.111",
            "111.111.1.111",
            "111.111.1.1",
            "1.11.111.111",
          ]
        }
      }
    }
  ]
}

Для второго сервиса ElasticSearch, который я создал: 

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:us-east-1:xxxxxxxxx:domain/es-mysql/*"
    }
  ]
}

1 Ответ

1 голос
/ 12 апреля 2020

ТАК Я решил две проблемы.

Проблема первая : У меня все еще была проблема с моим входным подключением logsta sh к моей RDS (которое не проблема опубликована, но я все равно решил поделиться):

Проблема :

Экземпляр RDS MySQL был неправильной версией. Было установлено рекомендуемое значение AWS (5,7), и мне нужно самое последнее 8,0. *. Это вызывало проблему с некорректной работой jdb c.

Решение :

Обновление экземпляра RDS MySQL до 8.0.17. Теперь мой logsta sh смог прочитать входные данные из MySQL RDS.

Проблема вторая : вывод моего logsta sh не работал.

Проблема :

Получение ошибки 403.

Решение :

Убрано требование https при настройке ES служба. Скорее всего, это сработало для меня, потому что мой ec2 не сертифицирован ssl.

Решение проблемы два уже ставилось под сомнение в моем посте. И, будучи новичком в настройке logsta sh на ec2 и сервисеasticsearch (AWS), я не следовал своим инстинктам. Но я убрал требование https при настройке службы ES. Да, не самая лучшая идея, но это среда разработки. Это решило проблему. Почему? Потому что мой сервис ec2 не сертифицирован ssl. Это имеет смысл. Одна из распространенных проблем, возникающих при ошибке 403, заключается в том, что источник отправляет запрос в SSL-сертифицированное место назначения.

Я думаю, что это общая проблема для людей, которые хотят что-то запустить в бюджет, и это упускается из виду. Большинство людей хотят перейти к вашей политике доступа, политике IP или группе безопасности, и это понятно.

...