You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 26, 2023. It is now read-only.
EdgeX now allows users to run a security proxy (kong) to secure an EdgeX instance. Currently, the CLI only talks to the different micro services directly over HTTP. Ideally, we'd need to talk to those services through the kong gateway, which means generating a token to pass with every requests.
Describe the solution you'd like
The user would have to generate a token before using the CLI with security enabled. The token would be stored in the config file or an env variable. The config file would also contain a security_enabled variable which would activate or deactivate security.
The text was updated successfully, but these errors were encountered:
:57 @colin Hutchinson (Kong) your developer scripts commit to lock down access to 127.0.0.1 now forces users of edgex-cli to be on the same host! Had envisaged it as a tool to manipulate remote edgeX instances … this prompts moving to secure EdgeX support sooner than later! Good job, your fix works. 🙂
Big-B (Intel)(opens in new tab) 8:31 AM
@MaliniKB How about just adding a -remote switch to the cli that sends everything through the kong proxy? (Or EDGEX_KONG_TOKEN env var) (edited)
MaliniKB(opens in new tab) 8:47 AM
thats what I am thinking .. but it had not been a first focus of the CLI
Colin Hutchinson (Kong)(opens in new tab) 8:50 AM
may I propose:
ports:
- "8000:8000"
tty: true
environment:
as a stopgap?
8:51
so secure by default but can be overrode to 0.0.0.0 or your exact ip via an environment variable?
Big-B (Intel)(opens in new tab) 8:52 AM
You mean ${KONG_PUBLIC_IP} and do it on the other set?
Colin Hutchinson (Kong)(opens in new tab) 8:52 AM
whoops did the wrong port ... heh but yes 🙂
Big-B (Intel)(opens in new tab) 8:52 AM
but wait thats already public.
Colin Hutchinson (Kong)(opens in new tab) 8:53 AM
wait I got it right didn't I. That's a git diff so instead of binding admin api to 127 bind admin api to 127 by default let an ENV change it
Big-B (Intel)(opens in new tab) 8:53 AM
I think the problem may be that the cli is not proxy-aware. Expects all the other services to have exposed ports.
Colin Hutchinson (Kong)(opens in new tab) 8:54 AM
ooooh I thought this was purely the cli can't use kong admin api because of the restriction.
8:55
I mean could implement a global env override for all things I bound to 127 😕
8:58
might be best to punt this as a requirement for the docker-compose rewrite.
Use case: developer environment vs production environment
🚀 Feature Request
Description
EdgeX now allows users to run a security proxy (kong) to secure an EdgeX instance. Currently, the CLI only talks to the different micro services directly over HTTP. Ideally, we'd need to talk to those services through the kong gateway, which means generating a token to pass with every requests.
Describe the solution you'd like
The user would have to generate a token before using the CLI with security enabled. The token would be stored in the config file or an env variable. The config file would also contain a
security_enabled
variable which would activate or deactivate security.The text was updated successfully, but these errors were encountered: