Re: Default Service Account Names
On Mon, Jul 17, 2017 at 10:07 AM, Jordan Liggitt wrote: > An export should include custom image pull or push secrets added to the > namespace and included in the service account's imagePullSecrets list. Jordan could you clarify, I noticed this: https://github.com/kubernetes/kubernetes/blob/master/pkg/registry/core/secret/strategy.go#L79 Would it be safe to apply that logic to our exports, skip any secrets of type kubernetes.io/service-account-token, or tied to a service account by it's UID. However make sure we include any custom image pull secrets (which do not appear to be tied by UID in my testing here), and that they remain associated with the correct SAs on the other side. Strangely I can't trigger that condition linked above with kubectl/oc get --export on a serviceaccounttoken secret, not sure why, maybe it doesn't hit this code, but it does seem to be stripping cluster info from the yaml output. ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
Re: Default Service Account Names
On Mon, Jul 17, 2017 at 10:07 AM, Jordan Liggitt wrote: > An export should include custom image pull or push secrets added to the > namespace and included in the service account's imagePullSecrets list. I will change approach here to make sure we include all service accounts and their associated secrets, with some potential merge logic on import. Somewhat leads into another discussion we're having, but is it reasonable to recreate the project separately (potentially with a different name in another cluster), then import objects into it, rather than trying to include the project and rolebinding info in the template/objectlist itself? It felt safer to do this when we're talking about long term archival, differing OpenShift versions, and moving clusters/projects. Thanks for the feedback all. > > On Mon, Jul 17, 2017 at 8:04 AM, Clayton Coleman > wrote: >> >> Also, if you exported a set of service accounts, assumption is that a new >> one can be added at any time (to all namespaces), which means you already >> have to handle merging them when you restore. >> >> On Mon, Jul 17, 2017 at 7:45 AM, Michail Kargakis >> wrote: >>> >>> What if someone has granted extra access to one of the default service >>> accounts? Custom deployments (and I imagine builds too) >>> may not work w/o granting extra permissions, depending on what the >>> deployer/builder is actually doing. >>> >>> On Mon, Jul 17, 2017 at 1:31 PM, Devan Goodwin >>> wrote: I've been working on project archival for online, with regard to service accounts we may need to export those created manually by the user, and skip those created automatically by OpenShift when we created the project. There does not appear to be any information on those service accounts to identify that it was automatically created by OpenShift: - apiVersion: v1 imagePullSecrets: - name: deployer-dockercfg-t2ckf kind: ServiceAccount metadata: creationTimestamp: 2017-07-12T14:48:19Z name: deployer namespace: myproject Is assuming the service accounts with names "builder", "deployer", and "default" a stable set we could count on for skipping during an export? Would it be acceptable to start adding an annotation to these service accounts similar to what we do for secrets that are attached to those SAs? kind: Secret metadata: annotations: kubernetes.io/created-by: openshift.io/create-dockercfg-secrets Perhaps in this case "openshift.io/default-service-accounts"? (suggestions welcome) If so, is there any established precedent for migrating pre-existing builder/deployer/default SAs to add the annotation during an upgrade? Thanks! Devan ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >>> >>> >>> >>> ___ >>> dev mailing list >>> dev@lists.openshift.redhat.com >>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >>> >> >> >> ___ >> dev mailing list >> dev@lists.openshift.redhat.com >> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >> > > > ___ > dev mailing list > dev@lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev > ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
Re: Default Service Account Names
An export should include custom image pull or push secrets added to the namespace and included in the service account's imagePullSecrets list. On Mon, Jul 17, 2017 at 8:04 AM, Clayton Coleman wrote: > Also, if you exported a set of service accounts, assumption is that a new > one can be added at any time (to all namespaces), which means you already > have to handle merging them when you restore. > > On Mon, Jul 17, 2017 at 7:45 AM, Michail Kargakis > wrote: > >> What if someone has granted extra access to one of the default service >> accounts? Custom deployments (and I imagine builds too) >> may not work w/o granting extra permissions, depending on what the >> deployer/builder is actually doing. >> >> On Mon, Jul 17, 2017 at 1:31 PM, Devan Goodwin >> wrote: >> >>> I've been working on project archival for online, with regard to >>> service accounts we may need to export those created manually by the >>> user, and skip those created automatically by OpenShift when we >>> created the project. >>> >>> There does not appear to be any information on those service accounts >>> to identify that it was automatically created by OpenShift: >>> >>> - apiVersion: v1 >>> imagePullSecrets: >>> - name: deployer-dockercfg-t2ckf >>> kind: ServiceAccount >>> metadata: >>> creationTimestamp: 2017-07-12T14:48:19Z >>> name: deployer >>> namespace: myproject >>> >>> >>> Is assuming the service accounts with names "builder", "deployer", and >>> "default" a stable set we could count on for skipping during an >>> export? >>> >>> Would it be acceptable to start adding an annotation to these service >>> accounts similar to what we do for secrets that are attached to those >>> SAs? >>> >>> kind: Secret >>> metadata: >>> annotations: >>> kubernetes.io/created-by: openshift.io/create-dockercfg-secrets >>> >>> Perhaps in this case "openshift.io/default-service-accounts"? >>> (suggestions welcome) >>> >>> If so, is there any established precedent for migrating pre-existing >>> builder/deployer/default SAs to add the annotation during an upgrade? >>> >>> Thanks! >>> >>> Devan >>> >>> ___ >>> dev mailing list >>> dev@lists.openshift.redhat.com >>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >>> >> >> >> ___ >> dev mailing list >> dev@lists.openshift.redhat.com >> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >> >> > > ___ > dev mailing list > dev@lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev > > ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
Re: Default Service Account Names
Also, if you exported a set of service accounts, assumption is that a new one can be added at any time (to all namespaces), which means you already have to handle merging them when you restore. On Mon, Jul 17, 2017 at 7:45 AM, Michail Kargakis wrote: > What if someone has granted extra access to one of the default service > accounts? Custom deployments (and I imagine builds too) > may not work w/o granting extra permissions, depending on what the > deployer/builder is actually doing. > > On Mon, Jul 17, 2017 at 1:31 PM, Devan Goodwin > wrote: > >> I've been working on project archival for online, with regard to >> service accounts we may need to export those created manually by the >> user, and skip those created automatically by OpenShift when we >> created the project. >> >> There does not appear to be any information on those service accounts >> to identify that it was automatically created by OpenShift: >> >> - apiVersion: v1 >> imagePullSecrets: >> - name: deployer-dockercfg-t2ckf >> kind: ServiceAccount >> metadata: >> creationTimestamp: 2017-07-12T14:48:19Z >> name: deployer >> namespace: myproject >> >> >> Is assuming the service accounts with names "builder", "deployer", and >> "default" a stable set we could count on for skipping during an >> export? >> >> Would it be acceptable to start adding an annotation to these service >> accounts similar to what we do for secrets that are attached to those >> SAs? >> >> kind: Secret >> metadata: >> annotations: >> kubernetes.io/created-by: openshift.io/create-dockercfg-secrets >> >> Perhaps in this case "openshift.io/default-service-accounts"? >> (suggestions welcome) >> >> If so, is there any established precedent for migrating pre-existing >> builder/deployer/default SAs to add the annotation during an upgrade? >> >> Thanks! >> >> Devan >> >> ___ >> dev mailing list >> dev@lists.openshift.redhat.com >> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >> > > > ___ > dev mailing list > dev@lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev > > ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
Re: Default Service Account Names
What if someone has granted extra access to one of the default service accounts? Custom deployments (and I imagine builds too) may not work w/o granting extra permissions, depending on what the deployer/builder is actually doing. On Mon, Jul 17, 2017 at 1:31 PM, Devan Goodwin wrote: > I've been working on project archival for online, with regard to > service accounts we may need to export those created manually by the > user, and skip those created automatically by OpenShift when we > created the project. > > There does not appear to be any information on those service accounts > to identify that it was automatically created by OpenShift: > > - apiVersion: v1 > imagePullSecrets: > - name: deployer-dockercfg-t2ckf > kind: ServiceAccount > metadata: > creationTimestamp: 2017-07-12T14:48:19Z > name: deployer > namespace: myproject > > > Is assuming the service accounts with names "builder", "deployer", and > "default" a stable set we could count on for skipping during an > export? > > Would it be acceptable to start adding an annotation to these service > accounts similar to what we do for secrets that are attached to those > SAs? > > kind: Secret > metadata: > annotations: > kubernetes.io/created-by: openshift.io/create-dockercfg-secrets > > Perhaps in this case "openshift.io/default-service-accounts"? > (suggestions welcome) > > If so, is there any established precedent for migrating pre-existing > builder/deployer/default SAs to add the annotation during an upgrade? > > Thanks! > > Devan > > ___ > dev mailing list > dev@lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev > ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
Re: Default Service Account Names
Asked another way - why not export them? On Mon, Jul 17, 2017 at 7:31 AM, Devan Goodwin wrote: > I've been working on project archival for online, with regard to > service accounts we may need to export those created manually by the > user, and skip those created automatically by OpenShift when we > created the project. > > There does not appear to be any information on those service accounts > to identify that it was automatically created by OpenShift: > > - apiVersion: v1 > imagePullSecrets: > - name: deployer-dockercfg-t2ckf > kind: ServiceAccount > metadata: > creationTimestamp: 2017-07-12T14:48:19Z > name: deployer > namespace: myproject > > > Is assuming the service accounts with names "builder", "deployer", and > "default" a stable set we could count on for skipping during an > export? > > Would it be acceptable to start adding an annotation to these service > accounts similar to what we do for secrets that are attached to those > SAs? > > kind: Secret > metadata: > annotations: > kubernetes.io/created-by: openshift.io/create-dockercfg-secrets > > Perhaps in this case "openshift.io/default-service-accounts"? > (suggestions welcome) > > If so, is there any established precedent for migrating pre-existing > builder/deployer/default SAs to add the annotation during an upgrade? > > Thanks! > > Devan > > ___ > dev mailing list > dev@lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev > ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
Default Service Account Names
I've been working on project archival for online, with regard to service accounts we may need to export those created manually by the user, and skip those created automatically by OpenShift when we created the project. There does not appear to be any information on those service accounts to identify that it was automatically created by OpenShift: - apiVersion: v1 imagePullSecrets: - name: deployer-dockercfg-t2ckf kind: ServiceAccount metadata: creationTimestamp: 2017-07-12T14:48:19Z name: deployer namespace: myproject Is assuming the service accounts with names "builder", "deployer", and "default" a stable set we could count on for skipping during an export? Would it be acceptable to start adding an annotation to these service accounts similar to what we do for secrets that are attached to those SAs? kind: Secret metadata: annotations: kubernetes.io/created-by: openshift.io/create-dockercfg-secrets Perhaps in this case "openshift.io/default-service-accounts"? (suggestions welcome) If so, is there any established precedent for migrating pre-existing builder/deployer/default SAs to add the annotation during an upgrade? Thanks! Devan ___ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev