aws / aws/aws-network-policy-agent
Network Policy Not Enforced on Initial Creation
- Dominant language
- Go
- Stars
- 75
- Forks
- 68
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 10
Description
I am experiencing an issue with network policies not being enforced upon their initial creation in my Kubernetes cluster using the AWS Network Policy Agent. The policies only take effect after being deleted and re-created. Below are the details of my configuration.
**Kubernetes YAML resources**
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: default-deny-ingress
namespace: demo
spec:
podSelector: {}
policyTypes:
- Ingress
Kubernetes Resources:
---
apiVersion: v1
kind: Service
metadata:
name: demo-app
namespace: demo
spec:
type: ClusterIP
ports:
- port: 80
selector:
app: demo-app
---
apiVersion: v1
kind: ConfigMap
metadata:
name: demo-app-index
namespace: demo
data:
index.html: |
Welcome to Amazon EKS!
html {color-scheme: light dark;}
body {width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif;}
Welcome to Amazon EKS!
If you see this page, you are able successfully access the web application as the network policy allows.
For online documentation and installation instructions please refer to
Amazon EKS Networking.
The migration guides are available at
Amazon EKS Network Policy Migration.
Thank you for using Amazon EKS.
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo-app
namespace: demo
spec:
selector:
matchLabels:
app: demo-app
replicas: 1
template:
metadata:
labels:
app: demo-app
spec:
containers:
- name: demo
image: public.ecr.aws/docker/library/nginx:stable
imagePullPolicy: IfNotPresent
volumeMounts:
- mountPath: /usr/share/nginx/html
name: nginx-index-volume
volumes:
- name: nginx-index-volume
configMap:
name: demo-app-index
---
apiVersion: v1
kind: Pod
metadata:
labels:
app: client-one
name: client-one
namespace: demo
spec:
containers:
- image: curlimages/curl:latest
name: client-one
command:
- sleep
- "360000"
---
apiVersion: v1
kind: Pod
metadata:
labels:
app: client-two
name: client-two
namespace: demo
spec:
containers:
- image: curlimages/curl:latest
name: client-two
command:
- sleep
- "360000"
```
**What happened**:
When the network policy is initially created, it does not enforce the ingress rules as expected. I am still able to access the demo-app service from the client-one pod. However, after deleting and re-creating the network policy, the policy is enforced correctly, and access is denied as expected.
**Attach logs**
Initial Network Policy Creation logs from Network Policy agent:
[not-working-infra.json](https://github.com/aws/aws-network-policy-agent/files/15355156/not-working-infra.json)
Delete of Network Policy logs:
[delete-log-infra.json](https://github.com/aws/aws-network-policy-agent/files/15355159/delete-log-infra.json)
Recreation of Network policy logs:
[working-infra.json](https://github.com/aws/aws-network-policy-agent/files/15355166/working-infra.json)
**What you expected to happen**:
The network policy should enforce the ingress rules upon initial creation without requiring deletion and re-creation.
**How to reproduce it (as minimally and precisely as possible)**:
1. Create the namespace and apply the network policy:
```
kubectl create namespace demo
kubectl apply -f network-policy.yaml
```
Deploy the Kubernetes resources:
```
kubectl apply -f kubernetes-resources.yaml
```
Test connectivity:
```
kubectl exec -it client-one -- curl demo-app # This returns HTML
```
Delete and re-create the network policy:
```
kubectl delete -f network-policy.yaml
kubectl apply -f network-policy.yaml
```
Test connectivity again:
```
kubectl exec -it client-one -- curl demo-app # This times out
```
**Anything else we need to know?**:
I have verified the CNI plugin configuration and ensured that it supports network policies. This issue seems to be related to the timing or synchronization of the policy application.
**Environment**:
EKS Version: 1.27
CNI Plugin: v1.18.1-eksbuild.1
Contributor guide
Research direction
Start by applying network-policy.yaml and kubernetes-resources.yaml with kubectl, then reproduce the curl checks before and after deleting and recreating the policy. Compare not-working-infra.json, delete-log-infra.json, and working-infra.json to identify why initial enforcement differs; done means the first policy application blocks client-one without recreation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, go, kubernetes
- Domain
- networking, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 35/100