aws-samples / hardeneks

Runs checks to see if an EKS cluster follows EKS Best Practices.
https://aws-samples.github.io/hardeneks/
MIT No Attribution
840 stars 89 forks source link

False Positive With "Don't bind clusterroles to anonymous/unauthenticated groups." #27

Closed NickTheSecurityDude closed 1 year ago

NickTheSecurityDude commented 1 year ago

It seems there is a possible false positive with the following: iam-->Cluster Wide-->Don't bind clusterroles to anonymous/unauthenticated groups.

It flagging "system:public-info-viewer - ClusterRoleBinding" EKS automatically creates this CRB.

If I remove this with the following command:

kubectl get ClusterRoleBinding -o json | jq -r '.items[] | select(.subjects[]?.name =="system:unauthenticated") | select(.metadata.name) | del(.subjects[] | select(.name =="system:unauthenticated"))'| kubectl apply -f -

It gets automatically re-added after a couple minutes:

# here its gone after I ran the above command
% ./rbac-lookup | grep -E 'system:(anonymous)|(unauthenticated)'

# then after a couple minutes, and run the same command again, its back:
% ./rbac-lookup | grep -E 'system:(anonymous)|(unauthenticated)'
system:unauthenticated                            cluster-wide   ClusterRole/system:public-info-viewer

Furthermore, according to the EKS best practice guide, it seems this particular role bound to the system:unauthenticated is OK:

Any role or ClusterRole other than system:public-info-viewer should not be bound to system:anonymous user or system:unauthenticated group.

Source:

Ergo, the check may need to exclude alerting for system:public-info-viewer bound to system:unauthenticated

dorukozturk commented 1 year ago

Great catch again. I will fix it as soon as possible.

dorukozturk commented 1 year ago

30 fixed it!