cloudfoundry/cli v8.1.0

on GitHub

Package Manager Installation

• apt-get, yum, homebrew

Installers

• Debian 64 bit / 32 bit (deb)
• Redhat 64 bit / 32 bit (rpm)
• Mac OS X 64 bit (pkg)
• Windows 64 bit / 32 bit (zip)

Binaries

• Linux 64 bit / 32 bit (tgz)
• Mac OS X 64 bit (tgz)
• Windows 64 bit / 32 bit (zip)

Docker

docker pull cloudfoundry/cli:8.1.0

Change Log

• Detect CF-on-K8s in cf api

  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

• Unpin protobuf
  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 version of the client-go
  package, which is needed for the cf-on-k8s support.

• Implement cf login for CF-on-K8s

  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.

• Use the latest cloudfoundry/go-log-cache

  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.

• Introduce a ConnectionWrapper for Kubernetes

  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

• Refactor the creation of the wrapped CC client
  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

• Support Kubernetes inline client certificates
  This only supports inline client certificates and keys for now.

• Support Kubernetes client certificates of any kind

  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.

• Test Kubernetes exec plugins

  This only adds tests as the behaviour comes for free from the previous
  commit.

• Support inline and filepath Kubernetes tokens

  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.

• Clear the Kubernetes auth information in cf api
  Issue: cloudfoundry/cf-k8s-controllers#183

• Clear the Kubernetes auth information in cf api --unset
  Issue: cloudfoundry/cf-k8s-controllers#182

• Clear the Kubernetes auth information in cf logout
  Issue: cloudfoundry/cf-k8s-controllers#157

• Use the real Kubernetes username when creating a space role

  Previously, CurrentUserName 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/cf-k8s-controllers#147

• Use the real Kubernetes username everywhere

Special thanks to our many contributors to this release, including but not limited to:
Giuseppe Capizzi, Danail Branekov, Georgi Sabev, Kieron Browne, Mario Nitchevi, Cristhian Camilo Peña, George Gelashvili, Héctor José Calderón, Hema Ranganathan, Juan Diego Gonzalez, Ryker Reed, Shwetha Gururaj, Alexander Berezovsky

Full Changelog: v8.0.0...v8.1.0

Note:
This CF CLI release is tested with minimum version CAPI release 1.109.0 and 1.124.0-rc.9
See our minimum supported version policy for more information.