I wanted to share some resources that detail the implementation and design aspects of Britive K8S support.
Britive uses unified PyBritive CLI that serves end users, admins, and developers alike. You can access it here:
https://britive.github.io/python-cli
This CLI offers numerous options and commands, including but not limited to:
– api: Exposes the Britive Python SDK methods to the CLI.
– aws: Groups together AWS-specific sub-commands.
– cache: Manages local cache settings.
– checkin: Checks in a profile.
– checkout: Checks out a profile.
– login: Performs an interactive login to obtain temporary credentials.
– logout: Logs out of an interactive login session.
– ls: Lists resources available for the currently authenticated identity.
– request: Provides functionality related to requesting approval.
– secret: Views or downloads a secret.
– ssh: Facilitates connecting to private cloud servers.
Some of the standout features include the ability to run any API command directly from the CLI and manage local cache settings or kubeconfig with the
`pybritive cache kubeconfig` command.
Additionally, for an in-depth understanding of the engineering behind our K8S implementation, you can refer to Britive’s technical documentation:
https://docs.britive.com/docs/kubernetes-onboarding-guide
Britive approach is platform independent so any flavor of Kuberenest implementation can be achieved with Britive solution. Weather you use Tanzu, EKS, GKE, AKS, its all standard based approach by connecting to Kubernetes API server. No need for any proxy or side-car or any code required.
https://docs.britive.com/docs/kubernetes-onboarding-guide
Private Kubernetes Implementations and Unique/Corner Use-Cases
If the organization finds group-based management restrictive or requires more detailed control over roles and permissions, Kubernetes Access Broker recipes allows for dynamic and granular role management. It provides flexibility to create custom role bindings on demand, catering to unique access requirements that cannot be addressed by the native implementation. Kubernetes Access Broker is particularly useful for scenarios where granular, role-based access control (RBAC) is needed, or when existing group-based management does not meet specific requirements.
Misc. References
Since we natively support any flavor of K8S, thats the reason you will not see each and every flavor listed on our website. Because it follows the same references architecture without any proporitery config or changes.
Some other reference are good too
https://www.britive.com/resource/blog/rbac-jit-access-kubernetes
https://www.britive.com/resource/blog/automate-jit-access-to-gke-clusters
https://www.britive.com/resource/blog/automate-just-in-time-access-to-azure-aks-clusters
https://docs.britive.com/apidocs
Summary
- Use Britive native K8S connector integration when role-binding already exist. In this case, Britive will provide temp token for JIT access to Kubernetes cluster/namespace.
- Use Access Broker based integration option when role-biding does not exist or deeper/granular control is required.
Comments are closed