What would you like to be enhanced:
mutating admission webhook "mpod.vpc.k8s.aws" pod spec handling should be revisited
Why is the change needed and what use case will it solve:
Currently the mutating admission webhook "mpod.vpc.k8s.aws" fails with error message:
admission webhook "mpod.vpc.k8s.aws" denied the request: Failed to get Matching SGP for Pods, rejecting event if pod.Spec.ServiceAccountName is not existing in namespace , code in /pkg/utils/helper.go in function GetMatchingSecurityGroupForPods here.
It is not the responsibility of VPC resource controller though to reject pod admission for that reason. This is confusing for user, esepcially giving the fact that VPC resource controller logs are not exposed in EKS (see issue [EKS] [request]: Support VPC-RC logging options for Amazon EKS control plane #2190, and the rejection should be done in other places of K8s.
At least or more meaningful error message should be exposed, in case the service account is needed inside the VPC resource controller.
What would you like to be enhanced:
mutating admission webhook "mpod.vpc.k8s.aws" pod spec handling should be revisited
Why is the change needed and what use case will it solve:
Currently the mutating admission webhook "mpod.vpc.k8s.aws" fails with error message:
admission webhook "mpod.vpc.k8s.aws" denied the request: Failed to get Matching SGP for Pods, rejecting eventifpod.Spec.ServiceAccountNameis not existing in namespace , code in/pkg/utils/helper.goin functionGetMatchingSecurityGroupForPodshere.It is not the responsibility of VPC resource controller though to reject pod admission for that reason. This is confusing for user, esepcially giving the fact that VPC resource controller logs are not exposed in EKS (see issue [EKS] [request]: Support VPC-RC logging options for Amazon EKS control plane #2190, and the rejection should be done in other places of K8s.
At least or more meaningful error message should be exposed, in case the service account is needed inside the VPC resource controller.