| I don't think you're wrong, its a complete offering- and yet: - If you want to ingest data with Kinesis Firehose, you can't deploy the cluster in a VPC. - You can enable API access to an IP whitelist, IAM role or an entire account. You can attach the policy to the resource, or to an identity, or call from an AWS service with a service-linked role. That's all good, perhaps a little complex but as you said, nothing too different than S3 or DyanmoDb, except for the addition of IP policy. Why not security groups? Is DENY worth the added complexity? - However, you can't authenticate to Kibana with IAM as a web-based service. Recently they added support for Cognito for Kibana, otherwise one would have to setup a proxy service and whitelist Kibana to that proxy's IP, then manage implementing signed IAM requests if you want index level control. Cognito user pools can be provisioned to link to a specific role, but you can't grant multiple roles to a user pool, so you have to create a role and user pool for every permutation of index access you want to grant. You also have delegate ES cluster access to Cognito, and deploy them in the same region. All told, even a relatively simple but proper implementation of ES+Kibana with access control to a few indexes using CloudFormation or Terraform would require at least a dozen resources, and at least a day of a competent developer's time researching, configuring, and testing the deployment. Probably more to get it right. Ultimately there is nothing wrong with the controls AWS provides, but plenty that can go wrong with them. For the curious: - https://aws.amazon.com/blogs/security/how-to-control-access-... - https://docs.aws.amazon.com/elasticsearch-service/latest/dev... |
why not?
https://aws.amazon.com/blogs/aws/amazon-elasticsearch-servic...