-
Notifications
You must be signed in to change notification settings - Fork 74
CCO-324,CCO-325: add support for workload identity #245
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CCO-324,CCO-325: add support for workload identity #245
Conversation
78fa349 to
c07769b
Compare
|
@abutcher can you please take a look as well? I've noticed one thing I can't wrap my head around, the enhancement says: "create workload identity clients when the Based on that the injector code change proposed here prioritizes client secret. That means that if for some reason there is both secret and token in the secret from CCO, we use the secret and ignore workload identity values. However, the current driver patch proposal (not merged yet!), seems to do quite the opposite - it first checks if workload identity can be used. So I'm wondering, do we still want to prioritize client secret like this? Can we even expect to get a secret from CCO where we have both? And if we do should we rather just "pass through" all the values and let driver/cloud provider pick the auth method? |
CCO should never provide a secret which has both client secret and workload identity fields set. If priority is a concern I think it would be okay to prioritize workload identity if both fields are present; or perhaps if the federatedTokenFile is set then it should be assumed that workload identity is requested. |
296fff0 to
29921ff
Compare
@abutcher Thanks for the details, assuming workload identity method sounds reasonable to me. I understand both methods should never be set by CCO, but we can have a check here, just in case. I've updated the PR again - it's ready for review now. |
|
@RomanBednar: This pull request references CCO-325 which is a valid jira issue. 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. |
|
/retest |
elmiko
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think this is mostly making sense to me, although i do not know the azure credentials system at a deep level. i do have a question about one of the log messages.
| // Workload identity is available, but client secret is provided too. | ||
| // If we don't fail here we would use client secret unnecessarily, also we can assume that user intended to use workload identity because all required values are provided. | ||
| return fmt.Errorf("%s env variable is set along with env variables %s and %s which indicate workload identity auth should be used, this should never happen\n"+ | ||
| "Please consider reporting a bug to CCO team: https://github.com/openshift/cloud-credential-operator/issues", clientSecretEnvKey, tenantIDEnvKey, federatedTokenEnvKey) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we direct them to issues.redhat.com or does the CCO team process bug reports from the github issues?
i just want to make sure we don't miss any bug reports.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, all bug reports should probably land in issues.redhat.com, thank you.
i think this is mostly making sense to me, although i do not know the azure credentials system at a deep level. i do have a question about one of the log messages.
Here we're mostly just passing through the values we get from CCO, most of the interesting stuff is done there so that's why I wanted @abutcher to review this PR as well.
520ac86 to
b55409e
Compare
|
/retest |
2 similar comments
|
/retest |
|
/retest |
elmiko
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a couple more questions
| } | ||
| if err != nil && !secretFound { | ||
| // Workload identity failed, and we don't have a secret - can't continue. | ||
| return fmt.Errorf("user+secret method failed: %s is missing; workload identity method failed: %v", clientSecretEnvKey, err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would it be possible to have err != nil && secretFound ?
just wondering if we need to cover all cases
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the conditions here we rule out the failure cases which are:
- we have both secret and workload identity
- we have neither
So what remains is that we either have secret or we have workload identity. Later we resolve this in prepareCloudConfig() where we take one or the other, prioritizing workload identity. So all cases are covered.
So sure we can have the conditions explicitly here, but then I believe we'd have to refactor prepareCloudConfig() so it does not do any decisions (which it already does with useManagedIdentityExtensionConfigKey). That would make the code more readable perhaps by having the logic at one place - I was tempted to go that route, but we have to consider the time invested to refactoring and value added.
| } else { | ||
| // Workload identity failed, but we have a secret. | ||
| klog.V(4).Info("%s env variable is set, client secret authentication will be used", clientSecretEnvKey) | ||
| cloudConfig[clientSecretCloudConfigKey] = clientSecret |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need to check len(clientSecret) > 0 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, I'm not sure if we want to pass through "" - I don't think CCO should let that through. But it does make sense to check for this. But if we do that with secret we should do that with all other values to be consistent. See my latest commit.
b55409e to
6581b44
Compare
|
/retest |
|
/hold |
6581b44 to
9c3f5b9
Compare
|
/retest |
2 similar comments
|
/retest |
|
/retest |
7a71922 to
892fe8a
Compare
|
@elmiko This PR needs one more, hopefully last review. I had to change this to drive the feature using a gate instead of assumptions from variables, the rest should be the same. |
|
/hold cancel |
elmiko
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
/lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: elmiko 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 |
|
@RomanBednar: This pull request references CCO-324 which is a valid jira issue. This pull request references CCO-325 which is a valid jira issue. 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. |
|
@RomanBednar: 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. |
In scope of Azure workload identity feature we need to extend injector to parse new configuration values.