libopenstorage
SDK Auth Proposal
Is this a BUG REPORT or FEATURE REQUEST?: FEATURE
SDK User Authentication
Overview
The SDK API is currently available to any who can access it and provides no security model. This proposal provides a model for securing the SDK access with authentication and authorization of users. The model used by this proposal is based on the OpenID Connect standard, or OIDC, used by Kubernetes, Google, Twitter, SalesForce, or Dex just to name a few.
Goals
- Provide a method where users can be authenticated
- Provide a method where users can be authorized
- Have no user management, only verification of tokens
Non-goals
- User management is something left to the user to manage. This project will only verify the tokens provided by the user.
Design
- Admin would configure OpenStorage server for a specified OIDC issuer.
- User would get a token from the approved OIDC issuer
- User would pass token with every SDK API call to OpenStorage.
- OpenStorage SDK Server would get the public keys from the issuer.
- OpenStorage would verify the token and check if the user is authorized.
Detailed Design
Authentication
Server configuration
To verify tokens, The server would need to be configured to allow a single, or multiple (TBD), OIDC issuers. For each issuer, the system would need the following configuration:
- oidc-client-id: Client ID provided by authentication issuer
- oidc-issuer-url: Issuer url, (e.g. https://accounts.google.com)
- oidc-ca-file: Path to certifificate. Needed if accessing internal issuers.
- oidc-admin-users: A list of admin users. Format is TBD, but could be something like:
sub:username,email:[email protected], following the format{JWT claim key}:{JWT claim value}
NOTE: This is similar to the configuration used in Kubernetes
Generating a Token
A user would use a tool like oidc-gen-token, kube-oidc, or any other tool which would authenticate the user with an OpenID Connect issuer to provide them with a OIDC token.
User would then use this token for all the API calls to the SDK. Both the REST gRPC Gateway and the gRPC endpoint would both support this model.
REST Gateway token management
The REST Gateway will not verify the token. Instead it will only repackage it for the gRPC calls. It will
expect the token in the header payload of the HTTP request, then it will place it in the metadata of the gRPC context.
gRPC Server
The gRPC Server will have an authentication interceptor which will verify the token stored in the metadata of the context. To verify this token it will use go-oidc, which takes of pulling the public keys from the issuer and then verifying the token.
Authorization
Authorization of the user will be checked against a set of Roles in the OpenStorage SDK Server. To keep authorization simple, the server will only support the following roles:
- admin: Can use any SDK API. Initial admins are set through the configuration of the server and cannot be changed.
- noaccess: No access to any API call. This is the default role for anyone logging in. Admins will need to change the role of a user to something else.
- user: Storage system user. Cannot modify the cluster, but can manage volumes.
After some discussion, we are going to make this much simpler in the initial release by using shared secret and/or cert based tokens.