Extend kubectl auth can-i support for kubernetes_resources RBAC rules

[tigrato]

This PR extends the Teleport capabilities of kubectl auth can-i to support
evaluation of kubernetes_resources.

It also changes the error message to be clear to the users what's the
cause of the error and adds a warning when users try to edit invalid
roles.

[hugoShaka]

Edit: the rolev5 was fixed, I removed the part about it.

If I understand correctly, before the change:

• rolev5:
  • if resource restrictions empty -> wildcard in resource restrictions
• rolev6:
  • if resource restrictions are set we honour them
  • we don't touch resource restrictions -> by default no access

after the change:

• rolev5:
  • if label set -> wildcard in resource restrictions
• rolev6:
  • if resource restrictions are set we honour them
  • if no resource restrictions but labels set -> wildcard in resource definition

The following rolev6 which was not providing any access will start to work.

kind: role
metadata:
  name: kube-access
version: v6
spec:
  allow:
    kubernetes_labels:
      'region': '*'
      'platform': 'minikube'
    kubernetes_groups:
    - developers
    kubernetes_users:
    - minikube
  deny: {}

I understand this is intended and provides a better user experience, but this was not a bug and might be a surprise if users who had no access suddenly can hit any resource after a Teleport update.

I think we should not change the v5 behaviour at all, for the v6 behaviour change I would be more comfortable with introducing a v7. It's awkward to have to bump the version again, but as a security company I think we must to strictly follow versioning constraints to avoid exposing our user's infrastructure.

[tigrato]

@hugoShaka the rolev5 was a typo.
The change should only affect rolev6 and by default it will fill the kubernetes_resources in a similar way as rolev5 and rolev4

[hugoShaka]

I'm not sure this heuristic is robust enough: depluralizeResource("ingress") will have a weird behaviour.

If you don't think we need to fix this now, can you add a warning in types.KubernetesResourcesKinds to ensure we don't introduce support for a resource ending with an s without changing the logic here?

[tigrato]

Right now we only support pods and once we support other options I will have a conversion table

[hugoShaka]

Would you mind adding kubectl auth can-i at the end of the Kubernetes access guide in a subsequent PR (or this one but we'd need to pull docs folks manually)?

[public-teleport-github-review-bot]

@tigrato See the table below for backport results.

Branch	Result
branch/v12	Failed
branch/v13	Create PR