@yaohai...@huawei.com <yaohai...@huawei.com> agree to you. but 1.graphical user interface is not a problem, network is a problem browser maybe can not connect to the instance directly 2.we must provide these features by governance console, the problem is if we will provide it by instance also? when provide by governance console, it's more powerful than by instance because instance can only have self information, but governance can show related instance's information.
yhs0092 <yhs0...@163.com> 于2019年3月5日周二 上午11:23写道： > 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 > yhs0...@163.com > > > On 3/5/2019 10:37，wjm wjm<zzz...@gmail.com> 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 <yhs0...@163.com> 于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 > yhs0...@163.com > > > On 3/5/2019 09:52，wjm wjm<zzz...@gmail.com> wrote： > @zhang_lei > > ServiceComb can run with spring boot, but will not depend on spring boot. > > > wjm wjm <zzz...@gmail.com> 于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 <zzz...@gmail.com> 于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? >
