liyuntao / kong-init

Declarative configuration tool for Kong
Apache License 2.0
38 stars 8 forks source link

Add Headers to all Admin API requests #11

Open arthmoeros opened 5 years ago

arthmoeros commented 5 years ago

Hello!, It's me again hehe.

I was wondering, does this tool has an option to add headers on args like kongfig?, we use this for Authorization headers, like this for example:

kongfig apply --https --path myconfig.yml --header "Authorization: Basic ${USER_PASSWORD}" --header "Kong-Admin-Token: ${USER_TOKEN}"
liyuntao commented 5 years ago

Do you mean to use such feature in a certain scene which kong-admin-api endpoint is secured by basic auth?

If so, it's pretty easy to add header when kong-init requesting the kong-admin-api endpoint.

arthmoeros commented 5 years ago

Do you mean to use such feature in a certain scene which kong-admin-api endpoint is secured by basic auth?

If so, it's pretty easy to add header when kong-init requesting the kong-admin-api endpoint.

Yes, I don't know if there is another use case to require the use of headers, but at least this one requires those headers.

I'm implementing a quick&dirty solution for this using reqwest 0.9.2 and string headers, but I'm not versed on Rust, so I don't see this solution fit for a PR.

liyuntao commented 5 years ago

support for custom header has been added in the latest master branch. (It took a long time for the migration work from reqwest 0.8 -> 0.9)

I'll trigger a release version after complete test.

arthmoeros commented 5 years ago

Hello!

Is there any update on the new release?, I'm sticking with my fork meanwhile, but I was wondering if your version with --header args is suitable for use or not.

I was going to try it anyway, but wanted your comments on this.

Thanks!

liyuntao commented 5 years ago

@arthmoeros I need some more detailed information. About how do you protect the admin-api? I just did some testing about header args feature. It works, but currently kong-init choose to clear all existed plugin/routes/services before doing initialization. So it doesn't fit the loopback api with key-auth/basic-auth plugin added to simply verify this feature.

verify detail:

# under kong 0.14.X
# following https://docs.konghq.com/0.14.x/secure-admin-api/#kong-api-loopback
# 1. add loopback service
curl -X POST http://localhost:8001/services \
  --data name=admin-api \
  --data host=localhost \
  --data port=8001

# 2. add loopback route
curl -X POST http://localhost:8001/services/admin-api/routes \
  --data paths[]=/admin-api

# 3. add basic-auth plugin to route (using konga,  ignore the step)

# 4. create a consumer
curl -d "username=user123&custom_id=user123" http://localhost:8001/consumers/

# 5. create a credential
curl -X POST http://localhost:8001/consumers/user123/basic-auth \
    --data "username=Aladdin" \
    --data "password=OpenSesame"

# 6. comment the clearing logic and rebuild kong-init 
fn clear_before_init(context: &ExecutionContext) {
    info!("clear_before_init");
//    context.kong_cli.delete_all_plugins();
//    context.kong_cli.delete_all_routes();
//    context.kong_cli.delete_all_services();
}

# 7. verify using url with basic-auth plugin protected
RUST_LOG=kong_init=debug ./target/debug/kong-init --path ./example/kong14.v2.yaml --url http://localhost:8000/admin-api  --header 'Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l'

conclusion in short

arthmoeros commented 5 years ago

Let me check with the guys that made the jenkins pipeline that install our kong ee stack.

Because the admin api protection is done there, I just use kong-init to setup the routes, services and consumers, but the admin api protection is already setup.