(In reply to Simon Sapin (:SimonSapin) from comment #7) > Is docker-worker affected at all? :wcosta manages the AMIs used by the aws-provisioner-v1/servo-docker-worker and aws-provisioner-v1/servo-docker-untrusted worker types. The equivalent docker-worker bug to this one is bug 1375194, but the work to update docker-worker to support getting secrets from taskcluster-secrets is not yet done, and blocks that bug. So that will come at some point later. > I apparently do not have scopes to access worker-type:aws-provisioner-v1/servo-* secrets. I've granted worker type secret read/write access for servo admins in role [project:servo:grants/secrets](https://tools.taskcluster.net/auth/roles/project%3Aservo%3Agrants%2Fsecrets) for this. Let me know if this resolves the issue for you, or if you are still having problems with access. > I assume I don’t need them for AWS worker types as the provisioner will presumably manage by itself to bootstrap an appropriate client ID in new instances. That is correct - see role [worker-type:*](project%3Aservo%3Agrants%2Fsecrets). > However, what is the way forward for non-AWS workers? This change only affects AWS workers, since we currently only have worker type definitions for AWS workers. > My scripts for provisioning them (namely for the proj-servo/macos and proj-servo/docker-worker-kvm worker types) are currently accessing the worker type definition of aws-provisioner-v1/servo-win2016 in order to find appropriate livelog secrets. I would recommend that they either get the secret from the taskcluster secrets service (worker-type:aws-provisioner-v1/servo-win2016) or creating a new taskcluster secret with livelog secret. As part of the start up sequence of the worker, before running generic-worker, a call could be made to the taskcluster secrets service to retrieve the value, and update the generic-worker.config file. > I think I have access to create a staging worker type myself. I’ll work on migrating our Windows AMI to generic-worker 13. Many thanks! Let me know if you get stuck.
Bug 1375182 Comment 8 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Simon Sapin (:SimonSapin) from comment #7) > Is docker-worker affected at all? :wcosta manages the AMIs used by the aws-provisioner-v1/servo-docker-worker and aws-provisioner-v1/servo-docker-untrusted worker types. The equivalent docker-worker bug to this one is bug 1375194, but the work to update docker-worker to support getting secrets from taskcluster-secrets is not yet done, and blocks that bug. So that will come at some point later. > I apparently do not have scopes to access worker-type:aws-provisioner-v1/servo-* secrets. I've granted worker type secret read/write access for servo admins in role [project:servo:grants/secrets](https://tools.taskcluster.net/auth/roles/project%3Aservo%3Agrants%2Fsecrets) for this. Let me know if this resolves the issue for you, or if you are still having problems with access. > I assume I don’t need them for AWS worker types as the provisioner will presumably manage by itself to bootstrap an appropriate client ID in new instances. That is correct - see role [worker-type:*](https://tools.taskcluster.net/auth/roles/worker-type%3A*). > However, what is the way forward for non-AWS workers? This change only affects AWS workers, since we currently only have worker type definitions for AWS workers. > My scripts for provisioning them (namely for the proj-servo/macos and proj-servo/docker-worker-kvm worker types) are currently accessing the worker type definition of aws-provisioner-v1/servo-win2016 in order to find appropriate livelog secrets. I would recommend that they either get the secret from the taskcluster secrets service (worker-type:aws-provisioner-v1/servo-win2016) or creating a new taskcluster secret with livelog secret. As part of the start up sequence of the worker, before running generic-worker, a call could be made to the taskcluster secrets service to retrieve the value, and update the generic-worker.config file. > I think I have access to create a staging worker type myself. I’ll work on migrating our Windows AMI to generic-worker 13. Many thanks! Let me know if you get stuck.
(In reply to Simon Sapin (:SimonSapin) from comment #7) > Is docker-worker affected at all? :wcosta manages the AMIs used by the aws-provisioner-v1/servo-docker-worker and aws-provisioner-v1/servo-docker-untrusted worker types. The equivalent docker-worker bug to this one is bug 1375194, but the work to update docker-worker to support getting secrets from taskcluster-secrets is not yet done, and blocks that bug. So that will come at some point later. > I apparently do not have scopes to access worker-type:aws-provisioner-v1/servo-* secrets. I've granted worker type secret read/write access for servo admins in role [project:servo:grants/secrets](https://tools.taskcluster.net/auth/roles/project%3Aservo%3Agrants%2Fsecrets) for this. Let me know if this resolves the issue for you, or if you are still having problems with access. > I assume I don’t need them for AWS worker types as the provisioner will presumably manage by itself to bootstrap an appropriate client ID in new instances. That is correct - see role [worker-type:*](https://tools.taskcluster.net/auth/roles/worker-type%3A*). > However, what is the way forward for non-AWS workers? This change only affects AWS workers, since we currently only have worker type definitions for AWS workers. > My scripts for provisioning them (namely for the proj-servo/macos and proj-servo/docker-worker-kvm worker types) are currently accessing the worker type definition of aws-provisioner-v1/servo-win2016 in order to find appropriate livelog secrets. I would recommend that they either get the secret from [secret worker-type:aws-provisioner-v1/servo-win2016](https://tools.taskcluster.net/secrets/worker-type%3Aaws-provisioner-v1%2Fservo-win2016) or creating a new taskcluster secret or secrets. Note, the secret-fetching from the taskcluster-secrets service is only activated if the --configure-for-aws option is set when running the generic-worker, although, we could change that to be called if the required secrets are not available locally. Then you could create e.g. the secret `worker-type:proj-servo/macos` for your mac workers (assuming they run generic-worker). Note, in 2019 H1 we are looking to replace docker-worker with generic-worker, so life should get simpler once we only have one worker architecture to worry about. Please let me know if you'd like us to provide support for bootstrapping non-aws workers with secrets from taskcluster-secrets service directly inside generic-worker. > I think I have access to create a staging worker type myself. I’ll work on migrating our Windows AMI to generic-worker 13. Many thanks! Let me know if you get stuck.
(In reply to Simon Sapin (:SimonSapin) from comment #7) > Is docker-worker affected at all? :wcosta manages the AMIs used by the aws-provisioner-v1/servo-docker-worker and aws-provisioner-v1/servo-docker-untrusted worker types. The equivalent docker-worker bug to this one is bug 1375194, but the work to update docker-worker to support getting secrets from taskcluster-secrets is not yet done, and blocks that bug. So that will come at some point later. > I apparently do not have scopes to access worker-type:aws-provisioner-v1/servo-* secrets. Apologies, I had forgotten to do this. I've since granted worker type secret read and write access for servo admins in role [project:servo:grants/secrets](https://tools.taskcluster.net/auth/roles/project%3Aservo%3Agrants%2Fsecrets) for this. Let me know if this resolves the issue for you, or if you are still having problems with access. > I assume I don’t need them for AWS worker types as the provisioner will presumably manage by itself to bootstrap an appropriate client ID in new instances. That is correct - see role [worker-type:*](https://tools.taskcluster.net/auth/roles/worker-type%3A*). > However, what is the way forward for non-AWS workers? This change only affects AWS workers, since we currently only have worker type definitions for AWS workers. > My scripts for provisioning them (namely for the proj-servo/macos and proj-servo/docker-worker-kvm worker types) are currently accessing the worker type definition of aws-provisioner-v1/servo-win2016 in order to find appropriate livelog secrets. I would recommend that they either get the secret from [secret worker-type:aws-provisioner-v1/servo-win2016](https://tools.taskcluster.net/secrets/worker-type%3Aaws-provisioner-v1%2Fservo-win2016) or creating a new taskcluster secret or secrets. Note, the secret-fetching from the taskcluster-secrets service is only activated if the --configure-for-aws option is set when running the generic-worker, although, we could change that to be called if the required secrets are not available locally. Then you could create e.g. the secret `worker-type:proj-servo/macos` for your mac workers (assuming they run generic-worker). Note, in 2019 H1 we are looking to replace docker-worker with generic-worker, so life should get simpler once we only have one worker architecture to worry about. Please let me know if you'd like us to provide support for bootstrapping non-aws workers with secrets from taskcluster-secrets service directly inside generic-worker. > I think I have access to create a staging worker type myself. I’ll work on migrating our Windows AMI to generic-worker 13. Many thanks! Let me know if you get stuck.
(In reply to Simon Sapin (:SimonSapin) from comment #7) > Is docker-worker affected at all? :wcosta manages the AMIs used by the aws-provisioner-v1/servo-docker-worker and aws-provisioner-v1/servo-docker-untrusted worker types. The equivalent docker-worker bug to this one is bug 1375194, but the work to update docker-worker to support getting secrets from taskcluster-secrets is not yet done, and blocks that bug. So that will come at some point later. > I apparently do not have scopes to access worker-type:aws-provisioner-v1/servo-* secrets. Apologies, I had forgotten to do this. I've since granted worker type secret read and write access for servo admins in role [project:servo:grants/secrets](https://tools.taskcluster.net/auth/roles/project%3Aservo%3Agrants%2Fsecrets) for this. Let me know if this resolves the issue for you, or if you are still having problems with access. > I assume I don’t need them for AWS worker types as the provisioner will presumably manage by itself to bootstrap an appropriate client ID in new instances. That is correct - see role [worker-type:*](https://tools.taskcluster.net/auth/roles/worker-type%3A*). > However, what is the way forward for non-AWS workers? This change only affects AWS workers, since we currently only have worker type definitions for AWS workers. > My scripts for provisioning them (namely for the proj-servo/macos and proj-servo/docker-worker-kvm worker types) are currently accessing the worker type definition of aws-provisioner-v1/servo-win2016 in order to find appropriate livelog secrets. I would recommend that they either get the secret from [secret worker-type:aws-provisioner-v1/servo-win2016](https://tools.taskcluster.net/secrets/worker-type%3Aaws-provisioner-v1%2Fservo-win2016) or creating a new taskcluster secret or secrets. Note, the secret-fetching from the taskcluster-secrets service is only activated if the --configure-for-aws option is set when running the generic-worker, although, we could change that to be called if the required secrets are not available locally. Then you could create e.g. the secret `worker-type:proj-servo/macos` for your mac workers (assuming they run generic-worker). Note, in 2019 H1 we are looking to replace docker-worker with generic-worker, so life should get simpler once we only have one worker architecture to worry about. Please let me know if you'd like us to provide support for bootstrapping non-aws workers with secrets from taskcluster-secrets service directly inside generic-worker. Note, the primary motivation of this change wasn't to get secrets off the workers, but to get secrets out of the AWS worker type definitions. However, if getting the secrets off the worker is also preferred, we can make this a more generic feature that works also on statically provisioned workers. > I think I have access to create a staging worker type myself. I’ll work on migrating our Windows AMI to generic-worker 13. Many thanks! Let me know if you get stuck.
(In reply to Simon Sapin (:SimonSapin) from comment #7) > Is docker-worker affected at all? :wcosta manages the AMIs used by the aws-provisioner-v1/servo-docker-worker and aws-provisioner-v1/servo-docker-untrusted worker types. The equivalent docker-worker bug to this one is bug 1375194, but the work to update docker-worker to support getting secrets from taskcluster-secrets is not yet done, and blocks that bug. So that will come at some point later. > I apparently do not have scopes to access worker-type:aws-provisioner-v1/servo-* secrets. Apologies, I had forgotten to do this. I've since granted worker type secret read and write access for servo admins in role [project:servo:grants/secrets](https://tools.taskcluster.net/auth/roles/project%3Aservo%3Agrants%2Fsecrets) for this. Let me know if this resolves the issue for you, or if you are still having problems with access. > I assume I don’t need them for AWS worker types as the provisioner will presumably manage by itself to bootstrap an appropriate client ID in new instances. That is correct - see role [worker-type:*](https://tools.taskcluster.net/auth/roles/worker-type%3A*). > However, what is the way forward for non-AWS workers? This change only affects AWS workers, since the motivation of the change is to get secrets out of the AWS worker type definitions. One positive side effect of this is that it also gets secrets off the workers too, so we could look at making this functionality available generally, so that any workers can bootstrap their config via the taskcluster-secrets service, but that currently isn't the case. > My scripts for provisioning them (namely for the proj-servo/macos and proj-servo/docker-worker-kvm worker types) are currently accessing the worker type definition of aws-provisioner-v1/servo-win2016 in order to find appropriate livelog secrets. I would recommend that they either get the secret from [secret worker-type:aws-provisioner-v1/servo-win2016](https://tools.taskcluster.net/secrets/worker-type%3Aaws-provisioner-v1%2Fservo-win2016) or creating a new taskcluster secret or secrets. Note, the secret-fetching from the taskcluster-secrets service is only activated if the --configure-for-aws option is set when running the generic-worker. If we made this feature available outside of AWS, it would be possible e.g. to bootstrap the `proj-servo/macos` workers secret config from taskcluster secret `worker-type:proj-servo/macos` (assuming they run generic-worker). Let me know if this is desirable, or if you are happy to bootstrap the config outside of generic-worker, before it runs. As noted above, the primary motivation of this change wasn't to get secrets off the workers, but to get secrets out of the AWS worker type definitions. However, if this is desirable, we can look into it. > I think I have access to create a staging worker type myself. I’ll work on migrating our Windows AMI to generic-worker 13. Many thanks! Let me know if you get stuck.
(In reply to Simon Sapin (:SimonSapin) from comment #7) > Is docker-worker affected at all? :wcosta manages the AMIs used by the aws-provisioner-v1/servo-docker-worker and aws-provisioner-v1/servo-docker-untrusted worker types. The equivalent docker-worker bug to this one is bug 1375194, but the work to update docker-worker to support getting secrets from taskcluster-secrets is not yet done, and blocks that bug. So that will come at some point later. > I apparently do not have scopes to access worker-type:aws-provisioner-v1/servo-* secrets. Apologies, I had forgotten to do this. I've since granted worker type secret read and write access for servo admins in role [project:servo:grants/secrets](https://tools.taskcluster.net/auth/roles/project%3Aservo%3Agrants%2Fsecrets) for this. Let me know if this resolves the issue for you, or if you are still having problems with access. > I assume I don’t need them for AWS worker types as the provisioner will presumably manage by itself to bootstrap an appropriate client ID in new instances. That is correct - see role [worker-type:*](https://tools.taskcluster.net/auth/roles/worker-type%3A*). > However, what is the way forward for non-AWS workers? This change only affects AWS workers, since the motivation of the change is to get secrets out of the AWS worker type definitions. One positive side effect of this is that it also gets secrets off the workers too, so we could look at making this functionality available generally, so that any workers can bootstrap their config via the taskcluster-secrets service, but that currently isn't the case. > My scripts for provisioning them (namely for the proj-servo/macos and proj-servo/docker-worker-kvm worker types) are currently accessing the worker type definition of aws-provisioner-v1/servo-win2016 in order to find appropriate livelog secrets. I would recommend that they either get the secret from [secret worker-type:aws-provisioner-v1/servo-win2016](https://tools.taskcluster.net/secrets/worker-type%3Aaws-provisioner-v1%2Fservo-win2016) or creating a new taskcluster secret or secrets specifically for those workers. Note, the secret-fetching from the taskcluster-secrets service is only activated if the --configure-for-aws option is set when running the generic-worker. If we made this feature available outside of AWS, it would be possible e.g. to bootstrap the `proj-servo/macos` workers secret config from taskcluster secret `worker-type:proj-servo/macos` (assuming they run generic-worker). Let me know if this is desirable, or if you are happy to bootstrap the config outside of generic-worker, before it runs. As noted above, the primary motivation of this change wasn't to get secrets off the workers, but to get secrets out of the AWS worker type definitions. However, if this is desirable, we can look into it. > I think I have access to create a staging worker type myself. I’ll work on migrating our Windows AMI to generic-worker 13. Many thanks! Let me know if you get stuck.
(In reply to Simon Sapin (:SimonSapin) from comment #7) > Is docker-worker affected at all? :wcosta manages the AMIs used by the aws-provisioner-v1/servo-docker-worker and aws-provisioner-v1/servo-docker-untrusted worker types. The equivalent docker-worker bug to this one is bug 1375194, but the work to update docker-worker to support getting secrets from taskcluster-secrets is not yet done, and blocks that bug. So that will come at some point later. > I apparently do not have scopes to access worker-type:aws-provisioner-v1/servo-* secrets. Apologies, I had forgotten to do this. I've since granted worker type secret read and write access for servo admins in role [project:servo:grants/secrets](https://tools.taskcluster.net/auth/roles/project%3Aservo%3Agrants%2Fsecrets) for this. Let me know if this resolves the issue for you, or if you are still having problems with access. > I assume I don’t need them for AWS worker types as the provisioner will presumably manage by itself to bootstrap an appropriate client ID in new instances. That is correct - see role [worker-type:*](https://tools.taskcluster.net/auth/roles/worker-type%3A*). > However, what is the way forward for non-AWS workers? This change only affects AWS workers, since the motivation of the change is to get secrets out of the AWS worker type definitions. One positive side effect of this is that it also gets secrets off the workers too, so we could look at making this functionality available generally, so that any workers can bootstrap their config via the taskcluster-secrets service, but that currently isn't the case. > My scripts for provisioning them (namely for the proj-servo/macos and proj-servo/docker-worker-kvm worker types) are currently accessing the worker type definition of `aws-provisioner-v1/servo-win2016` in order to find appropriate livelog secrets. I would recommend that they either get the secret from [secret worker-type:aws-provisioner-v1/servo-win2016](https://tools.taskcluster.net/secrets/worker-type%3Aaws-provisioner-v1%2Fservo-win2016) or creating a new taskcluster secret or secrets specifically for those workers. Note, the secret-fetching from the taskcluster-secrets service is only activated if the `--configure-for-aws` option is set when running the generic-worker. If we made this feature available outside of AWS, it would be possible e.g. to bootstrap the `proj-servo/macos` workers secret config from taskcluster secret `worker-type:proj-servo/macos` (assuming they run generic-worker). Let me know if this is desirable, or if you are happy to bootstrap the config outside of generic-worker, before it runs. As noted above, the primary motivation of this change wasn't to get secrets off the workers, but to get secrets out of the AWS worker type definitions. However, if this is desirable, we can look into it. > I think I have access to create a staging worker type myself. I’ll work on migrating our Windows AMI to generic-worker 13. Many thanks! Let me know if you get stuck.
(In reply to Simon Sapin (:SimonSapin) from comment #7) > Is docker-worker affected at all? :wcosta manages the AMIs used by the aws-provisioner-v1/servo-docker-worker and aws-provisioner-v1/servo-docker-untrusted worker types. The docker-worker secrets have also been copied too. The changes to docker-worker to be able to read the secrets from the secrets service is tracked in bug 1375190, and rolling that out to existing worker types is bug 1375192. > I apparently do not have scopes to access worker-type:aws-provisioner-v1/servo-* secrets. Apologies, I had forgotten to do this. I've since granted worker type secret read and write access for servo admins in role [project:servo:grants/secrets](https://tools.taskcluster.net/auth/roles/project%3Aservo%3Agrants%2Fsecrets) for this. Let me know if this resolves the issue for you, or if you are still having problems with access. > I assume I don’t need them for AWS worker types as the provisioner will presumably manage by itself to bootstrap an appropriate client ID in new instances. That is correct - see role [worker-type:*](https://tools.taskcluster.net/auth/roles/worker-type%3A*). > However, what is the way forward for non-AWS workers? This change only affects AWS workers, since the motivation of the change is to get secrets out of the AWS worker type definitions. One positive side effect of this is that it also gets secrets off the workers too, so we could look at making this functionality available generally, so that any workers can bootstrap their config via the taskcluster-secrets service, but that currently isn't the case. > My scripts for provisioning them (namely for the proj-servo/macos and proj-servo/docker-worker-kvm worker types) are currently accessing the worker type definition of `aws-provisioner-v1/servo-win2016` in order to find appropriate livelog secrets. I would recommend that they either get the secret from [secret worker-type:aws-provisioner-v1/servo-win2016](https://tools.taskcluster.net/secrets/worker-type%3Aaws-provisioner-v1%2Fservo-win2016) or creating a new taskcluster secret or secrets specifically for those workers. Note, the secret-fetching from the taskcluster-secrets service is only activated if the `--configure-for-aws` option is set when running the generic-worker. If we made this feature available outside of AWS, it would be possible e.g. to bootstrap the `proj-servo/macos` workers secret config from taskcluster secret `worker-type:proj-servo/macos` (assuming they run generic-worker). Let me know if this is desirable, or if you are happy to bootstrap the config outside of generic-worker, before it runs. As noted above, the primary motivation of this change wasn't to get secrets off the workers, but to get secrets out of the AWS worker type definitions. However, if this is desirable, we can look into it. > I think I have access to create a staging worker type myself. I’ll work on migrating our Windows AMI to generic-worker 13. Many thanks! Let me know if you get stuck.
(In reply to Simon Sapin (:SimonSapin) from comment #7) > Is docker-worker affected at all? :wcosta manages the AMIs used by the aws-provisioner-v1/servo-docker-worker and aws-provisioner-v1/servo-docker-untrusted worker types. The docker-worker secrets were also copied to the secrets service in the attached go program. The code changes to docker-worker to be able to read the secrets from the secrets service is tracked in bug 1375190, and rolling that out to existing docker-worker AWS worker types is tracked in bug 1375192. > I apparently do not have scopes to access worker-type:aws-provisioner-v1/servo-* secrets. Apologies, I had forgotten to do this. I've since granted worker type secret read and write access for servo admins in role [project:servo:grants/secrets](https://tools.taskcluster.net/auth/roles/project%3Aservo%3Agrants%2Fsecrets) for this. Let me know if this resolves the issue for you, or if you are still having problems with access. > I assume I don’t need them for AWS worker types as the provisioner will presumably manage by itself to bootstrap an appropriate client ID in new instances. That is correct - see role [worker-type:*](https://tools.taskcluster.net/auth/roles/worker-type%3A*). > However, what is the way forward for non-AWS workers? This change only affects AWS workers, since the motivation of the change is to get secrets out of the AWS worker type definitions. One positive side effect of this is that it also gets secrets off the workers too, so we could look at making this functionality available generally, so that any workers can bootstrap their config via the taskcluster-secrets service, but that currently isn't the case. > My scripts for provisioning them (namely for the proj-servo/macos and proj-servo/docker-worker-kvm worker types) are currently accessing the worker type definition of `aws-provisioner-v1/servo-win2016` in order to find appropriate livelog secrets. I would recommend that they either get the secret from [secret worker-type:aws-provisioner-v1/servo-win2016](https://tools.taskcluster.net/secrets/worker-type%3Aaws-provisioner-v1%2Fservo-win2016) or creating a new taskcluster secret or secrets specifically for those workers. Note, the secret-fetching from the taskcluster-secrets service is only activated if the `--configure-for-aws` option is set when running the generic-worker. If we made this feature available outside of AWS, it would be possible e.g. to bootstrap the `proj-servo/macos` workers secret config from taskcluster secret `worker-type:proj-servo/macos` (assuming they run generic-worker). Let me know if this is desirable, or if you are happy to bootstrap the config outside of generic-worker, before it runs. As noted above, the primary motivation of this change wasn't to get secrets off the workers, but to get secrets out of the AWS worker type definitions. However, if this is desirable, we can look into it. > I think I have access to create a staging worker type myself. I’ll work on migrating our Windows AMI to generic-worker 13. Many thanks! Let me know if you get stuck.