Skip to content

Conversation

@RomanBednar
Copy link
Contributor

@RomanBednar RomanBednar commented Apr 19, 2023

In scope of Azure workload identity feature we need to extend injector to parse new configuration values.

@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Apr 19, 2023
@openshift-ci openshift-ci bot requested review from damdo and elmiko April 19, 2023 07:07
@RomanBednar
Copy link
Contributor Author

RomanBednar commented Apr 20, 2023

@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 azure_client_secret is absent and when azure_federated_token_file fields are found"

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?

@abutcher
Copy link
Member

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.

@RomanBednar RomanBednar force-pushed the workload-identity branch 2 times, most recently from 296fff0 to 29921ff Compare April 21, 2023 13:31
@RomanBednar
Copy link
Contributor Author

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.

@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 RomanBednar changed the title WIP: add support for workload identity add support for workload identity Apr 21, 2023
@openshift-ci openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Apr 21, 2023
@RomanBednar RomanBednar changed the title add support for workload identity CCO-324 CCO-325: add support for workload identity Apr 21, 2023
@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Apr 21, 2023
@openshift-ci-robot
Copy link

openshift-ci-robot commented Apr 21, 2023

@RomanBednar: This pull request references CCO-325 which is a valid jira issue.

Details

In response to this:

In scope of Azure workload identity feature we need to extend injector to parse new configuration values.

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
Copy link
Contributor Author

/retest

Copy link
Contributor

@elmiko elmiko left a 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)
Copy link
Contributor

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.

Copy link
Contributor Author

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.

@RomanBednar RomanBednar force-pushed the workload-identity branch 3 times, most recently from 520ac86 to b55409e Compare April 26, 2023 15:02
@RomanBednar
Copy link
Contributor Author

/retest

2 similar comments
@RomanBednar
Copy link
Contributor Author

/retest

@RomanBednar
Copy link
Contributor Author

/retest

Copy link
Contributor

@elmiko elmiko left a 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)
Copy link
Contributor

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

Copy link
Contributor Author

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:

  1. we have both secret and workload identity
  2. 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
Copy link
Contributor

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 ?

Copy link
Contributor Author

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.

@RomanBednar RomanBednar force-pushed the workload-identity branch from b55409e to 6581b44 Compare May 5, 2023 13:15
@RomanBednar
Copy link
Contributor Author

/retest

@RomanBednar
Copy link
Contributor Author

/hold

@openshift-ci openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label May 9, 2023
@RomanBednar
Copy link
Contributor Author

/retest

2 similar comments
@RomanBednar
Copy link
Contributor Author

/retest

@RomanBednar
Copy link
Contributor Author

/retest

@RomanBednar
Copy link
Contributor Author

@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.

@RomanBednar
Copy link
Contributor Author

/hold cancel

@openshift-ci openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jun 6, 2023
Copy link
Contributor

@elmiko elmiko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/approve
/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Jun 8, 2023
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jun 8, 2023

[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

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 8, 2023
@RomanBednar RomanBednar changed the title CCO-324 CCO-325: add support for workload identity CCO-324,CCO-325: add support for workload identity Jun 15, 2023
@openshift-ci-robot
Copy link

openshift-ci-robot commented Jun 15, 2023

@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.

Details

In response to this:

In scope of Azure workload identity feature we need to extend injector to parse new configuration values.

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.

@openshift-ci-robot
Copy link

/retest-required

Remaining retests: 0 against base HEAD 87d0d22 and 2 for PR HEAD 892fe8a in total

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jun 19, 2023

@RomanBednar: all tests passed!

Full PR test history. Your PR dashboard.

Details

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. I understand the commands that are listed here.

@openshift-merge-robot openshift-merge-robot merged commit 785ce67 into openshift:master Jun 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. lgtm Indicates that a PR is ready to be merged.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants