This repository has been archived by the owner on May 3, 2022. It is now read-only.
Shipper requires access to all Secrets in management cluster #52
Comments
kanatohodets
added a commit
that referenced
this issue
Nov 23, 2018
This is a bug, since Shipper doesn't need cluster-wide access to Secrets in the management cluster, but it isn't ready to have scoped access. So, until we fix that (#52) we don't need code for Roles or RoleBindings, and just include cluster-wide access to secrets in the ClusterRole.
kanatohodets
pushed a commit
that referenced
this issue
Nov 23, 2018
crds: translate remaining CRDs to structs shipperctl: create all the CRDs in 'apply' Fixed bugs discovered in functional testing. Changed code and custom resource definitions to migrate to v1alpha1. Updated dep in the Travis configuration Fixed a linting error. Attempting to force vendor errors to be excluded. - Removed the Should* methods on the Cluster configurator, except ShouldCopySecret -- kept that one to generate better output - Formatted go imports - Fixed the definition of the SecretNotFound error struct - Changed the output of the command to conform to this new way of calling functions and using the already exists error as an indication that the object already exists Turned variable declarations into constants where needed. Improved outputting errors and fixed the Shipper import name. - INitialize the list of capabilities to an empty slice if it's nil - Do a priliminary validation of clusters to generate nicer - messages. At this point, this is only checking if region is empty. shipperctl: use shipper.SchemaGroupVersion instead of string shipperctl: include secrets/events in management clusterrole This is a bug, since Shipper doesn't need cluster-wide access to Secrets in the management cluster, but it isn't ready to have scoped access. So, until we fix that (#52) we don't need code for Roles or RoleBindings, and just include cluster-wide access to secrets in the ClusterRole. shipperctl: firmer split between app/management clusters This commit ensures that management cluster and app cluster setup are kept distinct, and introduces seperate service accounts for the two. Furthermore, all RBAC objects are labled with the domain that pertain to -- management or application. This helps to keep things straight in a combo cluster, as in development.
kanatohodets
pushed a commit
that referenced
this issue
Nov 23, 2018
crds: translate remaining CRDs to structs shipperctl: create all the CRDs in 'apply' Fixed bugs discovered in functional testing. Changed code and custom resource definitions to migrate to v1alpha1. Updated dep in the Travis configuration Fixed a linting error. Attempting to force vendor errors to be excluded. - Removed the Should* methods on the Cluster configurator, except ShouldCopySecret -- kept that one to generate better output - Formatted go imports - Fixed the definition of the SecretNotFound error struct - Changed the output of the command to conform to this new way of calling functions and using the already exists error as an indication that the object already exists Turned variable declarations into constants where needed. Improved outputting errors and fixed the Shipper import name. - INitialize the list of capabilities to an empty slice if it's nil - Do a priliminary validation of clusters to generate nicer - messages. At this point, this is only checking if region is empty. shipperctl: use shipper.SchemaGroupVersion instead of string shipperctl: include secrets/events in management clusterrole This is a bug, since Shipper doesn't need cluster-wide access to Secrets in the management cluster, but it isn't ready to have scoped access. So, until we fix that (#52) we don't need code for Roles or RoleBindings, and just include cluster-wide access to secrets in the ClusterRole. shipperctl: firmer split between app/management clusters This commit ensures that management cluster and app cluster setup are kept distinct, and introduces seperate service accounts for the two. Furthermore, all RBAC objects are labled with the domain that pertain to -- management or application. This helps to keep things straight in a combo cluster, as in development.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Right now our client store uses a Secrets informer generated from a kubeInformerFactory configured to list things for the entire cluster. This is more power than we need. Instead, that kubeInformerFactory should be filtered to only look at the Shipper namespace.
Once this is done, our RBAC configuration should restrict Shipper's access to secrets to just the Shipper namespace.
This is part of a wider topic about changing Shipper to be a good multi-tenant citizen (other work in this area includes making Clusters a namespaced object instead of cluster scoped, and somehow indicating to Shipper the set of namespaces it should manage on startup).
The text was updated successfully, but these errors were encountered: