OK, so what I'm hearing is that Sylvain would like to put SOME AAF components behind SideCars, not necessarily all. It would be a good exercise to determine in an ISTIO world what elements AAF would actually provide, as there are clearly overlaps.
Obviously, AAF was designed to secure all relevant components, and obviously, did it without Sidecars, as it was developed a few years before K8s or even Docker was popular. Therefore, my recommendation is to focus on non-security related ONAP Components (SSO and the like). Unfortunately, I can't spend a ton of time on this, as it's not a Frankfurt deliverable. But I appreciate being kept in the loop. -- Jonathan Gathman Principled-System Architect ATO Tech Dev/SEAT/Platform Architecture and Technology Management AT&T Services, Inc. m 314-550-3312 | [email protected] On 11/7/19, 7:41 AM, "Krzysztof Opasiak" <[email protected]> wrote: Hi Jonathatan, On 07.11.2019 14:31, GATHMAN, JONATHAN C wrote: > Right. > > We've actually worked through a lot of Side Car issues last year. > Amdocs created one for ONAP, and here's the main points, as we worked > it. Please correct me if I misstate something. > > 1. AAF was originally designed to give the security elements > (Certificates, ability to Authenticate/Authorize) on an HTTP/S stack > (ex: A Filter in Servlet, though that is not the only way). Agree. > 2. In any SideCar, you secure the Side Car, and setup protected > channels called Ingress and Egress to an otherwise unprotected MS. Agree. > 3. In the ONAP SideCar, they used AAF elements to secure the SideCar. > 1. IMPORTANT POINT: AAF is not IN the Sidecar. It is > Infrastructure used to SECURE the SideCar (instead of the MS > Directly). Yeah so AAF from Istio perspective is yet another web service that is used within ONAP. > > My assumption, when you talk about making AAF run as 127.0.0.1 so it can > run with Sidecar is that you are trying to put AAF itself into a > Sidecar, which doesn’t make any sense to me. Nope. aaf-locate is a service that can be access by other ONAP pod right? Sylvian is trying to deploy it using Istio. What this means, is that you have an istio sidecar added to that service (aaf-locate) which adds custom iptables rules and redirects all the traffic that is incoming to external interface to the "checker" that runs in a sidecar. The checker does some "chacking and policy" and if the traffic is allowed to reach the application it forwards the traffic to the app by sending it to the same port but on a localhost. Currently aaf-locate service is listening only on external interface which is intercepted by istio sidecar. This means that after sidecar decides that it can forward the traffic the traffic has no way to reach the application as the only interface that it was listening on has been intercepted by the sidecar. Best regards, -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics -- "Instrumental" PTL, AAF - ONAP Jonathan Gathman [email protected] -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19389): https://lists.onap.org/g/onap-discuss/message/19389 Mute This Topic: https://lists.onap.org/mt/45686190/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
