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.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19383): https://lists.onap.org/g/onap-discuss/message/19383
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]]
-=-=-=-=-=-=-=-=-=-=-=-
