Thanks for collecting this comprehensive list of improvements. Many of
these things have been on the “wish list” for a while now, and it would be
great to get them done.
I’ll see if I can write up some KIP content and/or one-pagers to propose
some details for some of this work. Then we can discuss in more detail, and
define some specific tasks/Jira issues.
I think shooting for a release mid-April is a good goal, even if we can’t
complete the list exhaustively.
Thanks again,
Phil
On Tue, Feb 12, 2019 at 3:51 PM larry mccay <lmc...@apache.org> wrote:
> All -
>
> I'd like to officially start the planning for the 1.3.0 release of Apache
> Knox.
>
> After looking at the list of outstanding JIRAs with fixVersion of 1.3.0,
> existing KIPs and considering requirements for a more containerized and
> cloud oriented world, I have a like of general categories:
>
> * TLS Improvements
> - Configurable Keystore Location and Password
> - Configurable Truststore Location and Password
> - Mutual Auth SSL truststores and client certs keystores
> - Dynamic keystore/truststore loading
> * Must keep in mind the KnoxCLI for create-cert, export-cert
>
> * Management Improvements
> There have been a number of people asking about the following and they are
> all encountering similar pain - whether it be from a containerization
> context, DevOps or management tool, perspective a number of these are
> painful today for Knox admins.
> - Eliminate needs to have access to the Knox machines
> - Bootstrap config for log locations, pids, env variable overrides, etc
> - Remote access to public certs (for SSL and for various signature
> verification(knoxtoken, knoxsso, etc))
> - UI for Alias Management
> - Surface logs in UI(maybe?) and API
> - Master Secret synchronization across instances
> - Service Discovery from new source/s
> - new Remote Config Monitor source/s
> - new Remote Alias Service for Vault
>
> * SSO
> Easing the configuration required to enable all of the participating
> applications for KnoxSSO across a deployment will be important in general
> but being able to more easily provision this for cloud deployments will be
> key.
> - IDP Initiated Flow with Landing Page (Okta portal page)
> - challenge - particpating apps are configured for a single IDP
> - Landing Page is like Okta - with links to UIs - how do we deal
> with multiple topologies
> - KnoxSSOut - logout from landing page
> - Keycloak?
> - Add a standard integration pattern for SPs to register with KnoxSSO -
> like SAML?
> - Azure AD with OAuth/OpenID Connect
> - Internal hostnames vs external for cookie domain
> - IDP metadata file for SPs to pull KnoxSSO public cert and any other
> details from an endpoint
>
> * Performance
> Performance is an ongoing item but deployment scenarios for cloud and
> hybrid may introduce new strategies for things like load balancing in front
> of and behind the Knox gateway.
> - LoadBalancing from dispatch
> - HA provider config?
> - service specific
> - Hive cookie - sticky sessions
> - Knox HA story requires sticky sessions
> - TLS Options
> - Sizing Guidelines
> - JVM tuning
> - number of instances based on anticipated load (services need to
> be taken into account)
>
> * KnoxShell
> As deployments move more and more to the cloud and/or hybrid combinations,
> the need to SSH to a gateway machine becomes more and more awkward. If we
> can provide a powerful enough scripting experience for Data Worker/ETL type
> roles, we will be able to limit the need to SSH.
> - Remote CLI classes
> - ETL Usecase Classes
> - Livy classes
>
> * KnoxCLI
> - return error codes rather than throwing exception and always
> returning zero
>
> Many of our 1.3.0 JIRAs fall into one or more of the above categories.
> There are also quite a few of dispatch related issues filed.
>
> I realize that is a rather large list and a mixed back of category and
> detail in places.
>
> I think that we need to write up a couple KIPs to encompass the work above
> that we would like to tackle in 1.3.0 and then identify/file JIRAs to
> represent the work.
> We will need to carefully manage scope in order to get this done but
> articulating this roadmap with some new KIP pages will help 1.3.0 and
> future releases.
> Thoughts?
>
> As for timeline, I am thinking that mid-April may feel appropriate.
> Thoughts?
>
> thanks,
>
> --larry
>
