Re: [onap-tsc][onap-discuss]Questions about Security Requirements for Casablanca: is CADI the only option to enable RBAC?
Hi Jonathan, Appreciate your explanation. Glad to know Python CADI has been touched , hope it will be available sometime. But integration with CADI requires effort and knowledge to understand the whole workflow, and debug/maintain effort as well. It will be great if AAF team could come up with solution similar to k8s “side-cars” approach. I understand the “side-cars” is not applicable to HEAT deployed ONAP , but this will not be the only missing feature compared to OOM, resilience is only available with OOM, not heat, correct? If I captured the HEAT/OOM mode discussion correctly, HEAT mode is only for testing purpose from Casablanca release, which implies the released ONAP will have OOM mode only. Thanks Best Regards, Bin Yang,Solution Readiness Team,Wind River Direct +86,10,84777126Mobile +86,13811391682Fax +86,10,64398189 Skype: yangbincs993 From: GATHMAN, JONATHAN C [mailto:jg1...@att.com] Sent: Wednesday, June 27, 2018 6:15 PM To: Stephen Terrill; Yang, Bin; onap-tsc; onap-sec...@lists.onap.org Cc: onap-discuss@lists.onap.org Subject: Re: [onap-tsc][onap-discuss]Questions about Security Requirements for Casablanca: is CADI the only option to enable RBAC? Greetings, Bin, Secure calls using Python is different depending on the Environment. However, remember that for Casablanca, we are still on the hook for “HEAT” as well as OOM (where “OOM” is Kubernetes). If in Kubernetes, there is an effort underway to create a Security Microservice, and K8 provides for “Side-Cars” that can be created. I do not think there will be enough time for these for Casablanca. AAF is entirely RESTful, with standard HTTP/S authentications. Any language could call, but there needs to be Caching in calls to avoid superfluous network traffic, AAF Load. CADI Framework is written for Java, but has patterns for this behavior that can be used. There is such a CADI framework for JavaScript, which we may be able to have added into EComp sometime. I do have several people on my AT&T Team who have Python experience and have expressed interest in building a Python client. Summary: We have an effort with others, working on defining K8 solutions which alleviate language issues, but that doesn’t help HEAT or anything else outside of K8. Language specific CADI can be built, and there have been several requests for Python. Python CADI is not committed for Casablanca, though I have some folks with interest in doing such work. -- Jonathan Gathman Principled-System Architect ATO Tech Dev/SEAT/Platform Architecture and Technology Management AT&T Services, Inc. 2349 Oaker, Arnold, MO 63010 m 314-550-3312 | jonathan.gath...@us.att.com<mailto:jonathan.gath...@us.att.com> From: Stephen Terrill Date: Wednesday, June 27, 2018 at 3:04 AM To: "Yang, Bin" , onap-tsc , "onap-sec...@lists.onap.org" , "GATHMAN, JONATHAN C" Cc: "onap-discuss@lists.onap.org" Subject: RE: [onap-tsc][onap-discuss]Questions about Security Requirements for Casablanca: is CADI the only option to enable RBAC? Hi Bin, I am looping in the onap-seccom distribution list as well. @Jonathan, what guidance would you provide for Bin regarding use CAD with python? Best Regards, Steve. From: Yang, Bin Sent: Wednesday, June 27, 2018 5:57 AM To: Stephen Terrill ; onap-tsc Cc: onap-discuss@lists.onap.org Subject: [onap-tsc][onap-discuss]Questions about Security Requirements for Casablanca: is CADI the only option to enable RBAC? Dear TSC and Security Subcommittee, As part of S3P requirement, the CII Silver badge requires: * Level 2: CII Silver badge, plus: * All internal/external system communications shall be able to be encrypted. * All internal/external service calls shall have common role-based access control and authorization with CADI If I understand correctly, CADI is an SDK/framework from AAF. And integration with CADI needs AAF SDK which is only available with java binding, is that correct? As you know some ONAP projects are python based and it is a great challenge/burden for us to develop a python based CADI SDK. So this could be a risk need TSC/Security subcommittee’s attention, especially in case that TSC makes it a mandatory requirement for Casablanca. On the other hand, I am wondering what is the real intention with this security requirement. If the role-based access control is the key pursuit, then we should explore other alternatives. Before diving into the specific alternatives, I would like touch a little bit the different requirements between a “Role” for end-user and “Role” for internal service entities. * A role for end-user could be dynamically maintained/assigned since the end-users are created/deleted/updated during run-time. In that case some UI is needed and I guess this is what AAF/CADI is doing, correct? * A role for service-entity is another story
Re: [onap-tsc][onap-discuss]Questions about Security Requirements for Casablanca: is CADI the only option to enable RBAC?
Hi Srini, I believe for multicloud the access rules based on URI/HTTP header values are pretty enough. If ISTIO CA and RBAC could help that would be great relief. Thanks for the comment. Best Regards, Bin Yang,Solution Readiness Team,Wind River Direct +86,10,84777126Mobile +86,13811391682Fax +86,10,64398189 Skype: yangbincs993 From: onap-...@lists.onap.org [mailto:onap-...@lists.onap.org] On Behalf Of Srini Sent: Wednesday, June 27, 2018 5:45 PM To: Stephen Terrill; Yang, Bin; onap-tsc; onap-sec...@lists.onap.org; GATHMAN, JONATHAN C Cc: onap-discuss@lists.onap.org Subject: Re: [onap-tsc][onap-discuss]Questions about Security Requirements for Casablanca: is CADI the only option to enable RBAC? Hi Bin, As Ramki mentioned in the wiki page, ISTIO CA and ISTIO RBAC may be good enough for Multi-Cloud. But to be sure, it is good to know from Multi-Cloud team on what kind of APIs are present and what kind of restrictions the team thinks it should provide to various consumers of Multi-Cloud. If the access rules are based on the URI & HTTP request header values, then ISTIO RBAC is good enough. But, if the access rules are based on HTTP body data, then you need to rethink about ISTIO RBAC or rethink about putting that data part of URI and HTTP request header. Thanks Srini From: Yang, Bin mailto:bin.y...@windriver.com>> Sent: Wednesday, June 27, 2018 5:57 AM To: Stephen Terrill mailto:stephen.terr...@ericsson.com>>; onap-tsc mailto:onap-...@lists.onap.org>> Cc: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: [onap-tsc][onap-discuss]Questions about Security Requirements for Casablanca: is CADI the only option to enable RBAC? Dear TSC and Security Subcommittee, As part of S3P requirement, the CII Silver badge requires: *Level 2: CII Silver badge, plus: -All internal/external system communications shall be able to be encrypted. -All internal/external service calls shall have common role-based access control and authorization with CADI If I understand correctly, CADI is an SDK/framework from AAF. And integration with CADI needs AAF SDK which is only available with java binding, is that correct? As you know some ONAP projects are python based and it is a great challenge/burden for us to develop a python based CADI SDK. So this could be a risk need TSC/Security subcommittee's attention, especially in case that TSC makes it a mandatory requirement for Casablanca. On the other hand, I am wondering what is the real intention with this security requirement. If the role-based access control is the key pursuit, then we should explore other alternatives. Before diving into the specific alternatives, I would like touch a little bit the different requirements between a "Role" for end-user and "Role" for internal service entities. * A role for end-user could be dynamically maintained/assigned since the end-users are created/deleted/updated during run-time. In that case some UI is needed and I guess this is what AAF/CADI is doing, correct? * A role for service-entity is another story. The role for a service-entity should be designed at day 0 and configured during deployment time. And should be kept intact during the life cycle of the whole system (ONAP in this case). Hence there is no need to create/update/delete the role for a service-entity. If my understanding/assumption is correct, I believe those services which does not expose API/UI to end-users should control the access based on the "role for service-entity" because their API consumers are service-entities, not end-users. e.g. MultiCloud services's consumers are SO/VFC/APPC/etc. No end-user should access the MulitCloud APIs directly. Hence the access control based on the "role for service-entity" should be enough and will be provisioned during deployment. In this case ISTIO's RBAC could be an alternative, which fullfil the requirement of RBAC, while offering following beneficts: 1, leverage the ongoing effort with regarding to ISTIO for service mesh. 2, Reuse the same infrastructure to fulfill requirement w.r.t. "All internal/external system communications shall be able to be encrypted" 3, OOM/Kubernetes based/managed, easy to configure/maintain. 4, Projects are not impacted at all, no code change, no API change, etc. No SDK development/integration needed. This is my 2 cents. Please let me know if I got anything wrong/incomplete. Thanks. Best Regards, Bin Yang,Solution Readiness Team,Wind River Direct +86,10,84777126Mobile +86,13811391682Fax +86,10,64398189 Skype: yangbincs993 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10654): https://lists.onap.org/g/onap-discuss/message/10654 Mute This Topic: https://lists
Re: [Onap-seccom] [onap-tsc][onap-discuss]Questions about Security Requirements for Casablanca: is CADI the only option to enable RBAC?
FYI, when I say “AAF is entirely RESTful”, I mean that calling AAF is RESTful. This means that any language that can do HTTP/S and TEXT can talk to AAF legitimately, including, I’ve seen MainFrames. Just because AAF itself is RESTful does not mean that applications using AAF must be RESTful. The Case in point is that we have Cassandra implementations which use proprietary protocols for their Clients, but AAF supplies Authorization. The take away is that AAF should be callable by most anything, and they don’t have to be RESTful to do it. -- Jonathan Gathman Principled-System Architect ATO Tech Dev/SEAT/Platform Architecture and Technology Management AT&T Services, Inc. 2349 Oaker, Arnold, MO 63010 m 314-550-3312 | jonathan.gath...@us.att.com<mailto:jonathan.gath...@us.att.com> From: Samuli Kuusela Date: Wednesday, June 27, 2018 at 5:44 AM To: "GATHMAN, JONATHAN C" , Stephen Terrill , "Yang, Bin" , onap-tsc , "onap-sec...@lists.onap.org" Cc: "onap-discuss@lists.onap.org" Subject: RE: [Onap-seccom] [onap-tsc][onap-discuss]Questions about Security Requirements for Casablanca: is CADI the only option to enable RBAC? Hi, as this topic was discussed also in Risk Assessment sessions in Beijing F2F event, adding here some aspects (disclaimer, my summary text below has not been reviewed): Authentication and authorization (AA) solution: non-REST APIs, and components written in other language than Java are not supported by the current CADI/AAF [ref. Jonathan text below for more details & plans]. Also, integration of CADI with a 3PP component might not be feasible. Example: Kafka native APIs are not REST (under the DMaaP REST APIs), those may need to be used in order to match the performance requirements of real-time PM data streaming. - I followed Srini’s ISTIO preesnation and had a quick chat with him: this (Kafka) case should be solving by ISTIO usage. - Related, but different type of UC: xNF AA. Whether this UC is in the scope of ONAP has not been decided yet, I think (also think it should be..). In any case, the current xNFs in general do not support REST interfaces. brs, Samuli From: onap-sec...@lists.onap.org On Behalf Of GATHMAN, JONATHAN C Sent: 27. kesäkuuta 2018 13:15 To: Stephen Terrill ; Yang, Bin ; onap-tsc ; onap-sec...@lists.onap.org Cc: onap-discuss@lists.onap.org Subject: Re: [Onap-seccom] [onap-tsc][onap-discuss]Questions about Security Requirements for Casablanca: is CADI the only option to enable RBAC? Greetings, Bin, Secure calls using Python is different depending on the Environment. However, remember that for Casablanca, we are still on the hook for “HEAT” as well as OOM (where “OOM” is Kubernetes). If in Kubernetes, there is an effort underway to create a Security Microservice, and K8 provides for “Side-Cars” that can be created. I do not think there will be enough time for these for Casablanca. AAF is entirely RESTful, with standard HTTP/S authentications. Any language could call, but there needs to be Caching in calls to avoid superfluous network traffic, AAF Load. CADI Framework is written for Java, but has patterns for this behavior that can be used. There is such a CADI framework for JavaScript, which we may be able to have added into EComp sometime. I do have several people on my AT&T Team who have Python experience and have expressed interest in building a Python client. Summary: We have an effort with others, working on defining K8 solutions which alleviate language issues, but that doesn’t help HEAT or anything else outside of K8. Language specific CADI can be built, and there have been several requests for Python. Python CADI is not committed for Casablanca, though I have some folks with interest in doing such work. -- Jonathan Gathman Principled-System Architect ATO Tech Dev/SEAT/Platform Architecture and Technology Management AT&T Services, Inc. 2349 Oaker, Arnold, MO 63010 m 314-550-3312 | jonathan.gath...@us.att.com<mailto:jonathan.gath...@us.att.com> From: Stephen Terrill mailto:stephen.terr...@ericsson.com>> Date: Wednesday, June 27, 2018 at 3:04 AM To: "Yang, Bin" mailto:bin.y...@windriver.com>>, onap-tsc mailto:onap-...@lists.onap.org>>, "onap-sec...@lists.onap.org<mailto:onap-sec...@lists.onap.org>" mailto:onap-sec...@lists.onap.org>>, "GATHMAN, JONATHAN C" mailto:jg1...@att.com>> Cc: "onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>" mailto:onap-discuss@lists.onap.org>> Subject: RE: [onap-tsc][onap-discuss]Questions about Security Requirements for Casablanca: is CADI the only option to enable RBAC? Hi Bin, I am looping in the onap-seccom distribution list as well. @Jonathan, what guidance would you provide for Bin regarding use CAD with python? Best Regards, Steve. From: Yang,
Re: [onap-tsc][onap-discuss]Questions about Security Requirements for Casablanca: is CADI the only option to enable RBAC?
Greetings, Bin, Secure calls using Python is different depending on the Environment. However, remember that for Casablanca, we are still on the hook for “HEAT” as well as OOM (where “OOM” is Kubernetes). If in Kubernetes, there is an effort underway to create a Security Microservice, and K8 provides for “Side-Cars” that can be created. I do not think there will be enough time for these for Casablanca. AAF is entirely RESTful, with standard HTTP/S authentications. Any language could call, but there needs to be Caching in calls to avoid superfluous network traffic, AAF Load. CADI Framework is written for Java, but has patterns for this behavior that can be used. There is such a CADI framework for JavaScript, which we may be able to have added into EComp sometime. I do have several people on my AT&T Team who have Python experience and have expressed interest in building a Python client. Summary: We have an effort with others, working on defining K8 solutions which alleviate language issues, but that doesn’t help HEAT or anything else outside of K8. Language specific CADI can be built, and there have been several requests for Python. Python CADI is not committed for Casablanca, though I have some folks with interest in doing such work. -- Jonathan Gathman Principled-System Architect ATO Tech Dev/SEAT/Platform Architecture and Technology Management AT&T Services, Inc. 2349 Oaker, Arnold, MO 63010 m 314-550-3312 | jonathan.gath...@us.att.com<mailto:jonathan.gath...@us.att.com> From: Stephen Terrill Date: Wednesday, June 27, 2018 at 3:04 AM To: "Yang, Bin" , onap-tsc , "onap-sec...@lists.onap.org" , "GATHMAN, JONATHAN C" Cc: "onap-discuss@lists.onap.org" Subject: RE: [onap-tsc][onap-discuss]Questions about Security Requirements for Casablanca: is CADI the only option to enable RBAC? Hi Bin, I am looping in the onap-seccom distribution list as well. @Jonathan, what guidance would you provide for Bin regarding use CAD with python? Best Regards, Steve. From: Yang, Bin Sent: Wednesday, June 27, 2018 5:57 AM To: Stephen Terrill ; onap-tsc Cc: onap-discuss@lists.onap.org Subject: [onap-tsc][onap-discuss]Questions about Security Requirements for Casablanca: is CADI the only option to enable RBAC? Dear TSC and Security Subcommittee, As part of S3P requirement, the CII Silver badge requires: * Level 2: CII Silver badge, plus: * All internal/external system communications shall be able to be encrypted. * All internal/external service calls shall have common role-based access control and authorization with CADI If I understand correctly, CADI is an SDK/framework from AAF. And integration with CADI needs AAF SDK which is only available with java binding, is that correct? As you know some ONAP projects are python based and it is a great challenge/burden for us to develop a python based CADI SDK. So this could be a risk need TSC/Security subcommittee’s attention, especially in case that TSC makes it a mandatory requirement for Casablanca. On the other hand, I am wondering what is the real intention with this security requirement. If the role-based access control is the key pursuit, then we should explore other alternatives. Before diving into the specific alternatives, I would like touch a little bit the different requirements between a “Role” for end-user and “Role” for internal service entities. * A role for end-user could be dynamically maintained/assigned since the end-users are created/deleted/updated during run-time. In that case some UI is needed and I guess this is what AAF/CADI is doing, correct? * A role for service-entity is another story. The role for a service-entity should be designed at day 0 and configured during deployment time. And should be kept intact during the life cycle of the whole system (ONAP in this case). Hence there is no need to create/update/delete the role for a service-entity. If my understanding/assumption is correct, I believe those services which does not expose API/UI to end-users should control the access based on the “role for service-entity” because their API consumers are service-entities, not end-users. e.g. MultiCloud services’s consumers are SO/VFC/APPC/etc. No end-user should access the MulitCloud APIs directly. Hence the access control based on the “role for service-entity” should be enough and will be provisioned during deployment. In this case ISTIO’s RBAC could be an alternative, which fullfil the requirement of RBAC, while offering following beneficts: 1, leverage the ongoing effort with regarding to ISTIO for service mesh. 2, Reuse the same infrastructure to fulfill requirement w.r.t. “All internal/external system communications shall be able to be encrypted” 3, OOM/Kubernetes based/managed, easy to configure/maintain. 4, Projects are not impacted at all, n
Re: [Onap-seccom] [onap-tsc][onap-discuss]Questions about Security Requirements for Casablanca: is CADI the only option to enable RBAC?
Hi, as this topic was discussed also in Risk Assessment sessions in Beijing F2F event, adding here some aspects (disclaimer, my summary text below has not been reviewed): Authentication and authorization (AA) solution: non-REST APIs, and components written in other language than Java are not supported by the current CADI/AAF [ref. Jonathan text below for more details & plans]. Also, integration of CADI with a 3PP component might not be feasible. Example: Kafka native APIs are not REST (under the DMaaP REST APIs), those may need to be used in order to match the performance requirements of real-time PM data streaming. - I followed Srini’s ISTIO preesnation and had a quick chat with him: this (Kafka) case should be solving by ISTIO usage. - Related, but different type of UC: xNF AA. Whether this UC is in the scope of ONAP has not been decided yet, I think (also think it should be..). In any case, the current xNFs in general do not support REST interfaces. brs, Samuli From: onap-sec...@lists.onap.org On Behalf Of GATHMAN, JONATHAN C Sent: 27. kesäkuuta 2018 13:15 To: Stephen Terrill ; Yang, Bin ; onap-tsc ; onap-sec...@lists.onap.org Cc: onap-discuss@lists.onap.org Subject: Re: [Onap-seccom] [onap-tsc][onap-discuss]Questions about Security Requirements for Casablanca: is CADI the only option to enable RBAC? Greetings, Bin, Secure calls using Python is different depending on the Environment. However, remember that for Casablanca, we are still on the hook for “HEAT” as well as OOM (where “OOM” is Kubernetes). If in Kubernetes, there is an effort underway to create a Security Microservice, and K8 provides for “Side-Cars” that can be created. I do not think there will be enough time for these for Casablanca. AAF is entirely RESTful, with standard HTTP/S authentications. Any language could call, but there needs to be Caching in calls to avoid superfluous network traffic, AAF Load. CADI Framework is written for Java, but has patterns for this behavior that can be used. There is such a CADI framework for JavaScript, which we may be able to have added into EComp sometime. I do have several people on my AT&T Team who have Python experience and have expressed interest in building a Python client. Summary: We have an effort with others, working on defining K8 solutions which alleviate language issues, but that doesn’t help HEAT or anything else outside of K8. Language specific CADI can be built, and there have been several requests for Python. Python CADI is not committed for Casablanca, though I have some folks with interest in doing such work. -- Jonathan Gathman Principled-System Architect ATO Tech Dev/SEAT/Platform Architecture and Technology Management AT&T Services, Inc. 2349 Oaker, Arnold, MO 63010 m 314-550-3312 | jonathan.gath...@us.att.com<mailto:jonathan.gath...@us.att.com> From: Stephen Terrill mailto:stephen.terr...@ericsson.com>> Date: Wednesday, June 27, 2018 at 3:04 AM To: "Yang, Bin" mailto:bin.y...@windriver.com>>, onap-tsc mailto:onap-...@lists.onap.org>>, "onap-sec...@lists.onap.org<mailto:onap-sec...@lists.onap.org>" mailto:onap-sec...@lists.onap.org>>, "GATHMAN, JONATHAN C" mailto:jg1...@att.com>> Cc: "onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>" mailto:onap-discuss@lists.onap.org>> Subject: RE: [onap-tsc][onap-discuss]Questions about Security Requirements for Casablanca: is CADI the only option to enable RBAC? Hi Bin, I am looping in the onap-seccom distribution list as well. @Jonathan, what guidance would you provide for Bin regarding use CAD with python? Best Regards, Steve. From: Yang, Bin mailto:bin.y...@windriver.com>> Sent: Wednesday, June 27, 2018 5:57 AM To: Stephen Terrill mailto:stephen.terr...@ericsson.com>>; onap-tsc mailto:onap-...@lists.onap.org>> Cc: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: [onap-tsc][onap-discuss]Questions about Security Requirements for Casablanca: is CADI the only option to enable RBAC? Dear TSC and Security Subcommittee, As part of S3P requirement, the CII Silver badge requires: * Level 2: CII Silver badge, plus: * All internal/external system communications shall be able to be encrypted. * All internal/external service calls shall have common role-based access control and authorization with CADI If I understand correctly, CADI is an SDK/framework from AAF. And integration with CADI needs AAF SDK which is only available with java binding, is that correct? As you know some ONAP projects are python based and it is a great challenge/burden for us to develop a python based CADI SDK. So this could be a risk need TSC/Security subcommittee’s attention, especially in case that TSC makes it a mandatory requirement for Casablanca. On the other hand, I am
Re: [onap-tsc][onap-discuss]Questions about Security Requirements for Casablanca: is CADI the only option to enable RBAC?
Hi Bin, As Ramki mentioned in the wiki page, ISTIO CA and ISTIO RBAC may be good enough for Multi-Cloud. But to be sure, it is good to know from Multi-Cloud team on what kind of APIs are present and what kind of restrictions the team thinks it should provide to various consumers of Multi-Cloud. If the access rules are based on the URI & HTTP request header values, then ISTIO RBAC is good enough. But, if the access rules are based on HTTP body data, then you need to rethink about ISTIO RBAC or rethink about putting that data part of URI and HTTP request header. Thanks Srini From: Yang, Bin mailto:bin.y...@windriver.com>> Sent: Wednesday, June 27, 2018 5:57 AM To: Stephen Terrill mailto:stephen.terr...@ericsson.com>>; onap-tsc mailto:onap-...@lists.onap.org>> Cc: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: [onap-tsc][onap-discuss]Questions about Security Requirements for Casablanca: is CADI the only option to enable RBAC? Dear TSC and Security Subcommittee, As part of S3P requirement, the CII Silver badge requires: *Level 2: CII Silver badge, plus: -All internal/external system communications shall be able to be encrypted. -All internal/external service calls shall have common role-based access control and authorization with CADI If I understand correctly, CADI is an SDK/framework from AAF. And integration with CADI needs AAF SDK which is only available with java binding, is that correct? As you know some ONAP projects are python based and it is a great challenge/burden for us to develop a python based CADI SDK. So this could be a risk need TSC/Security subcommittee's attention, especially in case that TSC makes it a mandatory requirement for Casablanca. On the other hand, I am wondering what is the real intention with this security requirement. If the role-based access control is the key pursuit, then we should explore other alternatives. Before diving into the specific alternatives, I would like touch a little bit the different requirements between a "Role" for end-user and "Role" for internal service entities. * A role for end-user could be dynamically maintained/assigned since the end-users are created/deleted/updated during run-time. In that case some UI is needed and I guess this is what AAF/CADI is doing, correct? * A role for service-entity is another story. The role for a service-entity should be designed at day 0 and configured during deployment time. And should be kept intact during the life cycle of the whole system (ONAP in this case). Hence there is no need to create/update/delete the role for a service-entity. If my understanding/assumption is correct, I believe those services which does not expose API/UI to end-users should control the access based on the "role for service-entity" because their API consumers are service-entities, not end-users. e.g. MultiCloud services's consumers are SO/VFC/APPC/etc. No end-user should access the MulitCloud APIs directly. Hence the access control based on the "role for service-entity" should be enough and will be provisioned during deployment. In this case ISTIO's RBAC could be an alternative, which fullfil the requirement of RBAC, while offering following beneficts: 1, leverage the ongoing effort with regarding to ISTIO for service mesh. 2, Reuse the same infrastructure to fulfill requirement w.r.t. "All internal/external system communications shall be able to be encrypted" 3, OOM/Kubernetes based/managed, easy to configure/maintain. 4, Projects are not impacted at all, no code change, no API change, etc. No SDK development/integration needed. This is my 2 cents. Please let me know if I got anything wrong/incomplete. Thanks. Best Regards, Bin Yang,Solution Readiness Team,Wind River Direct +86,10,84777126Mobile +86,13811391682Fax +86,10,64398189 Skype: yangbincs993 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10610): https://lists.onap.org/g/onap-discuss/message/10610 Mute This Topic: https://lists.onap.org/mt/22707998/21656 Group Owner: onap-discuss+ow...@lists.onap.org Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [onap-tsc][onap-discuss]Questions about Security Requirements for Casablanca: is CADI the only option to enable RBAC?
Hi Bin, I am looping in the onap-seccom distribution list as well. @Jonathan, what guidance would you provide for Bin regarding use CAD with python? Best Regards, Steve. From: Yang, Bin Sent: Wednesday, June 27, 2018 5:57 AM To: Stephen Terrill ; onap-tsc Cc: onap-discuss@lists.onap.org Subject: [onap-tsc][onap-discuss]Questions about Security Requirements for Casablanca: is CADI the only option to enable RBAC? Dear TSC and Security Subcommittee, As part of S3P requirement, the CII Silver badge requires: * Level 2: CII Silver badge, plus: * All internal/external system communications shall be able to be encrypted. * All internal/external service calls shall have common role-based access control and authorization with CADI If I understand correctly, CADI is an SDK/framework from AAF. And integration with CADI needs AAF SDK which is only available with java binding, is that correct? As you know some ONAP projects are python based and it is a great challenge/burden for us to develop a python based CADI SDK. So this could be a risk need TSC/Security subcommittee's attention, especially in case that TSC makes it a mandatory requirement for Casablanca. On the other hand, I am wondering what is the real intention with this security requirement. If the role-based access control is the key pursuit, then we should explore other alternatives. Before diving into the specific alternatives, I would like touch a little bit the different requirements between a "Role" for end-user and "Role" for internal service entities. * A role for end-user could be dynamically maintained/assigned since the end-users are created/deleted/updated during run-time. In that case some UI is needed and I guess this is what AAF/CADI is doing, correct? * A role for service-entity is another story. The role for a service-entity should be designed at day 0 and configured during deployment time. And should be kept intact during the life cycle of the whole system (ONAP in this case). Hence there is no need to create/update/delete the role for a service-entity. If my understanding/assumption is correct, I believe those services which does not expose API/UI to end-users should control the access based on the "role for service-entity" because their API consumers are service-entities, not end-users. e.g. MultiCloud services's consumers are SO/VFC/APPC/etc. No end-user should access the MulitCloud APIs directly. Hence the access control based on the "role for service-entity" should be enough and will be provisioned during deployment. In this case ISTIO's RBAC could be an alternative, which fullfil the requirement of RBAC, while offering following beneficts: 1, leverage the ongoing effort with regarding to ISTIO for service mesh. 2, Reuse the same infrastructure to fulfill requirement w.r.t. "All internal/external system communications shall be able to be encrypted" 3, OOM/Kubernetes based/managed, easy to configure/maintain. 4, Projects are not impacted at all, no code change, no API change, etc. No SDK development/integration needed. This is my 2 cents. Please let me know if I got anything wrong/incomplete. Thanks. Best Regards, Bin Yang,Solution Readiness Team,Wind River Direct +86,10,84777126Mobile +86,13811391682Fax +86,10,64398189 Skype: yangbincs993 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10608): https://lists.onap.org/g/onap-discuss/message/10608 Mute This Topic: https://lists.onap.org/mt/22707998/21656 Group Owner: onap-discuss+ow...@lists.onap.org Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[onap-tsc][onap-discuss]Questions about Security Requirements for Casablanca: is CADI the only option to enable RBAC?
Dear TSC and Security Subcommittee, As part of S3P requirement, the CII Silver badge requires: *Level 2: CII Silver badge, plus: -All internal/external system communications shall be able to be encrypted. -All internal/external service calls shall have common role-based access control and authorization with CADI If I understand correctly, CADI is an SDK/framework from AAF. And integration with CADI needs AAF SDK which is only available with java binding, is that correct? As you know some ONAP projects are python based and it is a great challenge/burden for us to develop a python based CADI SDK. So this could be a risk need TSC/Security subcommittee's attention, especially in case that TSC makes it a mandatory requirement for Casablanca. On the other hand, I am wondering what is the real intention with this security requirement. If the role-based access control is the key pursuit, then we should explore other alternatives. Before diving into the specific alternatives, I would like touch a little bit the different requirements between a "Role" for end-user and "Role" for internal service entities. *A role for end-user could be dynamically maintained/assigned since the end-users are created/deleted/updated during run-time. In that case some UI is needed and I guess this is what AAF/CADI is doing, correct? *A role for service-entity is another story. The role for a service-entity should be designed at day 0 and configured during deployment time. And should be kept intact during the life cycle of the whole system (ONAP in this case). Hence there is no need to create/update/delete the role for a service-entity. If my understanding/assumption is correct, I believe those services which does not expose API/UI to end-users should control the access based on the "role for service-entity" because their API consumers are service-entities, not end-users. e.g. MultiCloud services's consumers are SO/VFC/APPC/etc. No end-user should access the MulitCloud APIs directly. Hence the access control based on the "role for service-entity" should be enough and will be provisioned during deployment. In this case ISTIO's RBAC could be an alternative, which fullfil the requirement of RBAC, while offering following beneficts: 1, leverage the ongoing effort with regarding to ISTIO for service mesh. 2, Reuse the same infrastructure to fulfill requirement w.r.t. "All internal/external system communications shall be able to be encrypted" 3, OOM/Kubernetes based/managed, easy to configure/maintain. 4, Projects are not impacted at all, no code change, no API change, etc. No SDK development/integration needed. This is my 2 cents. Please let me know if I got anything wrong/incomplete. Thanks. Best Regards, Bin Yang,Solution Readiness Team,Wind River Direct +86,10,84777126Mobile +86,13811391682Fax +86,10,64398189 Skype: yangbincs993 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10601): https://lists.onap.org/g/onap-discuss/message/10601 Mute This Topic: https://lists.onap.org/mt/22707998/21656 Group Owner: onap-discuss+ow...@lists.onap.org Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
