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,84777126 Mobile +86,13811391682 Fax +86,10,64398189
Skype: yangbincs993
From: GATHMAN, JONATHAN C [mailto:[email protected]]
Sent: Wednesday, June 27, 2018 6:15 PM
To: Stephen Terrill; Yang, Bin; onap-tsc; [email protected]
Cc: [email protected]
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 |
[email protected]<mailto:[email protected]>
From: Stephen Terrill <[email protected]>
Date: Wednesday, June 27, 2018 at 3:04 AM
To: "Yang, Bin" <[email protected]>, onap-tsc <[email protected]>,
"[email protected]" <[email protected]>, "GATHMAN, JONATHAN
C" <[email protected]>
Cc: "[email protected]" <[email protected]>
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 <[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 (#3222): https://lists.onap.org/g/ONAP-TSC/message/3222
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]]
-=-=-=-=-=-=-=-=-=-=-=-
