On 07.11.2019 14:39, GATHMAN, JONATHAN C wrote:
> 
> On 11/7/19, 7:09 AM, "Krzysztof Opasiak" <[email protected]> wrote:
> 
>      Hi Jonathan,
>
>      On 07.11.2019 13:37, GATHMAN, JONATHAN C wrote:
>      > 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. __
>
>      That's a good assumptions for stuff that are running "in the box" or in
>      VM but not for containers. As we are moving towards more cloud native
>      deployment your application should listen on all available interfaces
>      unless you are using multus or stuff like that. But then you probably
>      have some policy where to listen for the incoming traffic. Otherwise you
>      should just trust that that people who deploy your application know how
>      to ensure its security by defining a proper network policy for k8s
>      cluster and attaching proper type of network interfaces to your 
> container.
>
>      >
>      >    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".
>
>      I do appreciate good security practices in ATT and their positive
>      influence on ONAP, but as long as we are talking about ONAP open source
>      project policies should be defined by the community not by a single 
> company.
> 
> ###. NOTE:  I was NOT trying to impose AT&T Security Standards on ONAP.  I 
> was stating examples of Security Software tooling that does NOT allow 
> 127.0.0.1, as a warning to ONAP that OTHER Companies that are NOT AT&T might 
> have similar security Standards.

I'm not against not having localhost listen enabled by default but I'm 
against lack of ability to enable it;)

>
>      >
>      > 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.
>      >
>
>      For me this sounds like some nasty hack to just bypass some "clever"
>      security tooling that greps for localhost keyword in the repo;)
> 
> #### This is not a Hack, unless you consider /etc/hosts is a hack.  This is a 
> better way to DEVELOP locally with REAL IPs without having to have your 
> personal box available on DNS.
> ##### HOWEVER.  The real point is that Sylvain wasn't trying to develop 
> locally per se.   He validly pointed out that the 127.0.0.1 is used by ISTIO 
> for Isolation behind the Sidecar.  Therefore, my recommendation (which was 
> for how to run AAF Locally on your PC) doesn't address the question...

but why do we need a DNS entry at all in order to just run a web server? 
Isn't IP just enough?

Best regards,
-- 
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#19399): https://lists.onap.org/g/onap-discuss/message/19399
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]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to