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 <[email protected]> Sent: Wednesday, June 27, 2018 5:57 AM To: Stephen Terrill <[email protected]>; onap-tsc <[email protected]> Cc: [email protected] 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,84777126 Mobile +86,13811391682 Fax +86,10,64398189 Skype: yangbincs993 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3215): https://lists.onap.org/g/ONAP-TSC/message/3215 Mute This Topic: https://lists.onap.org/mt/22707999/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/ONAP-TSC/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
