Project

General

Profile

Feature #24165

Refactor credential handling

Added by Marco Mambelli 11 months ago. Updated 2 months ago.

Status:
New
Priority:
Normal
Category:
-
Target version:
Start date:
03/10/2020
Due date:
% Done:

0%

Estimated time:
Stakeholders:

HEPCloud, OSG

Duration:

Description

In credential handling, there are many general codes and assumptions that could lead to bugs like [#24160].
It further lacks generality assuming the x509 certificates.
This is particularly important considering that the code will probably change to handle tokens.
Here a list that could be handled also in separate tickets:
  1. factor out general utility function like safe_update and compress+encode
  2. explicitly mention the type of credential and the format it is stored in and if it has a special purpose (e.g. compressed is not the same as compressed+key_value)
  3. clean the code using context managers when possible (os.file)
  4. be ready to handle multiple credential types for one entry (and multiple attempts)
    1. discuss w/ factory operators or SH meeting: specify the cred type or try all? 2 options (diff cred -> diff entry, try a list of entry and FE +stop at failure, try first one in entry list provided by FE)

Keep an eye on existing credential tickets, like [#23768]

Some use cases presented by Steve Tim:
  • given a group w/ a proxy, some entries require a project ID, sone not (type matching)
  • given a group w/ a proxy and project ID, different entries use different project ID (domain matching - different domains for different IDs)
Reconsider the whole credentials system:
  • how are secrets handled in other frameworks?
  • how is HTCondor doing? What tools or suggestions are there? - Propose a dedicated meeting w/ HTCondor developers
  • should project ID and similar information remain tied to credentials or not? VM type?
  • should scopes be hierarchical (or include the entry at the end, to allow per-entry selection in the Frontend)?
In GWMS:
  • credentials: part is public, part is secret, some elements are required, some optional
  • entry requires a type (set of elements) -> entry requires one of the accepted types (list)
  • types: GSI (proxy), username+password, priv+public_key, GCE, AWS, IDtoken, SciToken
  • optional type components (for all types): project ID
  • make names uniform: auth_method+trust_domain, type+trust_domain -> cred_type(s) cred_domain (or scope)
  • secrets are owned by the Frontend (global or group), the Factory is just using or forwarding them (to the Glidein)
  • in a place (global + group) multiple credentials of the same type+domain are equivalent
  • the Frontend should decide which credentials to send using only type+domain from the Factory (entries)
  • forwarded via encrypted classad -> allow also reference in vault/credmon/...
  • add "use" of credential (Factory, Glidein OR submission, pool, logging, ...)
    • the submission ones are matched w/ entry requirements and used at the Factory
    • others are forwarded to the Glidein
    • there could be uses used also on the Fronten (logging? cred renewal?)
  • avoid group ballooning just to change optional components in a credential (amazon zone, project ID, ...)
  • different credentials could use the same file (e.g. proxy for cred w and w/o project ID). Only one should be responsible for renewal, ...
Sw considerations:
  • there should be a hierarchy of cred type classes (e.g. cred->token->IDtoken)
  • extension, no modification: framework should not require changes if type is added
    • optional elements added to a class are in all the children w/o need to change the children
  • cred -> type,domain; verification (mandatory/optional parts); matching (compatible type+domain)
Intermediate step for 3.7.2:
  • token as a type of credential, same as grid_proxy, ...
  • no error if a token is provided and no proxy

Other tickets: 21324, 23768, 25200


Related issues

Related to GlideinWMS - Feature #25200: Consider tokens for glidein submission the same way as grid_proxy, ssh keys, ...New11/13/2020

Related to GlideinWMS - Bug #23768: Bug in multiple credential distributionNew12/15/2019

Related to GlideinWMS - Feature #21324: Handle new GCE credential formatNew11/07/2018

Related to GlideinWMS - Bug #24160: Submission to GCE brokenClosed03/10/2020

History

#1 Updated by Marco Mambelli 3 months ago

  • Target version changed from v3_7_1 to v3_7_2

#2 Updated by Marco Mambelli 2 months ago

  • Target version changed from v3_7_2 to v3_9_x
  • Description updated (diff)

#3 Updated by Marco Mambelli 2 months ago

  • Related to Feature #25200: Consider tokens for glidein submission the same way as grid_proxy, ssh keys, ... added

#4 Updated by Marco Mambelli 2 months ago

  • Related to Bug #23768: Bug in multiple credential distribution added

#5 Updated by Marco Mambelli 2 months ago

#6 Updated by Marco Mambelli 2 months ago

  • Related to Bug #24160: Submission to GCE broken added

#7 Updated by Marco Mambelli 2 months ago

  • Stakeholders updated (diff)
  • Description updated (diff)

#8 Updated by Steven Timm 2 months ago

It should be also noted that in some cases, like AWS and Google, the credentials system is being overloaded to pass things such as VM Instance Type which are not properly credentials at all.

Also available in: Atom PDF