Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prepare input for OPA #225

Merged
merged 5 commits into from
May 26, 2020
Merged

Conversation

lazyniv
Copy link
Member

@lazyniv lazyniv commented Apr 24, 2020

Now OPA input provides the following objects:

  1. All information about connection (usage: input.connection.[...]. For example, a token from zero path segment we can get as input.connection.path.path_segments[0].token)
  2. The TLSInfo (as retrieved by peer.FromContext for Server or grpc.Peer for the Client) which contains the following data:
    • "certificate" -- is a pem encoded x509cert (usage: input.auth_info.certificate)
    • "spiffe_id" -- is a spiffeID from SVIDX509Certificate (usage: input.auth_info.spiffe_id)
  3. "operation" -- one of request/close (usage: input.operation)
  4. "role" -- one of client/endpoint (usage: input.role)

An example of using OPA input for the case of token signature verification

package test 
default allow = false    
allow { 
   token := input.connection.path.path_segments[0].token  
   cert := input.auth_info.certificate  
   io.jwt.verify_es256(token, cert) # signature verification  
}

Motivation #200

Signed-off-by: Dmitry Vlasov dmitry.vlasov@xored.com

@edwarnicke
Copy link
Member

edwarnicke commented Apr 28, 2020

package test 
default allow = false    
allow { 
   token := input.connection.path.path_segments[0].token  
   cert := input.auth_info.certificate  
   io.jwt.verify_es256(token, cert) # signature verification  
}```

Before the line:

cert := input.auth_info.certificate


We need something to *validate* the cert.

Note: This is not a commentary on the code at all... it's just a comment on what we need to do in the policy :)

"spiffe_id": spiffeID,
},
"operation": operation,
"role": role,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tell me what you are thinking about the "role" parameter :)

Copy link
Member Author

@lazyniv lazyniv Apr 29, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@edwarnicke I don't understand what the authorization client chain element should do. Please can you explain some usage cases when we need to use authorization client? Authz server is handle policies by using connection and tls info from context, but what authz client should do?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Client-side authorization is used to decide if you trust who is providing you the Network Service.

Client-side authorization would also use OPA to do authorization based on the TLSInfo and Connection... but in this case its the Connection returned from its Request call.

Dmitry Vlasov added 5 commits April 30, 2020 10:50
Signed-off-by: Dmitry Vlasov <dmitry.vlasov@xored.com>
Signed-off-by: Dmitry Vlasov <dmitry.vlasov@xored.com>
Signed-off-by: Dmitry Vlasov <dmitry.vlasov@xored.com>
Signed-off-by: Dmitry Vlasov <dmitry.vlasov@xored.com>
Signed-off-by: Dmitry Vlasov <dmitry.vlasov@xored.com>
@lazyniv
Copy link
Member Author

lazyniv commented May 20, 2020

@edwarnicke What do you think about operation and role parameters? In my implementation of OPA input we just pass these parameters to OPA as strings in authorization chain element. What do you think about of this approach?

@edwarnicke edwarnicke merged commit d607108 into networkservicemesh:master May 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants