-
Notifications
You must be signed in to change notification settings - Fork 934
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
Introduce CF-on-K8s support #2233
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This makes `cf api` able to detect the `cf-on-k8s` flag in the root endpoint response and persist this information in the config. This will allow us to enable CF-on-K8s-specific behaviour for every following command. We have introduced a new `selfcontained` integration suite which contains tests that do not need to be run against a cf deployment. Issue: cloudfoundry/cf-k8s-api#10 Co-authored-by: Danail Branekov <danailster@gmail.com> Co-authored-by: Giuseppe Capizzi <gcapizzi@pivotal.io> Co-authored-by: Georgi Sabev <georgethebeatle@gmail.com>
- client-go v0.22 does not work with protobuf v1.3.4. - protobuf v1.5 leads to a runtime panic in go-loggregator and go-log-cache. See: cloudfoundry/go-log-cache#30 - pin go-log-cache to a fork containing this PR that fixes the above problem: cloudfoundry/go-log-cache#31 Having done all this allows us to use the latest verson of the client-go package, which is needed for the cf-on-k8s support. Co-authored-by: Danail Branekov <danailster@gmail.com>
This implements a CF-on-K8s-compatible version of the `cf login` command. When a user runs `cf login` against a CF-on-K8s, they will be prompted to choose an `auth-info` from the ones specified in their `$KUBECONFIG`. Passing any extra option, except for `-a`, will result in a failure. The main changes here are the extraction of the `AuthActor` and `UserConfig` interfaces, which we implement both for the default use case and the Kubernetes one. This allow us to provide specific implementations of methods like `Authenticate`, `GetLoginPrompts` and `CurrentUser*`. While the choice of the `AuthActor` implementation can happen in the `NewActor` constructor, this can't be done for `UserConfig`. `cf login` hits the root endpoint and mutates the `Config` accordingly, and the selection of the `UserConfig` implementation depends on those mutations. We have then decided to perform this choice dynamically via the `DynamicUserConfig` decorator. Co-authored-by: Danail Branekov <danailster@gmail.com> Co-authored-by: Georgi Sabev <georgethebeatle@gmail.com> Co-authored-by: Kieron Browne <kbrowne@vmware.com> Co-authored-by: Giuseppe Capizzi <gcapizzi@pivotal.io> Co-authored-by: Mario Nitchev <marionitchev@gmail.com> Co-authored-by: Giuseppe Capizzi <gcapizzi@pivotal.io>
This removes the rewrite to eirini-forks/go-log-cache and bumps cloudfoundry/go-log-cache to the latest `master` commit which includes the protobuf fix. Co-authored-by: Danail Branekov <danailster@gmail.com> Co-authored-by: Giuseppe Capizzi <gcapizzi@pivotal.io>
This introduces a new implementation a new `ConnectionWrapper` implementation to be used when targeting a CF-on-K8s API. The wrapper leverages the Kubernetes configuration directly. Only `auth-provider` credentials are supported at the moment. Issue: https://github.com/cloudfoundry/cf-k8s-api/issues/16 Co-authored-by: Georgi Sabev <georgethebeatle@gmail.com> Co-authored-by: Danail Branekov <danailster@gmail.com> Co-authored-by: Kieron Browne <kbrowne@vmware.com> Co-authored-by: Giuseppe Capizzi <gcapizzi@pivotal.io>
API and Login commands do not require auth, so skip the auth wrapping explicitly by calling a wrapper that doesn't add it. Other commands do require auth, so call the auth wrapping command. Remove the nil checks in the auth wrappers, as they will now only be involved when auth is actually required. Issue: https://github.com/cloudfoundry/cf-k8s-api/issues/16 Co-authored-by: Kieron Browne <kbrowne@vmware.com> Co-authored-by: Giuseppe Capizzi <gcapizzi@pivotal.io>
This only supports inline client certificates and keys for now. Co-authored-by: Giuseppe Capizzi <gcapizzi@pivotal.io> Co-authored-by: Kieron Browne <kbrowne@vmware.com> Co-authored-by: Danail Branekov <danailster@gmail.com> Co-authored-by: Giuseppe Capizzi <gcapizzi@pivotal.io> Co-authored-by: Danail Branekov <danailster@gmail.com>
This change leverages the `client-go` `rest.TLSConfigFor` method to build a `tls.Config` regardless of the authentication method. This allows us to support any authentication method that uses client certificates (inline certs, filepath certs, exec plugins) with the same code. Co-authored-by: Mario Nitchev <marionitchev@gmail.com> Co-authored-by: Giuseppe Capizzi <gcapizzi@pivotal.io> Co-authored-by: Danail Branekov <danailster@gmail.com> Co-authored-by: Giuseppe Capizzi <gcapizzi@pivotal.io>
This only adds tests as the behaviour comes for free from the previous commit. Co-authored-by: Giuseppe Capizzi <gcapizzi@pivotal.io>
Support the case where a token is provided directly in the auth-info with `token` or using `token-file`. The logic here is that there won't any certificates in the TLSConfig, and the WrapTransport method of transportConfig will be nil, as it is only set in the exec and auth-provider plugins. Therefore we'll just wrap the http request with whatever auth info is left, which is 'hard-coded' tokens in this case. Issue: cloudfoundry/cf-k8s-api#11 Issue: cloudfoundry/cf-k8s-api#12 Co-authored-by: Danail Branekov <danailster@gmail.com> Co-authored-by: Giuseppe Capizzi <gcapizzi@pivotal.io> Co-authored-by: Danail Branekov <danailster@gmail.com>
Issue: cloudfoundry/korifi#183 Co-authored-by: Giuseppe Capizzi <gcapizzi@pivotal.io>
Issue: cloudfoundry/korifi#182 Co-authored-by: Danail Branekov <danailster@gmail.com> Co-authored-by: Giuseppe Capizzi <gcapizzi@pivotal.io>
Issue: cloudfoundry/korifi#157 Co-authored-by: Giuseppe Capizzi <gcapizzi@pivotal.io> Co-authored-by: Danail Branekov <danailster@gmail.com> Co-authored-by: Giuseppe Capizzi <gcapizzi@pivotal.io>
Previously, CurrentUser[Name]() implementation was split in the config area for standard CF and CF-on-k8s. It would have been great to update the k8s version to call /whoami, but the cloud controller logic doesn't seem to belong in the config area. So instead, GetCurrentUser() has been added to the actor interface, and also to the AuthActor interface. This has a standard CF and a k8s CF implementation. The standard implementation just defers to the config method, whereas the k8s implementation invokes the new /whoami endpoint on the cloud controller. This commit also introduces handling that endpoint. Issue: cloudfoundry/korifi#147 Co-authored-by: Giuseppe Capizzi <gcapizzi@pivotal.io> Co-authored-by: Danail Branekov <danailster@gmail.com> Co-authored-by: Giuseppe Capizzi <gcapizzi@pivotal.io>
Co-authored-by: Kieron Browne <kbrowne@vmware.com> Co-authored-by: Danail Branekov <danailster@gmail.com> Co-authored-by: Giuseppe Capizzi <gcapizzi@pivotal.io> Co-authored-by: Danail Branekov <danailster@gmail.com>
jdgonzaleza
approved these changes
Nov 23, 2021
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.
LGTM...
Every commit was previously reviewed in the eirini-forks repo 😄
jdgonzaleza
pushed a commit
that referenced
this pull request
Nov 24, 2021
* Detect CF-on-K8s in `cf api` * Unpin protobuf * Implement `cf login` for CF-on-K8s * Use the latest cloudfoundry/go-log-cache * Introduce a `ConnectionWrapper` for Kubernetes * Refactor the creation of the wrapped CC client * Support Kubernetes inline client certificates * Support Kubernetes client certificates of any kind * Test Kubernetes exec plugins * Support inline and filepath Kubernetes tokens * Clear the Kubernetes auth information in `cf api` * Clear the Kubernetes auth information in `cf api --unset` * Clear the Kubernetes auth information in `cf logout` * Use the real Kubernetes username when creating a space role * Use the real Kubernetes username everywhere Co-authored-by: Giuseppe Capizzi <gcapizzi@pivotal.io> Co-authored-by: Danail Branekov <danailster@gmail.com> Co-authored-by: Georgi Sabev <georgethebeatle@gmail.com> Co-authored-by: Kieron Browne <kbrowne@vmware.com> Co-authored-by: Mario Nitchev <marionitchev@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This introduces the first batch of changes necessary to support CF-on-K8s. The details of how we changed the architecture to accomodate these changes are in the proposal document.
We think this is pretty much all changes needed for CF-on-K8s support and we'd love to see it backported to the next
v8.x
release, maybe marking it as experimental. Before we can call this stable we probably want to:cf oauth-token
);We will make further PRs to address the points above.
/cc @cloudfoundry/cf-k8s