No my goal is to use service mesh and have a sidecar near aaf pods. So AAF wouldn’t be in a sidecar but AAF would be in the mesh like the other components of ONAP, so we can at least see tracing between pods when we troubleshoot operational issues.
--- Sylvain Desbureaux De : "GATHMAN, JONATHAN C" <[email protected]> Date : jeudi 7 novembre 2019 à 14:32 À : DESBUREAUX Sylvain TGI/OLN <[email protected]>, Krzysztof Opasiak <[email protected]>, "[email protected]" <[email protected]> Cc : "[email protected]" <[email protected]> Objet : Re: [onap-discuss] [ONA][AAF] AAF with Istio/linkerd 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). 2. In any SideCar, you secure the Side Car, and setup protected channels called Ingress and Egress to an otherwise unprotected MS. 3. In the ONAP SideCar, they used AAF elements to secure the SideCar. * IMPORTANT POINT: AAF is not IN the Sidecar. It is Infrastructure used to SECURE the SideCar (instead of the MS Directly). 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. If you are using Istio with AAF, IIMHO, you have to figure out how to implement Istio SideCar Authentication and/or Authorization Interfaces (if that exists) with AAF running as it does today… outside of the SideCars themselves. -- 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, 6:51 AM, "[email protected]" <[email protected]> wrote: Hi Jonathan and thanks for the reply, My purpose is to (try to) install ONAP (actually a subset) into a Kubernetes Cluster with service mesh enabled (in particular istio -- https://urldefense.proofpoint.com/v2/url?u=https-3A__istio.io&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=jxRielOoGyNWi5tOCRKusgUTQisLiqE_bMTrKwvJIvI&m=izHcjMcyZjt62G5W7OHOK1JCiNkHBH5Abn-iGovE1h4&s=OwT8H6eNMJ4Bs7KLawgwU0ThG3X6PlCr0u-u2Qxves4&e= -- and linkerd -- https://urldefense.proofpoint.com/v2/url?u=https-3A__linkerd.io_&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=jxRielOoGyNWi5tOCRKusgUTQisLiqE_bMTrKwvJIvI&m=izHcjMcyZjt62G5W7OHOK1JCiNkHBH5Abn-iGovE1h4&s=aNoGFK2CKfQY007Kkw0nlfg7HfxgOYqis0_rVnmP9aU&e=). These service meshes automatically add at start of a POD a "sidecar" (another container in the same cgroup) which will proxy all network requests. The purpose is to : * add tracing (and thus visibility) * add (later on) network policy (for example allow only aaf pods to connect to aaf cassandra) * add metrics for operations * add automatic mTLS between pods In order to do that, these proxies intercept the network, and if it's accepted, send it back to the destination container. But in order to do that, they point the destination container as 127.0.0.1:CONTAINER_PORT (127.0.0.1:8095 for aaf-locate for example). See here https://urldefense.proofpoint.com/v2/url?u=https-3A__istio.io_docs_reference_config_networking_v1alpha3_sidecar_&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=jxRielOoGyNWi5tOCRKusgUTQisLiqE_bMTrKwvJIvI&m=izHcjMcyZjt62G5W7OHOK1JCiNkHBH5Abn-iGovE1h4&s=g7QRBU7fMGLy5yAPxZMxSW1mA6OU-WbL61GyXluVCbc&e= for a better (and more accurate) explanation And here an explanation on cassandra: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_istio_istio.io_blob_master_content_en_faq_applications_cassandra.md&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=jxRielOoGyNWi5tOCRKusgUTQisLiqE_bMTrKwvJIvI&m=izHcjMcyZjt62G5W7OHOK1JCiNkHBH5Abn-iGovE1h4&s=CzAyTBQLq8LRypwxR7PMkDoVY9Hg6mjRbRMvpu1-IC8&e= So if I want to deploy ONAP on top of these service meshes, I need application to listen at least on 127.0.0.1 (but everywhere is fine too). And I don't see how I can achieve that with AAF components today Hoping that I'm clear, --- Sylvain Desbureaux Le 07/11/2019 13:37, « GATHMAN, JONATHAN C » <[email protected]> a écrit : Greetings, May I assume that your need for 127.0.0.1 is so you can develop with? Some History: Security Policies from the past tend to frown on "localhost", because some people wrote code that assumed if processes on running on the box, they are secure. This is not a good assumption. Also, 127.0.0.1, as an IP, is not unique... Every box has one. __ For that reason, SOME Security tooling (at least ones that AAF supports at AT&T) denies the use of 127.0.0.1 or "localhost". What to do instead: What works better is to come up with a valid name. For my local AAF Instances, I use "aaf.osaaf.org" (my ONAP Namespace). I then enter that name into /etc/hosts with supporting IP from "minikube" (which is how I run K8s). Ex 192.168.64.1 aaf.osaaf.org At this point, everything is validly running that I need in my K8s private net, and, of course, not accessible externally. For AAF, we get "hostname" onto a property file in docker through the use of "Init" docker. Let me know if you need to explore that part. -- 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, 5:46 AM, "Krzysztof Opasiak" <[email protected]> wrote: HI Sylvian, I did just some short lookup so this may not work but I think is worth to try: try setting the hostname property for locator as based on what I see in init logs: 2019-10-31 05:05:03,328+0000 2019-10-31T05:05:03.328+0000 INIT [init] hostname is not explicitly set 2019-10-31 05:05:03,328+0000 2019-10-31T05:05:03.328+0000 INIT [init] Hostname set to dev-aaf-aaf-locate-7c89f876c4-q7cdf which I think is generated by: // Setup Host, in case Network reports an unusable Hostname (i.e. VTiers, VPNs, etc) String hostname = logProp(access, HOSTNAME,null); if (hostname==null) { try { hostname = InetAddress.getLocalHost().getHostName(); } catch (UnknownHostException e1) { throw new CadiException("Unable to determine Hostname",e1); } } access.log(Level.INIT, "Hostname set to",hostname); in cadi/core/src/main/java/org/onap/aaf/cadi/config/Config.java so I believe that if you explicitly set this you should be able to force aaf to listen on all network interfaces or at least on localhost On 07.11.2019 11:44, [email protected] wrote: > Hi Krzysztof, > I agree but I also don't know how to do it in aaf ^_^. > > --- > Sylvain Desbureaux > > Le 07/11/2019 11:43, « Krzysztof Opasiak » <[email protected]> a écrit : > > Hi Sylvian, > > On 07.11.2019 11:39, Sylvain Desbureaux via Lists.Onap.Org wrote: > > Sorry, bad mail address > > > > --- > > > > Sylvain Desbureaux > > > > *De : *DESBUREAUX Sylvain TGI/OLN <[email protected]> > > *Date : *jeudi 7 novembre 2019 à 11:38 > > *À : *"[email protected]" <[email protected]> > > *Cc : *"[email protected]" <[email protected]>, > > "[email protected]" <[email protected]> > > *Objet : *[ONA][AAF] AAF with Istio/linkerd > > > > Hello Jonathan, > > > > I’m trying to make work ONAP on a kubernetes with service mesh (linkerd, > > istio and consul connect as service mesh). > > > > As these service meshes add “sidecars” to PODs, every requests sent to > > the pod is intercepted by the sidecar and sent back from the sidecar. It > > means that you need to listen on 127.0.0.1 and not on the public ip. > > > > Today, aaf-locate (and maybe others 😉) are listening on public ip. I’ve > > taken a look at the configuration and at the code and I don’t see if > > it’s possible to listen to 127.0.0.1 and if yes how to “tell” aaf-locate > > to do so… > > > > I’ve seen that in > > auth/auth-core/src/main/java/org/onap/aaf/auth/server/AbsServiceStarter.java, > > we use the hostname but I’m not sure how to “force” to 127.0.0.1. > > You don't need to force the localhost, you can just make sure that it > listens on all available interfaces (0.0.0.0) which shouldn't break > anything and then make it work also with istio;) > > > -- > Krzysztof Opasiak > Samsung R&D Institute Poland > Samsung Electronics > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19384): https://lists.onap.org/g/onap-discuss/message/19384 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]] -=-=-=-=-=-=-=-=-=-=-=-
