Package: ocp-sso-token
Non-interactive CLI login for OpenShift clusters via OpenID-connected IdP with Kerberos supportThis package can be foundon Copr as@cki/ocp-sso-tokenon PyPI asocp-sso-tokenThe Copr packages are provided for all active Fedora releases, CentOS
Stream/EPEL Next 9 and RHEL/EPEL 9.The code is tested on thesupported Python versions3.8, 3.9, 3.10, 3.11 and
3.12.Quickstart# from Copr...sudodnfcoprenable@cki/ocp-sso-token
sudodnfinstallocp-sso-token# ...or from PyPIpipinstallocp-sso-token# get a Kerberos tokenkinitUSER@DOMAIN.COM# create a kubectl context with a temporary token via SSOocp-sso-tokenhttps://API.CLUSTER:6443--contextCONTEXT--namespaceNAMESPACE# and try it out!oc--contextCONTEXTgetpodProblem: several manual steps to log into an OpenShift cluster via OIDC without ROPCTo log into an OpenShift cluster on the command line,oc loginsupports
user/password authentication for variousidentity providerslikeLDAPorOIDC
with ROPC grant flow.If no provider with password support is configured, the user is referred to the
OAuth login page to obtain a temporary token interactively. After selecting the
right provider, the user is forwarded to authenticate with the SSO provider,
and redirected back to the cluster afterwards. Another click reveals the
temporary token that can now be used for the CLI tools.For an OpenID provider that supports Kerberos tickets, the authentication with
the SSO provider happens transparently. For such setups, logging into a cluster
via the CLI roughly requires the following steps:runoc loginand click on the link, or visit a bookmark for the cluster
login pageclick on the button for the OpenID providerwatch the webpages forwarding to each otherclick on the link to reveal the temporary tokenuse the shown temporary token/oc login command to log into the clusterThese steps must be performed daily and per cluster.Approach: automate all the steps aboveThe Python script in this repository automates all the steps to obtain the
temporary token so that the following is possible:kinit$user@$domain# either save the token directly in the specified context in ~/.kube/config...ocp-sso-token$server--context$context--namespace$namespaceoc--context$contextgetpod# ...or use the token with oc loginoclogin--server$server--token$(ocp-sso-token$server)ocgetpodInstalling the script# from Coprsudodnfcoprenable@cki/ocp-sso-token
sudodnfinstallocp-sso-token# from PyPIpipinstallocp-sso-token# from sourcepipinstall--usergit+https://gitlab.com/cki-project/ocp-sso-tokenUsing the script to log into an OpenShift cluster via OIDCusage: ocp-sso-token [-h] [--identity-providers IDENTITY_PROVIDERS]
                     [--context CONTEXT] [--namespace NAMESPACE]
                     api_url

Obtain an OCP OAuth token for a Kerberos ticket

positional arguments:
  api_url               Cluster API URL like https://api.cluster:6443

optional arguments:
  -h, --help            show this help message and exit
  --identity-providers IDENTITY_PROVIDERS
                        Identity provider names (default: SSO,OpenID)
  --context CONTEXT     Instead of printing the token, store it in the given context (default:
                        None)
  --namespace NAMESPACE
                        Namespace to use for --context (default: None)If your identity provider name is not included in the defaults shown above, add
it via--identity-providers. The first matching identity provider will be
used.With--context, the token is directly added to the Kubernetes configuration file
(~/.kube/configor KUBECONFIG). Otherwise, the token is printed to the console.Running a smoke testkinituser@DOMAIN.COMserver=https://api.cluster:6443;oc--server$server--token$(ocp-sso-token$server)getprojectLogging into clusters with custom context namesWith--contextand--namespace, the obtained tokens are directly configured
in the specified contexts:$kinituser@DOMAIN.COM
$ocp-sso-tokenhttps://api.cluster1:6443--contextcluster1--namespaceproject1
$ocp-sso-tokenhttps://api.cluster2:6443--contextcluster2--namespaceproject2

$occonfigget-contexts
CURRENTNAMECLUSTERAUTHINFONAMESPACEcluster1api-cluster1:6443api-cluster1:6443project1cluster2api-cluster2:6443api-cluster2:6443project2

$oc--contextcluster1getpod
$oc--contextcluster2getpodLogging into clusters viaoc loginWithout--context, the obtained tokens are printed to the console and can be
used withoc login. Logging into clusters this way creates context names
automatically. This is most useful with a single cluster, but works with
multiple clusters as well:$kinituser@DOMAIN.COM
$server=https://api.cluster1:6443;oclogin--server$server--token$(ocp-sso-token$server)$server=https://api.cluster2:6443;oclogin--server$server--token$(ocp-sso-token$server)$occonfigget-contexts
CURRENTNAMECLUSTERAUTHINFONAMESPACEdefault/api-cluster1:6443/user@domain.comapi-cluster1:6443user@domain.com/api-cluster1:6443default
*default/api-cluster2:6443/user@domain.comapi-cluster2:6443user@domain.com/api-cluster2:6443default

$oc--namespaceproject2getpod
$oc--contextdefault/api-cluster1:6443/user@domain.com--namespaceproject1getpod
$oc--contextdefault/api-cluster2:6443/user@domain.com--namespaceproject2getpodssl.SSLCertVerificationErrorIf you get an error similar to the following, most likely the intranet
certificates are not used by therequestsmodule as thecertifimodule
ships its own certificate store:ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:992)On Fedora/Debian-based distributions, this can be solved by using thecertifimodule from the distribution package repositories, e.g. viapipuninstallcertifi# if certifi was already installed via pipdnfinstallpython3-certifi# Fedora-based distributionsaptinstallpython3-certifi# Debian-based distributionsIt is also possible to force the use of a specific certificate bundle via
something likeexportREQUESTS_CA_BUNDLE=/etc/pki/tls/certs/ca-bundle.crtCreating a development setup and running the testsInstalling development dependencies:pipinstall-e.[dev]Running linting/tests:toxCreating a releaseCreate a release MR with an update of the version number inocp_sso_token/__init__.py, e.g to '3.1.4'Create an annotated tag with the same version prefixed withvand enter
the release notes as the tag message, e.g.gittagv3.1.4-aFor the release notes, list the important changes and include the
merge requests that introduced them, e.g.-Run tests in parallel on multiple Python versions (!8)Push the tag to GitLab, e.g.gitpushoriginv3.1.4Wait for the tag pipeline to finishCheck the resulting GitLab and PyPI releases