Provide support for a corporate compliance warning when authenticating

[miclip]

Provide a means to configure a corporate legal notice when a user authenticates using pinniped-cli. Common for organisations to require a legal noticed be displayed when accessing corporate systems. Would mostly apply to LDAP/AD as OIDC should redirect to a service that can display the notice.

User executes kubectl cmd, pinniped challenges for credentials and displays a configured message, example below.

This system is company property and is provided for [company]-authorized
use only, including occasional personal use, as set forth in applicable
written policies. Unauthorized use is prohibited and may be subject to
discipline, civil suit and criminal prosecution. As [company] has a legitimate
interest in the security of this company resource as well as its efficient
and lawful use, any communications or data transiting or stored on this
system may be monitored, intercepted, recorded, and searched at any time
for any lawful purpose, and may be used or disclosed for any lawful purpose.
By using this system you understand and consent as follows: to comply with
all other applicable written policies, procedures and guidelines for system
use and protection of company information or information that the company
has an obligation to protect, including but not limited to Proprietary
Information, Personal Information/Personally Identifiable Information,
Controlled Unclassified Information, and Export Controlled Information.

[joshuatcasey]

This is pretty interesting.

At first glance I might expect this warning to be placed as close as possible to the resource being protected. If the cluster is being protected, this warning should be placed on the *Authenticator resource that permits access to that cluster. This would also allow for some customization per cluster. This would also mean the warning could be displayed in setups that do not include the Supervisor. It's not strictly clear to me how the warning text would be transmitted back from the concierge to the cli (in the TokenCredentialRequest response? This is awkward because this isn't returned until after login, but maybe that is ok?).

Another option: include the warning text in Supervisor discovery documents, which would imply it would be discovered and rendered on the login page (and possibly the Supervisor webpage that accepts the username/password?).

Yet another option that could be the easiest to implement is allowing admins to bake a warning into the kubeconfig with pinniped get kubeconfig --pre-login-banner-text or something similar. This is the most brittle option for administrators (requires rolling out new kubeconfigs for every textual change) and of course users could just edit it out of their own kubeconfigs.

What if we just created a new resource that only held this compliance warning, and the CLI looked for it in the concierge namespace?