OCPBUGS-14998: Only use RoleARN for Route53 API#951
OCPBUGS-14998: Only use RoleARN for Route53 API#951openshift-merge-robot merged 1 commit intoopenshift:masterfrom
Conversation
|
@gcs278: This pull request references Jira Issue OCPBUGS-14998, which is invalid:
Comment The bug has been updated to refer to the pull request using the external bug tracker. DetailsIn response to this:
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/test-infra repository. |
|
@gcs278: This pull request references Jira Issue OCPBUGS-14998, which is invalid:
Comment DetailsIn response to this:
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/test-infra repository. |
pkg/dns/aws/dns.go
Outdated
| } | ||
|
|
||
| // When RoleARN is provided, make a copy of the Route53 session and configure it to use RoleARN. | ||
| // RoleARN is intended to only provide access to another account's Route53 service, not for ELBs. |
There was a problem hiding this comment.
| // RoleARN is intended to only provide access to another account's Route53 service, not for ELBs. | |
| // RoleARN is intended to only provide access to another account's Route 53 service, not for ELBs. |
Can you add a similar comment to the RoleARN field in the Config struct definition?
pkg/dns/aws/dns.go
Outdated
| // RoleARN is intended to only provide access to another account's Route53 service, not for ELBs. | ||
| sessRoute53 := sess | ||
| if config.RoleARN != "" { | ||
| sessRoute53 := sess.Copy(sess.Config) |
There was a problem hiding this comment.
You shouldn't need to specify sess.Config.
| sessRoute53 := sess.Copy(sess.Config) | |
| sessRoute53 := sess.Copy() |
I'm not certain, but you might be able to hang this config on r53Config below instead:
r53Config := aws.NewConfig()
// When RoleARN is provided, make a copy of the Route53 session and configure it to use RoleARN.
// RoleARN is intended to only provide access to another account's Route53 service, not for ELBs.
if config.RoleARN != "" {
r53Config.WithCredentials(stscreds.NewCredentials(sess, config.RoleARN))
}There was a problem hiding this comment.
Done & will keep pattern in my back pocket.
There was a problem hiding this comment.
@Miciah Turns out, it appears that i need sess.Config, otherwise, it shared vpc Route53 creation breaks completely.
Added sessRoute53 := sess.Copy(sess.Config) back, and in my smoke testing, it worked.
There was a problem hiding this comment.
Actually, I tested again, and it didn't work. I think I might of ran an invalid test, possibly the service hanging around while I created a new ingresscontroller caused me to get a false positive by somehow re-using the existing service...not sure, will update when I find what works.
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Miciah The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/hold |
|
/jira refresh |
|
@gcs278: This pull request references Jira Issue OCPBUGS-14998, which is valid. The bug has been moved to the POST state. 3 validation(s) were run on this bug
Requesting review from QA contact: DetailsIn response to this:
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/test-infra repository. |
|
e2e-aws-ovn failed because I've filed OCPBUGS-15227 for this issue. |
|
e2e-aws-ovn-serial failed because This looks like a timeout that might have been caused by general cluster instability (many other tests were reported as flaky in the same CI job run). Maybe it was a fluke. |
|
CI Looks pretty bad today, but no errors attributed to this PR. Must-gather failure |
|
/hold |
|
I've never seen this one before, but since this update is specific to DNS, I don't think it's related.
`pods should successfully create sandboxes by adding pod to networ: seems unrelated |
| // RoleARN is intended to only provide access to another account's Route 53 service, not for ELBs. | ||
| sessRoute53 := sess | ||
| if config.RoleARN != "" { | ||
| sessRoute53 = sess.Copy() |
There was a problem hiding this comment.
@Miciah - I made a silly mistake that broke everything. I had sessRoute53 := sess.Copy() instead of sessRoute53 = sess.Copy().
The variable was shadowed in the scope of the if statement, and didn't modify the sessRoute53 in the scope we needed. Everything works as expected now.
|
/hold cancel |
|
must gather failure pathological event should not see excessive Back-off restarting failed containers Distruption testing failure TestUpgradeControlPlane/EnsureNoCrashingPods |
|
unable to create pod |
| "github.com/aws/aws-sdk-go/aws/arn" | ||
| "github.com/aws/aws-sdk-go/aws/awserr" | ||
| "github.com/aws/aws-sdk-go/aws/client/metadata" | ||
| "github.com/aws/aws-sdk-go/aws/credentials/stscreds" |
There was a problem hiding this comment.
The "github.com/aws/aws-sdk-go/aws/credentials/stscreds" import was moved erroneously
To support Shared VPC, we split the DNS client into public and private providers, the private using the RoleARN (Account A) and the public using the default (Account B). However, the RoleARN only provides API access for Account A's Route53 service, not the ability to describe Account B's ELBs. This fix isolates the RoleARN to only be used with Route53 API services. `pkg/dns/aws/dns.go`: Create a separate Route53 session object that uses the RoleARN when provided.
|
Must gather failure
|
|
There was no issues with regression on the public and private cluster created with the premerged image, hence marking as verified |
|
/lgtm |
|
|
|
|
|
Lots of e2e test failures in e2e-azure-operator, that's a bit of a first, but it seems something went wrong with the installation
|
|
|
|
Same issue, 3rd time... |
|
@gcs278: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions 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/test-infra repository. I understand the commands that are listed here. |
|
@gcs278: Jira Issue OCPBUGS-14998: All pull requests linked via external trackers have merged: Jira Issue OCPBUGS-14998 has been moved to the MODIFIED state. DetailsIn response to this:
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/test-infra repository. |
To support Shared VPC, we split the DNS client into public and private providers, the private using the RoleARN (Account A) and the public using the default (Account B). However, the RoleARN only provides API access for Account A's Route53 service, not the ability to describe Account B's ELBs. The ingress-operator DNS Logic uses the AWS API to describe the ELBs in order to determine the Zone ID. This fix isolates the RoleARN to only be used with Route53 API services.
pkg/dns/aws/dns.go: Create a separate Route53 session object that uses the RoleARN when provided.