kubeauth

kubeauth

kubeauth is a program to assist usage of kubectl for user/group related operations. It currently provides two commands:

1. add-user creates a service account based user, adds the credentials to the selected kubeconfig, and optionally creates bindings to existing roles or cluster roles.
2. ctl wraps kubectl invocation and validates flags such as --as and --as-group.

add-user

Examples

Create the kubeconfig user "tester" based on service account "default" in the "dev" namespace. Also bind it to a role and cluster role. The --role and --cluster-role flags may be supplied multiple times.

kubeauth add-user -v=1 \
  --user tester \
  --account default \
  --namespace dev \
  --role role_name_0:binding_name_0 \
  --cluster-role role_name_1:binding_name_1

Validation checks

• --role: role exists in effective namespace
• --cluster-role: cluster role exists

ctl

• Invocation format: ctl [kubectl sub-command] [kubeauth flags] -- [kubectl sub-command flags]
• ctl flags which are also accepted by kubectl will be passed to the latter.

Examples

Verify that "tester" exists and run "kubectl auth can-i -v=1 --as tester --list".

kubeauth ctl auth can-i -v=1 \
  --as tester \
  -- --list

Verify that "system:serviceaccount:dev:default" exists and run "kubectl auth can-i -v=1 --as system:serviceaccount:dev:default --list".

kubeauth ctl auth can-i -v=1 \
  --as system:serviceaccount:dev:default \
  -- --list

Validation checks

• effective context exists
• effective namespace exists
• --as selection exists
• --as-group selection exists
• agreement between --cluster and effective context's cluster

Development

License

Mozilla Public License Version 2.0 (About, FAQ)

Contributing

• Please feel free to submit issues, PRs, questions, and feedback.
• Although this repository consists of snapshots extracted from a private monorepo using transplant, PRs are welcome. Standard GitHub workflows are still used.

Testing

ctl

• Reminders
  • "you typically need to include --as-group=system:authenticated in order to have permission to run a selfsubjectaccessreview check." (https://github.com/kubernetes/kubernetes/issues/73123#issuecomment-456185028)

FAQ

• ctl
  • Q: When verbose output is enabled with -v=1 and I use --as/--as-group flags, why do I not always see in namespace X in the messages describing where the user/group was found?
    • A: It may be that the --as/--as-group identity was found in a role or cluster-role binding where the Subject object contained an empty Namespace field. At the time this was written, the empty value is expected for User and Group subjects because those object kinds are considered "non-namespace".