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
