How are my services secured? 🔗︎
Backyards uses the mutual TLS feature of Istio for service-to-service authentication and traffic encryption. In Backyards, you can manage mTLS settings between services with the CLI or on the UI, mesh-wide, namespace-wide, and on the service-specific level.
Does Backyards use its own authentication system? 🔗︎
No, Backyards leverages Kubeconfig, the official client libraries, and the Kubernetes API to perform authentication and authorization for its users.
If you’re allowed to add, edit, or delete specific Istio custom resources, you’ll have the same permissions from Backyards as well.
The Backyards installer provides a way - mainly for demo/tryout purposes - to disable user authentication and use its own service account token for all communication with the Kubernetes API server.
What’s the story on access and visibility control? 🔗︎
By default, authentication is needed to access Backyards UI. The observability features are granted for every authenticated users, the control features allowance is based on the authenticated user’s RBAC permissions.
Do you keep an audit trail? 🔗︎
Every action or configuration update through Backyards is audited for accountability and to get insights from tracking changes.
Primarily, Backyards GraphQL API mutation events are recorded with information about the user and the specific query.
Secondarily, Kubernetes API server calls are recorded as well, similarly to how the API Server itself would record these events in its audit logs. That way the users can see the filtered Kubernetes event log, which is made by Backyards exclusively until the dynamic audit webhook backend feature reaches General Availability. Once that feature is available, users can configure a dynamic audit webhook separately for an even more accurate audit log.
