djpbessems/ContainerImage.Pinniped
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Link to the release from our v0.10.0 blog post.

Browse Source 
Signed-off-by: Matt Moyer <moyerm@vmware.com>
This commit is contained in:
Matt Moyer 2021-07-30 16:35:38 -05:00
parent a06b38d2cd
commit 65fa47cbcd
No known key found for this signature in database
GPG Key ID: EAE88AD172C5AE2D
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
site/content/posts/2021-07-30-supporting-remote-oidc-workflows.md
View File

@ -13,11 +13,11 @@ tags: ['Matt Moyer', 'Anjali Telang', 'release']
## Remote Host Environments and OIDC login flows ## Remote Host Environments and OIDC login flows
Enterprise workloads on Kubernetes clusters often run in a restricted environment behind a firewall. In such a setup, the clusters can be accessed via servers sometimes called “SSH jump hosts”. These servers pose restrictions on what the users can execute and typically allow only command line access. Users can use command line utilities such as kubectl, pinniped CLI, etc. on these servers to access the Kubernetes clusters. However, this poses a problem for the OIDC login workflows since they require a browser to complete the authentication workflow. Enterprise workloads on Kubernetes clusters often run in a restricted environment behind a firewall. In such a setup, the clusters can be accessed via servers sometimes called “SSH jump hosts”. These servers pose restrictions on what the users can execute and typically allow only command line access. Users can use command line utilities such as kubectl, `pinniped` CLI, etc. on these servers to access the Kubernetes clusters. However, this poses a problem for the OIDC login workflows since they require a browser to complete the authentication workflow.
## Solution for Browserless clients ## Solution for Browserless clients
In this release, we introduce the ability to use a manual workaround to complete the OIDC workflow in such restricted browserless environments by supporting `response_mode=form_post` in the Pinniped Supervisor. As described in the [OAuth 2.0 Form Post spec](https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html), the response parameters are “encoded as HTML form values that are auto-submitted in the User Agent, and thus are transmitted via the HTTP POST method to the Client”. To complete the authentication process, The Pinniped users can copy and paste the response from the HTML page hosted by the Pinniped Supervisor into the waiting CLI process on the Jump Host. In the [v0.10.0 release](https://github.com/vmware-tanzu/pinniped/releases/tag/v0.10.0), we introduce the ability to use a manual workaround to complete the OIDC workflow in such restricted browserless environments by supporting `response_mode=form_post` in the Pinniped Supervisor. As described in the [OAuth 2.0 Form Post spec](https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html), the response parameters are “encoded as HTML form values that are auto-submitted in the User Agent, and thus are transmitted via the HTTP POST method to the Client”. To complete the authentication process, The Pinniped users can copy and paste the response from the HTML page hosted by the Pinniped Supervisor into the waiting CLI process on the Jump Host.
You can find more details in our [design document](https://hackmd.io/Hx17ATt_QpGOdLH_7AH1jA). You can find more details in our [design document](https://hackmd.io/Hx17ATt_QpGOdLH_7AH1jA).
@ -43,7 +43,7 @@ You can find more details in our [design document](https://hackmd.io/Hx17ATt_QpG
4. User competes the web-browser OIDC workflow and gets an authorization response code. 4. User competes the web-browser OIDC workflow and gets an authorization response code.
5. User will copy-paste the authorization code into the Jump Host environment to complete the login. 5. User will copy-paste the authorization code into the Jump Host environment to complete the login.
Additionally, the v0.10.0 includes support for non-interactive password based LDAP logins. This feature provides the ability for Jenkins as well as other CI/CD tools that use LDAP Identity Platforms to access the cluster with centralized service account identities from the LDAP directory Additionally, the [v0.10.0 release](https://github.com/vmware-tanzu/pinniped/releases/tag/v0.10.0) includes support for non-interactive password based LDAP logins. This feature provides the ability for Jenkins as well as other CI/CD tools that use LDAP Identity Platforms to access the cluster with centralized service account identities from the LDAP directory
We invite your suggestions and contributions to make Pinniped work across all flavors of Kubernetes. We invite your suggestions and contributions to make Pinniped work across all flavors of Kubernetes.