gravitational / teleport

The easiest, and most secure way to access and protect all of your infrastructure.
https://goteleport.com
GNU Affero General Public License v3.0
16.98k stars 1.71k forks source link

tctl get connectors #2246

Closed kontsevoy closed 5 years ago

kontsevoy commented 5 years ago

Problem

It is annoying that tctl get does not have a convenient connector resource type and instead of we're forcing users to remember their type, like 'saml' or 'github'. You can't even tell WHAT connectors are present until you try them all. It makes it hard to reason about security and it's easy to overlook connectors that (maybe?) shouldn't be there

Solution

$ tctl get connectors

It should dump all known connector types.

aberoham commented 5 years ago

Related UX issue -- users often accidentally try to run non-Enterprise and are then surprised that trying to use oidc or saml connectors generates a stack trace instead of a clear error message.

This is what you get right now if you try to apply an Enterprise tctl config to a non-Enterprise build:

# /usr/local/bin/tctl create -f okta-connector.yml 
ERROR REPORT:
Original Error: *trace.BadParameterError creating resources of type "saml" is not supported
Stack Trace:
/gopath/src/github.com/gravitational/teleport/tool/tctl/common/resource_command.go:170
github.com/gravitational/teleport/tool/tctl/common.(*ResourceCommand).Create
[snip]
User Message: creating resources of type "saml" is not supported

Could the above error include a hint that a given resource type is only supported in Enterprise?

klizhentas commented 5 years ago

most likely you see stack trace because you have DEBUG environment variable set.

aberoham commented 5 years ago

The UX User Message: creating resources of type "saml" is not supported is not as helpful as a message such as This version of Teleport does not support [plain english feature description], please check that you running commercial Teleport binaries or a version that includes the '[raw]' resource type

Also, end-users who aren't familiar with golang development often will miss the human-readable error messages because they're wrapped in golang'isms and then only repeated at the very end.

Could the human-readable error be more human, be listed as the first thing before the stack trace, then be repeated below the stack trace?

klizhentas commented 5 years ago

@aberoham yes, just create a separate ticket for this so we can track

russjones commented 5 years ago

Reopening to make this a documentation ticket, this is what the output looks like:

$ tctl get connectors
- kind: oidc
  metadata:
    name: google
  spec:
   ...
  version: v2
- kind: saml
  metadata:
    name: okta
  spec:
   ...
  version: v2
- kind: github
  metadata:
    name: github
  spec:
     ...
  version: v3
$tctl get connectors --format=text

OIDC:
Name   Issuer URL                  Additional Scope 
------ --------------------------- ---------------- 
google https://accounts.google.com profile,email    

SAML:
Name SSO URL                                                                                                    
---- ----------------------------------------------------
okta https://dev-683790.oktapreview.com/app/1234/sso/saml 

GitHub:
Name   Teams To Logins            
------ -------------------------- 
github @gravitational/1234: admin