aws-custom-route-controller events are wrongly categorized as `ERR_RETRYABLE_INFRA_DEPENDENCIES` instead of `ERR_INFRA_UNAUTHENTICATED`

[ialidzhikov]

How to categorize this issue?

/area ops-productivity
/kind bug
/platform aws

What happened:
Shoot credentials got invalid. Then the ControlPlane got unhealthy with:

status:
  conditions:
  - codes:
    - ERR_RETRYABLE_INFRA_DEPENDENCIES
    lastTransitionTime: "2024-11-20T10:37:28Z"
    lastUpdateTime: "2024-11-20T10:49:01Z"
    message: "[aws-custom-route-controller] RoutesUpdateFailed: (combined from similar
      events): AuthFailure: AWS was not able to validate the provided access credentials\n\tstatus
      code: 401, request id: <id>."
    reason: HealthCheckUnsuccessful
    status: "False"
    type: ControlPlaneHealthy

IMO, the ERR_RETRYABLE_INFRA_DEPENDENCIES is wrong. It should be ERR_INFRA_UNAUTHENTICATED.

In

gardener-extension-provider-aws/pkg/apis/aws/helper/error_codes.go

Line 14 in 95bfe29

unauthenticatedRegexp = regexp.MustCompile(`(?i)(AuthFailure|InvalidAccessKeyId|InvalidSecretAccessKey)`)

, the error string AuthFailure is already marked as ERR_INFRA_UNAUTHENTICATED.

The custom handling for the events:

gardener-extension-provider-aws/pkg/controller/healthcheck/customroutecontrollerhealth.go

Lines 62 to 67 in 95bfe29

	var codes []gardencorev1beta1.ErrorCode
	if strings.Contains(newestEvent.Message, "RouteLimitExceeded") {
	codes = append(codes, gardencorev1beta1.ErrorInfraQuotaExceeded)
	} else {
	codes = append(codes, gardencorev1beta1.ErrorRetryableInfraDependencies)
	}

What you expected to happen:
AuthFailure error to be flagged with ERR_INFRA_UNAUTHENTICATED, not with ERR_RETRYABLE_INFRA_DEPENDENCIES.

How to reproduce it (as minimally and precisely as possible):
See above.

Anything else we need to know?:
N/A

Environment:

• Gardener version (if relevant):
• Extension version: v1.58.3
• Kubernetes version (use kubectl version):
• Cloud provider or hardware configuration:
• Others:

[gardener-ci-robot]

The Gardener project currently lacks enough active contributors to adequately respond to all issues.
This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close

/lifecycle rotten

@gardener-ci-robot Command /add is not available to you but only to a Maintainer, Member, Author.

[gardener-ci-robot]

The Gardener project currently lacks enough active contributors to adequately respond to all issues.
This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 60d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 60d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as active with /lifecycle active
• Mark this issue as frozen with /lifecycle frozen
• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close

/lifecycle rotten

[gardener-ci-robot]

The Gardener project currently lacks enough active contributors to adequately respond to all issues.
This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 60d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 60d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as active with /lifecycle active
• Mark this issue as frozen with /lifecycle frozen
• Mark this issue as fresh with /remove-lifecycle rotten

/close

[gardener-prow]

@gardener-ci-robot: Closing this issue.

Details

In response to this:

The Gardener project currently lacks enough active contributors to adequately respond to all issues.
This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 60d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 60d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as active with /lifecycle active
• Mark this issue as frozen with /lifecycle frozen
• Mark this issue as fresh with /remove-lifecycle rotten

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[gardener-ci-robot]

The Gardener project currently lacks enough active contributors to adequately respond to all issues.
This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 60d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 60d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as active with /lifecycle active
• Mark this issue as frozen with /lifecycle frozen
• Mark this issue as fresh with /remove-lifecycle stale
• Mark this issue as rotten with /lifecycle rotten
• Close this issue with /close

/lifecycle stale