Pinniped v0.16.0: With Build-Your-Own FIPS Binaries, Workspace ONE IDP configuration, and Supervisor HTTP listener changes
Apr 20, 2022
Photo by karlheinz_eckhardt on Unsplash
This release continues our theme of providing security-hardening for Kubernetes authentication solutions with Pinniped.
Build-Your-Own FIPS compliant Pinniped Binaries
We now bring to you information on how to Build-Your-Own Pinniped binaries with FIPS Compliant BoringSSL Crypto. The Federal Information Processing Standard (FIPS) 140-2 publication describes United States government approved security requirements for cryptographic modules. Software that is validated by an accredited Cryptographic Module Validation Program (CVMP) laboratory can be suitable for use in applications for US governmental departments or in industries subject to US Federal regulations.
Refer to our FIPS reference documentation that provides details on how to compile Pinniped with a FIPS validated cryptographic module that adheres to the standards established by FIPS 140-2. We are using BoringSSL/BoringCrypto in our example with an open source BoringCrypto flavor of Go readily available as the cryptographic module. BoringSSL is Google’s fork of OpenSSL and as a whole is not FIPS validated, but a specific core library called BoringCrypto is. For more detailed information about BoringCrypto see here.
Note: We will not provide official support for FIPS configuration, and may not respond to GitHub issues opened related to FIPS support. Out intent is to provide you with an example of how you can do this yourself in your environments.
Supervisor with default HTTPS listener port
With v0.13.0 we had announced that we will disable the use of default HTTP listeners.
Breaking change in this release: With this release, we disable the Supervisor’s HTTP listener by default, and will not allow it to be configured to bind to anything other than loopback interfaces.
However, we do recognize that it may take some users time to adjust to this breaking change. If you want to bring back the insecure http listen ports behavior into your deployments, you can set the variable, deprecated_insecure_accept_external_unencrypted_http_requests, in your Supervisor deployment yaml file. This will print a warning in the pod logs that lets you know that this is an insecure option. Please do note that we plan to remove this field in some future release and only provide you with secure https options. This deprecated field will be available for at least two releases to give users time to make changes.
This feature does not change any HTTPS listen port configuration nor does it change the user’s ability to do the following with the HTTP listener ports:
- Enable or disable the HTTP listening port
- Configure the HTTP listening port to listen on tcp loopback interfaces (ipv4, ipv6, or both) or on a unix domain socket file for listening for connections from inside the pod, for example connections from a service mesh’s sidecar container
- Choose the port number for the HTTP listening port
For more information on this feature refer to #981.
Workspace ONE Identity Provider configuration
We continue to gather feedback from the community around the need to integrate with different Identity Providers. With this in mind, we have documented our support for configuring VMware Workspace ONE Access (formerly VMware Identity Manager) as an Identity provider. Workspace ONE access also acts as a broker to other identity stores and providers—including Active Directory (AD), Active Directory Federation Services (ADFS), Azure AD, Okta and Ping Identity to enable authentication across on-premises, software-as-a-service (SaaS), web and native applications. Available as a cloud-hosted service, Workspace ONE Access is an integral part of the Workspace ONE platform.
Refer to our detailed guide on how to configure supervisor with Workspace ONE Access.
What else is in this release?
In addition to the above features, this release also adds custom prefixes to Supervisor authcodes, access tokens, and refresh tokens. The prefixes are intended to make the tokens more identifiable to a user when seen out of context. The prefixes are
pin_ac_ for authcodes,
pin_at_ for access tokens, and
pin_rt_ for refresh tokens. See #688 for more on this.
Refer to the release notes for v0.16.0 for a complete list of fixes and features included in the release.
The Pinniped community continues to grow, and is a vital part of the project’s success. This release includes contributions from users @vicmarbev and @hectorj2f. Thank you for helping improve Pinniped!
Are you using Pinniped?
Did you try our new security hardening features? Are there other Identity Providers for which you want to see documentation similar to what we provided for Workspace ONE Access?
We thrive on community feedback and would like to hear more!
Reach out to us in #pinniped on Kubernetes Slack, create an issue on our Github repository, or start a discussion.
Join the Pinniped community!
Pinniped is better because of our contributors and maintainers. It's because of you that we can bring great software to the community.
Connect with the community on GitHub and Slack.
Join our Google Group to receive updates and meeting invitations.
Pinniped v0.18.0: With User-Friendly features such as JSON formatted logs, LDAP/ActiveDirectory UI Support
With v0.18.0 you get cool new features like nicely formatted JSON logs, UI to login to your LDAP or ActiveDirectory Identity Provider, and more
Pinniped v0.13.0: Security Hardened Pinniped
With the release of v0.13.0, Pinniped only supports the use of secure TLS ciphers, configurable Pinniped Supervisor listener ports, and reflecting changes made by the identity provider on the user’s Kubernetes cluster access
Pinniped v0.11.0: Easy Configurations for Active Directory, OIDC CLI workflows and more
With the release of v0.11.0, Pinniped offers CRDs for easy Active Directory configuration, OIDC password grant flow for CLI workflows, and Distroless images for security and performance