OCPCLOUD-3092: Merge https://github.com/kubernetes/cloud-provider-aws:master (bea9adf) into main

.github/workflows/update-deps.yaml

@@ -18,7 +18,7 @@ jobs:
       pull-requests: write
     steps:
       - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
-      - uses: actions/setup-go@d35c59abb061a4a6fb18e82ac0862c26744d6ab5
+      - uses: actions/setup-go@44694675825211faa026b3c33043df3e48a5fa00
         with:
           go-version-file: go.mod
       - name: Update Dependencies

.ko.yaml

@@ -1 +1 @@
-defaultBaseImage: registry.k8s.io/build-image/go-runner:v2.4.0-go1.24.4-bookworm.0
+defaultBaseImage: registry.k8s.io/build-image/go-runner:v2.4.0-go1.24.7-bookworm.0

Dockerfile

@@ -14,15 +14,15 @@
 ##                               BUILD ARGS                                   ##
 ################################################################################
 # This build arg allows the specification of a custom Golang image.
-ARG GOLANG_IMAGE=golang:1.24.4
+ARG GOLANG_IMAGE=golang:1.24.7
 
 # The distroless image on which the CPI manager image is built.
 #
 # Please do not use "latest". Explicit tags should be used to provide
 # deterministic builds. Follow what kubernetes uses to build
 # kube-controller-manager, for example for 1.23.x:
 # https://github.com/kubernetes/kubernetes/blob/release-1.24/build/common.sh#L94
-ARG DISTROLESS_IMAGE=registry.k8s.io/build-image/go-runner:v2.4.0-go1.24.4-bookworm.0
+ARG DISTROLESS_IMAGE=registry.k8s.io/build-image/go-runner:v2.4.0-go1.24.7-bookworm.0
 
 ################################################################################
 ##                              BUILD STAGE                                   ##

charts/aws-cloud-controller-manager/Chart.yaml

@@ -2,8 +2,8 @@
 apiVersion: v1
 name: aws-cloud-controller-manager
 description: Installs Cloud Controller Manager for AWS Cloud Provider
-version: 0.0.8
-appVersion: v1.27.1
+version: 0.0.10
+appVersion: v1.34.0
 maintainers:
 - name: Nick Turner
   email: nic@amazon.com

charts/aws-cloud-controller-manager/values.yaml

@@ -6,7 +6,7 @@ args:
 
 image:
     repository: registry.k8s.io/provider-aws/cloud-controller-manager
-    tag: v1.33.0
+    tag: v1.34.0
 
 # Specify image pull secrets
 imagePullSecrets: []

cloudbuild.yaml

@@ -17,7 +17,7 @@ steps:
       - --platform=linux/amd64,linux/arm64
       - .
   # Build cloudbuild artifacts (for attestation)
-  - name: 'docker.io/library/golang:1.24.4-bookworm'
+  - name: 'docker.io/library/golang:1.24.7-bookworm'
     id: cloudbuild-artifacts
     entrypoint: make
     env:

docs/development.md

@@ -143,7 +143,7 @@ cd cloud-provider-aws
 make && make test
 ```
 
-### Run the tests!
+### Run the e2e tests!
 
 You can run the tests with the following:
 
@@ -159,3 +159,47 @@ make test-e2e
 
 > [!NOTE]
 > If tests fail and the cluster isn't deleted, you can manually delete with `kops delete cluster --name ENTER_NAME`. The S3 kops state bucket will include all clusters not cleaned up.
+
+### Run the e2e tests in clusters not provisioned by kops
+
+E2E tests require a running Kubernetes cluster with AWS cloud provider configured.
+
+Prerequisites:
+- AWS credentials configured
+- kubernetes configuration pointing to a cluster with cloud-provider-aws deployed
+
+Steps:
+
+- Build the test utility:
+```bash
+make e2e.test
+```
+- A binary `e2e.test` is expected to be created under the root of the project:
+- Check available e2e tests (optional):
+```bash
+./e2e.test --ginkgo.dry-run
+```
+- Run specific e2e tests (Load Balancer with NLB):
+```bash
+./e2e.test --ginkgo.v  --ginkgo.focus="loadbalancer.*NLB"
+```
+
+## CI Test Infrastructure
+
+The cloud-provider-aws project uses [Prow][prow] as to the CI/CD (Continuous Integration/Continuous Delivery) system to schedule CI jobs, and use [kops][kops] to create the cluster used by jobs.
+
+The Prow test grid dashboard is available at [testgrid.k8s.io/amazon-ec2][test-grid] ([here][test-grid-e2e] is the directly link to the e2e test suite).
+
+The CI jobs are defined in the [kubernetes/test-infra repository][k-test-infra-ccm].
+
+The e2e test suite is defined in [tests/e2e](https://github.com/kubernetes/cloud-provider-aws/tree/master/tests/e2e).
+
+When you need to investigate CI infrastructure issues (such as build timeouts, resource constraints, or job failures), you can use the Grafana instance available at [monitoring-eks.prow.k8s.io][monitoring-eks]. The [Build Dashboard][monitoring-eks-dash-build] is commonly used to monitor resource usage from build jobs.
+
+[prow]: https://github.com/kubernetes-sigs/prow
+[kops]: https://github.com/kubernetes/kops/tree/master
+[test-grid]: https://testgrid.k8s.io/amazon-ec2
+[test-grid-e2e]: https://testgrid.k8s.io/amazon-ec2#ci-cloud-provider-aws-e2e
+[k-test-infra-ccm]: https://github.com/kubernetes/test-infra/blob/master/config/jobs/kubernetes/cloud-provider-aws/cloud-provider-aws-presubmit.yaml
+[monitoring-eks]: https://monitoring-eks.prow.k8s.io/
+[monitoring-eks-dash-build]: https://monitoring-eks.prow.k8s.io/d/96Q8oOOZk/builds

docs/getting_started.md

@@ -24,9 +24,9 @@ with the cloud controller manager.  The steps are as follows:
 1. Add the `--cloud-provider=external` to the kube-controller-manager config.
 1. Add the `--cloud-provider=external` to the kube apiserver config.
 1. Add the `--cloud-provider=external` to each the kubelet's config.
-1. Add the tag kubernetes.io/cluster/your_cluster_id=owned (if resources are
+1. Add the tag `kubernetes.io/cluster/your_cluster_id=owned` (if resources are
    owned and managed by the cluster) or
-   kubernetes.io/cluster/your_cluster_id=shared (if resources are shared
+   `kubernetes.io/cluster/your_cluster_id=shared` (if resources are shared
    between clusters, and should not be destroyed if the cluster is destroyed)
    to your instances.
 1. Apply the kustomize configuration: `kubectl apply -k
