Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1357061 - RFE: Openshift Installer (BYO): Make adding different types of identity providers easier to the inventory file
Summary: RFE: Openshift Installer (BYO): Make adding different types of identity pro...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Auth
Version: 3.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 4.1.0
Assignee: Erica von Buelow
QA Contact: Chuan Yu
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-15 15:26 UTC by Matt Woodson
Modified: 2019-03-12 14:03 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-12-03 12:50:39 UTC


Attachments (Terms of Use)

Description Matt Woodson 2016-07-15 15:26:46 UTC
Description of problem:

Let me preface this by saying this isn't an easy issue to solve. But this is one that I would like to get some improvements on. It would help Openshift Ops quite a bit.

The current problem:

We are using the BYO inventory file to configure a lot of clusters with all sorts of authentication schemes. There is one variable to configure all of these:

openshift_master_identity_providers

Then, we need to set this var as a json dict. There are multiple problem with this:

-there is no good examples with all of the different supported auth types (at least I couldn't find them)

- the auth types don't have all of the options documented.
(https://gist.github.com/detiber/da042623b26522fcd5767825eafe97a0 as an example)

- the dictionaries that are needed do NOT line us with official docs of the auth type. What i mean by this, we pass in a dictionary of values that are then put in the right place in the yaml code by the byo. For example, I can't look at https://docs.openshift.com/enterprise/3.2/install_config/configuring_authentication.html and come up with what the json dictionary should be.

- each dictionary takes different options depending on the auth type.

- the dictionaries are hard to read

- not all options in the dict are needed. It's hard to know what is, what isn't. It would help if this was lined up with documents.

Comment 1 Matt Woodson 2016-07-15 15:27:33 UTC
This originally filed here:

https://github.com/openshift/openshift-ansible/issues/2083

I would like to brainstorm on the possible outcome. I would love to hear other's thoughts.

Here is one of the suggestion that could help solve the issue. Take this for what it's worth.

What if a variable was added like:

openshift_master_identity_type=

This would be one of the types of id that openshift supports. It could be "google", "github", "openid", "htpasswd", etc...

Then, there would be a list of required or variables that go with each provider type. I would envision each type having it's own set of variables that are needed. If the option isn't required, the byo should handle that appropriately. For example, if

openshift_master_oauth_type=google

We would then have other variable that are used:

openshift_master_oauth_google_provider_clientID=
openshift_master_oauth_google_provider_clientSecret=
openshift_master_oauth_google_provider_hostedDommain=

There could be oauth level ones that map accross all types of auth. For example, the higher level ones could be something like:

openshift_master_oauth_mappingMethod=lookup

This could be documented fairly easily. We could add additional variables based on the oauthConfig found in the docs and in the config file.

I think this would be much easier than the existing dictionary. This would also line up with what is in the docs and follow the oauthConfig dictionary found in the master-config.yml.

Comment 2 Matt Woodson 2016-07-15 15:41:44 UTC
@detiber  If you could have a simple version that worked for a handful of auth providers, I would support that.  But when we start jamming in data structures into a single variable, in my opinion that loses it's simplicity.  I am not against providing  something simple, but I do want the flexibility to put in something.

I'd be ok with being able handing over a "final configuration chunk", something that the final output would like in master-config.yml, and then you put it in place as one of the auth types.  We could store our auth  variables in yaml at that point, hand them to the installer, and just have it do the right thing.  Then you could keep a simple and have this way be the "advanced" config.  

Hmm, the more I think about this, the more I like this.  The advantages are:

- we could use official documentation for the right variables.  We wouldn't have to guess how they will be interpreted and then converted
- we could use this to check against the master config  with config management.
- it should be easy for you, and then not have to write all sorts of different variables for different advanced auth types, and maintain them.  It's just pure yaml.

I like this this idea, thoughts from you guys?


Note You need to log in before you can comment on or make changes to this bug.