vSphere passthrough mode for CredentialsRequests #150
Conversation
openshift-ci-robot
added
do-not-merge/work-in-progress
openshift-ci-robot
added
the
approved
Implement a simple passthrough-mode-only actuator for vSphere. Assumes the credentials used during installation are good enough to be passed along to any in-cluster components needing vSphere credentials. Add the VSphereProviderSpec definitions which allows listing permissions being requested (even though they are presently ignored as passthrough-mode is assumed).
| metav1.TypeMeta `json:",inline"` | ||
|
|
||
| // Permissions contains a list of groups of privileges that are being requested. | ||
| Permissions []VSpherePermission `json:"permissions"` |
There was a problem hiding this comment.
It looks like you've given thought to this and the entities can be tied to specific privileged in the future.
There was a problem hiding this comment.
that's the idea. that we can hopefully extend this in a non-breaking way if/when we get to mint-mode
joelddiaz
changed the title
openshift-ci-robot
removed
the
do-not-merge/work-in-progress
|
@dgoodwin i was looking at adding vsphere e2e tests, but it doesn't look like vsphere IPI e2e is ready yet, so this should be good to go |
|
|
||
| // VSphereCloudCredSecretName is the name of the secret where credentials | ||
| // for vSphere are stored. | ||
| VSphereCloudCredSecretName = "vsphere-creds" |
There was a problem hiding this comment.
Is it safe to assume this hard-coded value instead of getting the secret name from the cloud provider config? What if there are multiple vCenters with different cred secrets?
There was a problem hiding this comment.
this is an excellent question. @jcpowermac do you know if it is safe to assume that the vsphere secret will always be the secret kube-system/vsphere-creds ?
There was a problem hiding this comment.
I haven't tested it but I wonder if you could continue to append the data section:
vcenterA.username: A
vcenterA.password: A
vcenterB.username: B
vcenterB.password: B
https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/k8s-secret.html
There was a problem hiding this comment.
@dav1x has done a lot with it maybe he has additional insight.
There was a problem hiding this comment.
the secret does have a format that would seem to allow this
data:
vcsa-ci.vmware.devcluster.openshift.com.password: some_base64_password
vcsa-ci.vmware.devcluster.openshift.com.username: some_base64_username
There was a problem hiding this comment.
It was only recently that VCP started to support multiple credentials or secrets via separate vCenter servers.
kubernetes/cloud-provider-vsphere#241
The examples in the PR above do a good job illustrating how this should look.
|
/hold |
openshift-ci-robot
added
the
do-not-merge/hold
|
/unhold |
openshift-ci-robot
removed
the
do-not-merge/hold
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dgoodwin, joelddiaz 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:
Approvers can indicate their approval by writing |
|
/test e2e-aws |
Implement a simple passthrough-mode-only actuator for vSphere. Assumes the credentials used during installation are good enough to be passed along to any in-cluster components needing vSphere credentials.
Add the VSphereProviderSpec definitions which allows listing permissions being requested (even though they are presently ignored as passthrough-mode is assumed).