I also find it very interesting that Network Policy API requires namespaces
to be labeled, rather than working with namespace names directly.

I wonder who out there is actively labeling their namespaces, but it sounds
like a good practice and a good use case for labels.

I have some off the shelf network policy recipes at
https://github.com/ahmetb/kubernetes-network-policy-recipes if you're
interested in getting things working through examples.

On Sun, Apr 29, 2018 at 11:59 PM 'mrpanigale' via Kubernetes user
discussion and Q&A <kubernetes-users@googlegroups.com> wrote:

> I also made the same incorrect assumptions. Thanks for identifying it, I
> will also give it a try.
>
> many kind regards,
>
> Andrew
>
> On Monday, April 30, 2018 at 8:34:13 AM UTC+2, Mark NS wrote:
>>
>> Gah, I could kick myself!
>>
>> I was expecting that
>>
>>   - from:
>>     - namespaceSelector:
>>         matchLabels:
>>           name: kube-system
>>
>> would match
>>
>> kind: Namespace
>> metadata:
>>   name: kube-system
>>
>> Which of course it won't... only when the label name: kube-system is
>> applied
>>
>> kind: Namespace
>> metadata:
>>   name: kube-system
>>   labels:
>>     name: kube-system
>>
>> Apologies for hijacking the thread, now to go and see if I can get this
>> working with the istio-ingress after all!
>>
>>
>> On Sunday, 29 April 2018 20:25:04 UTC+2, Mark NS wrote:
>>>
>>> Hi,
>>> I also seem to be unable to configure a network policy to allow pod
>>> ingress only from an nginx ingress-controller
>>>
>>> Here is what I did (GKE 1.8.8-gke.0):
>>> $ kubectl run web --image=gcr.io/google-samples/hello-app:1.0 --port=
>>> 8080
>>> $ kubectl expose deployment web --target-port=8080 --type=NodePort
>>> $ helm install stable/nginx-ingress --name nginx-ingress --namespace
>>> kube-system --set rbac.create=true
>>>
>>> $ cat <<'EOF' | kubectl create -f -
>>> apiVersion: extensions/v1beta1
>>> kind: Ingress
>>> metadata:
>>>   annotations:
>>>     kubernetes.io/ingress.class: nginx
>>>     name: basic-ingress
>>>   namespace: default
>>> spec:
>>>   backend:
>>>     serviceName: web
>>>     servicePort: 8080
>>> EOF
>>>
>>> $ cat <<'EOF' | kubectl create -f -
>>> apiVersion: extensions/v1beta1
>>> kind: NetworkPolicy
>>> metadata:
>>>   name: web-np
>>>   namespace: default
>>> spec:
>>>   policyTypes:
>>>   - Ingress
>>>   podSelector: {}
>>>   ingress:
>>>   - from:
>>>     - namespaceSelector:
>>>         matchLabels:
>>>           name: kube-system
>>>     ports:
>>>     - protocol: TCP
>>>       port: 8080
>>> EOF
>>>
>>> I think this should allow a connection from the nginx-controller running
>>> in kube-system namespace to the "web" pod running in default. However
>>> that's not successful:
>>> $ curl x.y.z:80
>>> <html>
>>> <head><title>504 Gateway Time-out</title></head>
>>> <body bgcolor="white">
>>> <center><h1>504 Gateway Time-out</h1></center>
>>> <hr><center>nginx/1.13.5</center>
>>> </body>
>>> </html>
>>>
>>> However, if I open the network policy to allow all traffic
>>>   podSelector: {}
>>>   ingress:
>>>     - {}
>>>
>>> then I can successfully connect to the pod:
>>> $ curl x.y.z:80
>>> Hello, world!
>>> Version: 1.0.0
>>> Hostname: web-6498765b79-b6866
>>>
>>> Also want to note that I've had a similar issue with the Istio ingress
>>> controller
>>> <https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/istio-users/8-7J3fAu9aU/5kBl0pAVBAAJ>
>>> :
>>>
>>> Is it possible to restrict ingress traffic to only the ingress
>>> controller?
>>>
>>> Thanks,
>>> Mark
>>>
>>>
>>>
>>> On Tuesday, 24 April 2018 12:38:03 UTC+2, mrpanigale wrote:
>>>>
>>>> When editing an already published network policy the namespace field is
>>>> automatically populated.
>>>>
>>>> On Saturday, March 10, 2018 at 1:13:24 AM UTC+1, Igor Cicimov wrote:
>>>>>
>>>>> This is missing `namespace:` in metadata
>>>>
>>>> --
> You received this message because you are subscribed to the Google Groups
> "Kubernetes user discussion and Q&A" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kubernetes-users+unsubscr...@googlegroups.com.
> To post to this group, send email to kubernetes-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/kubernetes-users.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q&A" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.
  • [kubernetes-... 'mrpanigale' via Kubernetes user discussion and Q&A
    • [kubern... iuk
    • [kubern... Igor Cicimov
      • [ku... 'mrpanigale' via Kubernetes user discussion and Q&A
        • ... Mark NS
          • ... Mark NS
            • ... 'mrpanigale' via Kubernetes user discussion and Q&A
              • ... 'Ahmet Alp Balkan' via Kubernetes user discussion and Q&A
                • ... 'mrpanigale' via Kubernetes user discussion and Q&A

Reply via email to