End-user authentication with Istio and KeyCloak on the AWS EKS environment

When evaluating Istio to use in our AWS EKS clusters environment, I found it is a little bit confusing with end-user authentication which cost me a couple days to set up a running scenario. Moreover, most of the blog posts and online documents only mention end-user authentication with Auth0 (a proprietary authentication solution) or very limited to other software such as KeyCloak. This article describes how I did the configuration to make it work with KeyCloak as well as briefly explaining the authentication flow of Istio.

As you may know, Istio introduces two types of authentication which are Transport Authentication and Origin Authentication [0]. Transport Authentication is used for the service to service authentication while Origin Authentication is used for end-user authentication. But, when it comes to real configuration, it looks like I have to apply both types if I want to set up the scenario as follows:

Figure 1: Expected scenario What I expected to have are:
End-user requests …

Counting all items of a DynamoDB table using aws cli

This following command will return the total number of records of a DynamoDB table:

aws dynamodb scan --table-name <TABLE_NAME> --select "COUNT"

Playing with Vault

Like many other products HashiCorp [1] has brought to the world (remember Vagrant [2]?), Vault [3] is great and useful. It helps you to manage secrets and protect sensitive data (I know some company even use it to store their application's configurations) and it's open source [4]!!!

Obviously, the easiest way to check it out these days is using Docker container. I tried these following steps and it works (vault v1.1.3).

1. Create a working directory for vault to store data

$ mkdir vault

2. Inside vault dir, create another directory to store its configuration

$ cd vault
$ mkdir config

3. Create the configuration file inside the config dir and name it vault.json

$ cd config
$ nano vault.json

  "backend": {
    "file": {
      "path": "/vault/file"
  "listener": {
      "address": "",
      "tls_disable": 1
  "ui": true

Note that in this configuration, …

Searchlight at Denver Summit 2019

In the last summit (Denver, CO), the Searchlight team had an opportunity to introduce its cool stuff to everyone. Due to the visa issues, there only one out of three members can come to the US. Thuy Dang, one of the core tea,, delivered the presentation and had a great conversation with the other community members.

The key points you can take out from the Project Update [1] and Project Onboarding [2] sessions are:
Review of Searchlight current status: 3 active contributorsFeatures introduced in Stein: support ES 5.x, bug fixes, multi-cloud visionFeatures for Train: multi-cloud support, new resource indexed (e.g., Tacker, Octavia, etc.)Introduce different ways you can contribute to Searchlight. Hopefully, after the summit, there will be more contributors interested in Searchlight. You can check out the slides for Project Update [4] and Project Onboarding [5].

Even though there were not many people attend the sessions, Thuy had had a great chance talking to some of the original Searchli…

Searchlight for Train

As we are reaching the final weeks of the Stein cycle, I would like to discuss a little bit about what we've done in Stein and planning for the Train cycle.

Stein cycle highlights as putting in [1]:
Searchlight now works with Elasticsearch 5.xWe have released a new vision to make Searchlight a multi-cloud application [2]. Moreover, we did a comparison of our vision and the OpenStack clouds visionFunctional test setup has been improvedSearchlight now can work and be tested with Python 3.7 And for the Train cycle, we would like to accomplish these main goals to fulfill the vision:
Make searchlight work with multiple cloud platforms including multiple OpenStack clouds [6], Azure [9], Google Cloud [10], AWS [11]. Add support for other OpenStack resources: Tacker [7], Octavia [8]Deprecate support for Elasticsearch 2.x [5] There is a lot of work to be done so I would continue putting effort to encourage new contributors t…

Searchlight RC1 released

Yahooo!!! We just released Searchlight Stein RC1 last week [1][2]. The stable/stein branch has been created for all of the projects. Here are the versions:

- searchlight:
- searchlight-ui:
- python-searchlightclient: 1.5.0

Moreover, we also added some highlights for Searchlight in this Stein cycle  [3]. There will be not much going on for the rest of the cycle, only minor changes. And, since we're busy preparing for the next term with more features to fulfill the Searchlight's vision [4], we will focus on designing the architecture and make Searchlight more stable.

BTW, I will continue serving as Searchlight's PTL for Train :) So, let's rock it!!!



Searchlight at Stein-3 (R-8,7,6)

Yahoo!!! We reached the Stein-3 (Stein R-5) [13] which is a very important milestone [11]. During this week, there are a couple of events (Searchlight related) will happen including:
Feature freeze: we have some features are being developed and expected to release them at Stein R-1.Final release for client libraries: at this point, I can tell there would be no more major changes of the python-searchlightclientStein community goals completed: Searchlight runs tests under Python 3 by default and has a basic framework for pre-upgrade checks.Train PTL self-nomination: I would say that I will run for another term as Searchlight PTL in order to build a foundation for the multi-cloud vision of Searchlight. Following are the major changes we made at Stein-3:
TC vision reflection [1]: this is a good practice to compare Searchlight vision with the TC vision [12] to make sure the team is going in the right direction which designed by the OpenStack community.Replace httplib2 with requests [2]: thi…