Kerberos, Token and Hadoop

Kerberos, Token and Hadoop
MIT Kerberos Day
Intel Big Data Technologies
kai.zheng@intel.com
1

Outline
1. Kerberos and Hadoop
2. Token and Hadoop
3. Token and Kerberos
4. Kerberos, Token and Hadoop
5. Future work
2

4
When Hadoop adding security
 Initially no authentication at all
 Kerberos or SSL/TLS?
 Adding security should not impact performance much
 Kerberos is used to authenticate users, GSSAPI/SASL is
used between C/S, encryption on wire could be optional

 End users to services, using password
 Services to services, using service credentials/keytabs
 Services to services, delegating users, using service
credentials
 MR tasks to services, delegating users, using delegation
token
Kerberos authentication
5

7
Deploying Kerberos
Provisioning service credentials/keytabs

8
Deploying Kerberos (cont'd)

Strengths
 Symmetric encryption, mutual authentication
 Flexible SASL QoP, authentication (privacy) by default
 Command line (kinit, SSO) + Browser (SPNEGO)
 Mature, available in Linux/Windows + J2SE
9

Challenges
 Hadoop ecosystem is large and still fast evolving, other
authentication solutions are desired
 Hadoop cluster can be large, the traffic can be huge
 Services are dynamically provisioned and relocated on
demand
 Applications are to run in containerized environment, and
can be dynamically scheduled and relocated to other
nodes automatically
 Different deployment environments and scenarios, with
different requirements
10

 Lagged Kerberos feature support in Java (PKINIT, S2U
only added recently, etc.)
 Lacking fine-grained authorization support
 Lacking strong delegation support in Kerberos/Java stack
 Inconvenient and limited browser access via SPNEGO, for
work around to bypass Kerberos exposing internal
delegation token
 Encryption not set in SASL via (QoP) by default, and might
involve performance impact (benchmark and
optimization?)
 AES 256 isn’t supported by Java by default
 Just get it work, allow_weak_crypto is used;
 kinit –R issue
Problems
11

Outline
2. Token and Hadoop
5. Future work
12

Hadoop tokens
Existing Hadoop tokens for internal authentication:
delegation token, job token, block access token …
13

TokenAuth effort
Proposed token for primary/initial authentication
14

Requirements
 Allow to integrate 3rd party authentication solutions
 Help enforce fine-grained authorization
 Supporting OAuth 2.0 token and work flow is desired for
cloud deployment
15

Challenges
 Involve great change over the ecosystem
 May break existing applications built on the platform
 Over complex, involving both Identity Token and Access
Token with related services, the work flow is quite
complex. (Reinvent Kerberos?)
 Big impact for performance or security concerns
We either use TLS/SSL to protect token or don’t care about it at all.
The former involves performance impact, the latter suffers security
consideration.
16

Outline
2. Token and Hadoop
5. Future work
17

TokenPreauth mechanism
Allows user to authenticate to KDC using 3rd party tokens instead of
password
18

TokenPreauth mechanism (cont’d)
 Defines required token attribute values based on JWT
token, reusing existing attributes
 Support Bearer Token and allows to support Holder-of-Key
Token in future
 Support Identity Token (or ID Token) and allows to support
Access Token in future
19

TokenPreauth mechanism (cont’d)
 Client principal may exist or not during token validating
and ticket issuing
 kinit –X token=[Your-Token], by default ref. ~/.kerbtoken
 How token being generated may be out of scope, left for
token authority
 Identity Token -> Ticket Granting Ticket, Access Token ->
Service Ticket
 Ticket lifetime derived from token SHOULD be in the time
frame of the token
 Ticket derived from token may be not renewable
20

Access Token profile
 Based on TokenPreauth, allow Access Token to be used
to request Service Ticket directly in AS exchange
 Should be useful to support OAuth 2.0 Web flow in
Kerberized Resource Server with backend service
21

Why it matters
 Token and OAuth are widely used in Internet, cloud and
mobile, more and more popular
 It allows Kerberized systems to be supported in token’s
world
 Also allows Kerberized systems to integrate other
authentication solutions thru token and Token Authority,
without modification of existing codes.
 May help Kerberos evolve in both cloud and big data
platform
 Make extra sense for Hadoop, supporting token across the
ecosystem without performance impact
22

How it is going
 We’re collaborating with MIT to standardize
 Initial drafts, under MIT team’s review
 Should be submitted to KITTEN WG soon
 PoC done targeting for Hadoop
23

Outline
2. Token and Hadoop
5. Future work
24

Kerberos + Token for Hadoop
 Let’s combine all of these together

PoC: Token authentication JAAS module
27

PoC: Browser and Web support
28

 Implement the mechanism and have it included in next
MIT Kerberos release, collaborating with MIT team
 Or at least, provide the plugin binary download and source
codes repository for public usage and review
 Make a complete token solution based on Kerberos for
Hadoop
Next step
29

 The Repo:
https://github.com/drankye/haox
 Working on a first class Java Kerberos client library
 Catch up with latest Kerberos features and fill gaps lagged
by Java
– PKINIT
– TokenPreauth
Haox project
30

Haox-asn1
 A data driven ASN-1 encoding/decoding framework
 A simple example, AuthorizationData type from RFC4210
31

Haox-asn1 (cont’d)
 A simple example, AuthorizationData type from RFC4210
32

Haox-asn1 (cont’d)
 A more complex example, from X.690-0207
33

Haox kerb-crypto
 Implementing des, des3, rc4, aes, camellia encryption and
corresponding checksum types
 Interoperates with MIT Kerberos
 Independent with Kerberos codes in JRE, but rely on JCE
34

 ASN-1 (done)
 Core spec types (done)
 Crypto (done)
 AS client (going)
 Preauth framework (going)
 PKINIT (going)
Haox Status
35

Future work
 Combining all of these effort together, make a complete
token solution for Hadoop
 Additionally, we’d also like to make Kerberos deployment
be more easily and readily even for large Hadoop clusters
It’s Intel’s mission that makes Hadoop more enterprise-grade security
ready
 We’re also interested in evolving Kerberos for cloud
platform, particularly, how Kerberized services and
applications can be dynamically scheduled to nodes and
bootstrap
 Will investigate how Intel’s technology like TEE/TXT can
help thru all of these
36

Trusted Execution Technology (TXT)
 Establishing root of trust through measurement of
hardware and pre-launch software components, and
utilizing the result,
1.Run your workload and data on a trusted
2.Protect your workload and data
3.Avoid compromising security in the cloud
4.Sealed and secured storage
37

Kerberos with TXT
 With the secured storage provided by TXT,
1.Protect credential cache to store TGTs for Kerberos
2.Protect token cache for Hadoop
3.Protect encryption keys for data
4.Protect key store for management

Kerberos with TXT (cont’d)
 With secured token cache and trusted execution by TXT,
TokenPreauth can be deployed with host keytab/cert

Thanks!
You feedback are very welcome
Please contact kai.zheng@intel.com for update.
40

Kerberos, Token and Hadoop

Recommended

More Related Content

What's hot (20)

Similar to Kerberos, Token and Hadoop (20)

Recently uploaded (20)

Kerberos, Token and Hadoop