test: add e2e test for provided credentials

[cvvz]

What type of PR is this?
/kind test

What this PR does / why we need it:

Which issue(s) this PR fixes:

Fixes #

Requirements:

• uses conventional commit messages
• includes documentation
• adds unit tests
• tested upgrade from previous version

Special notes for your reviewer:
Add e2e test for provided credentials stored in k8s secret, including:

• storage account key
• storage account SAS token
• service principal
• managed identity

Release note:

Add e2e test for provided credentials stored in k8s secret, including: storage account key, storage account SAS token, service principal and managed identity.

[k8s-ci-robot]

Hi @cvvz. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[andyzhangx]

/ok-to-test

[andyzhangx]

/retest

[andyzhangx]

run() only provisions different secret, I think we need to add a new e2e test case for sas token stored in k8s secret scanerio

[cvvz]

run() will generate different secret, pvc, pv and pod and also create and clean them up in k8s each time. Also per the name of this test case: pre_provisioned_provided_credentials_tester,I think this test case is used to test the scenario of provided credentials, which includes access key, sas token, service principal and managed identity. I think it would be more reasonable and convenient to put them all in this test case.

[cvvz]

/retest

[cvvz]

/retest

[andyzhangx]

pls squash all commits, and also add more details in PR description what e2e tests this PR has added, thanks.

[andyzhangx]

let's keep the sp test

[cvvz]

This modification is to solve the problem that blobfuse mount failed when authenticate by MSI. The root cause is MSI generated by aks-engine is not assigned to VMSS.
BTW, considering sp is already tested by the most of jobs using the arm template linux.json, which set useManagedIdentity: false and

    "servicePrincipalProfile": {
        "clientID": "{clientID}", 
        "secret": "{secret}"
    }

And only job pull-blob-csi-driver-e2e-vmss uses template linux-vmss.json which set useManagedIdentity: true. Maybe we should have set

    "servicePrincipalProfile": {
        "clientID": "msi", 
    }

to test msi scenario?

[andyzhangx]

per the logs, pull-blob-csi-driver-e2e is using sp

https://storage.googleapis.com/kubernetes-jenkins/pr-logs/pull/kubernetes-sigs_blob-csi-driver/730/pull-blob-csi-driver-e2e/1557924587340042240/build-log.txt

[pod/csi-blob-controller-84cf49dc6d-zs47k/blob] I0812 03:13:38.637448       1 azure.go:104] read cloud config from file: /etc/kubernetes/azure.json successfully
[pod/csi-blob-controller-84cf49dc6d-zs47k/blob] I0812 03:13:38.638028       1 azure_auth.go:245] Using AzurePublicCloud environment
[pod/csi-blob-controller-84cf49dc6d-zs47k/blob] I0812 03:13:38.638061       1 azure_auth.go:130] azure: using client_id+client_secret to retrieve access token

pull-blob-csi-driver-e2e-vmss is using msi:
https://storage.googleapis.com/kubernetes-jenkins/pr-logs/pull/kubernetes-sigs_blob-csi-driver/730/pull-blob-csi-driver-e2e-vmss/1557924587390373888/build-log.txt

[pod/csi-blob-node-8trh8/blob] I0812 03:15:51.934107       1 azure_auth.go:245] Using AzurePublicCloud environment
[pod/csi-blob-node-8trh8/blob] I0812 03:15:51.934127       1 azure_auth.go:96] azure: using managed identity extension to retrieve access token
[pod/csi-blob-node-8trh8/blob] I0812 03:15:51.934131       1 azure_auth.go:102] azure: using User Assigned MSI ID to retrieve access token
[pod/csi-blob-node-8trh8/blob] I0812 03:15:51.934162       1 azure_auth.go:113] azure: User Assigned MSI ID is client ID. Resource ID parsing error: %+vparsing failed for 82e9bd91-c283-4b2d-8708-6d11b07d630d. Invalid resource Id format

[andyzhangx]

looks like you are right.

[cvvz]

/retest

[andyzhangx]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andyzhangx, cvvz

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [andyzhangx]

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