Here is just my personal consideration. It's indeed a complex problem when get involved in security issues.
Once we decide this function is only provided directly by the service instances, users can only log into the micro-service clusters to get access to these informations. In such case we can assume that the security should be guaranteed by users themselves. There are still several problems: 1. Usually there are all Linux OS servers in a cluster, with no graphical user interface. It may be hard to find a browser to read the informations. 2. If the instances enable Mutual TLS authentication, it may be difficult to get access to the informations directly. Or we can provide an isolated port for this feature, but it makes us further away from our security goal. If we provide a separate console service, maybe we can solve these problem. The console can be split into web page and backend service. The backend service can be deployed into the service cluster. It can be treated as a common micro-service, which means the security options of it can keep the same as other services. The web pages, if they are static page with html+js, can be deployed in the edge service. If users are concerned about the security issues, they can add authorization by themselves. I think this solution is flexible, but complex for many users. On conclusion, I guess if this feature is provided by service instances directly, it is less complex for us to implement it. While it may be not so practical in production environment. If this feature is provided by another console service, it's more complex, but there are more chances to apply it into a production environment. Yours sincerely Yao Haishi [email protected] On 3/5/2019 10:37，wjm wjm<[email protected]> wrote： this feature should be for both development and production environment, so must conside security problem. currently i'm not sure what's the best way to control it. yhs0092 <[email protected]> 于2019年3月5日周二 上午10:28写道： That's a great idea! What is the positioning of this feature? If it's designed for development environment trouble-shooting, I guess it's okay the web pages are provided by the micro-service instances directly. But if this feature is expected to work in production environment, which may contains massive micro-service instances, maybe it's better that service instances provide RESTful interfaces, and users get access to these informations via the console service. Yours sincerely Yao Haishi [email protected] On 3/5/2019 09:52，wjm wjm<[email protected]> wrote： @zhang_lei ServiceComb can run with spring boot, but will not depend on spring boot. wjm wjm <[email protected]> 于2019年3月5日周二 上午9:49写道： href of gif: https://issues.apache.org/jira/secure/attachment/12961084/swaggerAndDocument.gif and more question: how to define the security of the new feature should open a new port for the feature? wjm wjm <[email protected]> 于2019年3月5日周二 上午9:20写道： currently it's difficult to collect internal status of a microservice instance when some problem happened. eg: routing depend on cached instances, discovery tree, strategy of governances, and so on when we resolving routing related problem, we can only guess the status of all related modules. so we should provide a way to inspect the internal status of a microservice instance at runtime, maybe include: discovery tree isolation eventbus view schemas as swagger or html/pdf...... ...... maybe like the gif: my question: provide these informations include related html/js/css by instance directly, or only by governance console if provide by both instance and governance console, that will cause duplicate development if provide by instance what's the name of the module? "inspector"? swagger to html depend on "asciidoctor", which depend on jruby, it's very heavy. in my demo, resource of swagger and asciidoctor all load from cdn, but for some customer's environment, maybe can not connect to internet. any other idea?