@@ -45,7 +45,7 @@ Follow the detailed steps in [the documentation](https://kubernetes.io/docs/task
 |------|-----------|-------------|
 | kube-apiserver | `--cloud-provider=external` | Disables the cloud provider in the API Server. This will disable the cloud provider code in the kube apiserver, which is limited to the persistent volume labelling controller.  |
 | kube-controller-manager | `--cloud-provider=external` | Disables the cloud provider in the Kube Controller Manager. This disables cloud related control loops, including the route controller, the service controller, and the node lifecycle controller. |
-| kube-controller-manager | --leader-elect=true | Enable leader election  |
+| kube-controller-manager | `--leader-elect=true` | Enable leader election  |
 | kube-controller-manager | `--external-cloud-volume-plugin=aws` | Tells the Kube Controller Manager to run the volume loops that have cloud provider code in them.  This is required for volumes to work if you are not using CSI with migration enabled. |
 | kubelet | `--cloud-provider=external` | Disables the cloud provider in the Kubelet. This disables the built-in kubelet image credential provider, so in order for the kubelet to fetch from ECR repositories, it will need the external ECR kubelet image credential provider binary.  This also disables the EBS attacher interface implementation, which is generally safe as long as the EBS CSI driver is installed and CSI migration is enabled.|
 | aws-cloud-controller-manager | <code>--cloud-provider=[aws&#124;aws/v2]</code> | Optional.  Selects the legacy cloud-provider or the v2 cloud-provider in the aws-cloud-controller-manager. WARNING: the v2 cloud-provider is in a pre-alpha state. |
@@ -56,4 +56,4 @@ In order to create a cluster using kops, you can try the kops example cluster. R
 
 `make kops-example`
 
-This will create a sample kops cluster with the example configuration, found in [examples/kops-new-cluster](../examples/kops-new-cluster)  The cloud cloud controller manager specific configuration is separate, purely for readability purposes, and can be found in [overlays/cloud-controller-manager](../examples/kops-new-cluster/overlays/cloud-controller-manager).
+This will create a sample kops cluster with the example configuration, found in [examples/kops-new-cluster](https://github.com/kubernetes/cloud-provider-aws/tree/master/examples/kops-new-cluster)  The cloud cloud controller manager specific configuration is separate, purely for readability purposes, and can be found in [overlays/cloud-controller-manager](https://github.com/kubernetes/cloud-provider-aws/tree/master/examples/kops-new-cluster/overlays/cloud-controller-manager).

docs/nlb_security_groups.md

@@ -0,0 +1,117 @@
+# Service type-LoadBalancer Network Load Balancer with Security Group
+
+## Overview
+
+The controller can be configured to enable managed Security Group (SG) for Services using AWS Network Load Balancer (NLB) by setting an opt-in configuration in your cloud config. When enabled, each NLB created for a Kubernetes Service of type `LoadBalancer` with annotation `service.beta.kubernetes.io/aws-load-balancer-type=nlb` will have a dedicated Security Group, managed by the cloud provider controller. We are calling this as opt-in Managed NLB Security Group ("Managed SG" mode).
+
+> Note: The BYO SG (user-provided security groups) annotations (`service.beta.kubernetes.io/aws-load-balancer-security-groups` and `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`) are valid only for Classic Load Balancers. To learn more about supported annotations by load balancer type, see the [service_controller documentation][doc-ctrl-service].
+
+[doc-ctrl-service]: https://github.com/kubernetes/cloud-provider-aws/blob/master/docs/service_controller.md
+
+## Configuration
+
+### Opt-in Managed Security Group mode
+
+To enable this feature, add the following to your cloud config (usually `/etc/kubernetes/cloud-config` or as configured in your deployment):
+
+```ini
+[Global]
+NLBSecurityGroupMode = Managed
+```
+
+- **Default behavior:** If `NLBSecurityGroupMode` is not set or set to any value other than `Managed`, NLBs are provisioned without a dedicated, controller-managed Security Group (legacy behavior).
+- **Opt-in behavior:** When set to `Managed`, the controller will create, attach, update, and delete a dedicated SG for each NLB Service.
+
+## Feature Details and Use Cases
+
+- **Why use this feature?**
+  - Improved security: fine-grained, automated control over NLB ingress.
+  - Automated lifecycle management of SGs, reducing manual intervention and risk of resource leaks.
+- **When to use:**
+  - When you want the controller to manage NLB security groups automatically for NLB.
+  - When your security/compliance policies require explicit SGs for each NLB.
+
+## Upgrade and Migration Notes
+
+- **Enabling the feature:**
+  - Existing Service type-loadBalancer NLB will not be retroactively assigned a managed SG. Only new Services (created after enabling the feature) will have managed SGs.
+  - To migrate existing NLBs, you must recreate the Service or manually update the SGs.
+- **Disabling the feature:**
+  - If you disable the feature after using it, previously managed SGs will not be deleted automatically unless the Service and associated NLB is deleted.
+- **Controller restart:**
+  - Changing the config requires a controller restart for the new setting to take effect.
+
+## Security Group Lifecycle
+
+### Managed Security Group
+
+- **Creation:**
+  - SGs are created with owned cluster tag indicating they are managed by the controller.
+- **Tagging:**
+  - Managed SGs are tagged for identification and safe cleanup. Example cluster tag:
+    - `kubernetes.io/cluster/<cluster-name>: owned`
+- **Deletion:**
+  - Managed SGs are deleted when the corresponding Service is deleted. The controller uses exponential backoff to handle AWS dependency violations.
+
+## Testing and Validation
+
+### Test 1 - **How to test the Managed Security Group:**
+
+  1. Ensure your cloud-config has the configuration `NLBSecurityGroupMode = Managed`
+  2. Create a Service of type `LoadBalancer` after enabling the feature.
+```sh
+APP_NAME=app
+APP_NAMESPACE=$APP_NAME
+SVC_NAME="${APP_NAME}-nlb-sg"
+cat << EOF | kubectl create -f -
+apiVersion: v1
+kind: Service
+metadata:
+  name: "${SVC_NAME}"
+  namespace: "${APP_NAMESPACE}"
+  annotations:
+    service.beta.kubernetes.io/aws-load-balancer-type: nlb
+spec:
+  selector:
+    app: "${APP_NAME}"
+  ports:
+    - port: 80
+      targetPort: 8080
+      protocol: TCP
+  type: LoadBalancer
+EOF
+```
+  3. Verify that a managed SG is created and attached to the NLB in the AWS console.
+  4. Check that the SG is tagged appropriately and that ingress rules match your Service spec.
+  5. Ensure you can reach the Service NLB endpoint:
+```sh
+LB_DNS=$(kubectl get svc $SVC_NAME -n ${APP_NAMESPACE} -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
+
+aws elbv2 describe-tags --resource-arns $(aws elbv2 describe-load-balancers | jq -r ".LoadBalancers[] | select(.DNSName==\"$LB_DNS\").LoadBalancerArn") | jq .TagDescriptions[].Tags
+
+[
+  {
+    "Key": "kubernetes.io/service-name",
+    "Value": "app/app-svc-ccm"
+  },
+  {
+    "Key": "kubernetes.io/cluster/mrb-sg-zvcgr",
+    "Value": "owned"
+  }
+]
+
+# reach the LB endpoint
+curl -v $LB_DNS
+```
+  4. Delete the Service and verify that the SG is deleted.
+
+## Troubleshooting
+
+- **SG not deleted:**
+  - Check for AWS dependency violations (e.g., NLB still deleting). The controller will retry deletion with backoff.
+- **NLB not created:**
+  - Ensure the controller has IAM permissions to manage Security Groups.
+- **SG rules not as expected:**
+  - Check your Service annotations and cloud config.
+- **Config changes not taking effect:**
+  - Ensure you have restarted the controller after changing the config.