Awesome work Jeremy! Thank you and the team for keeping this moving forward.
1. Create/Read/Update/Delete delivery services
* Agree
2. Manage DS regexes
* Many customers CNAME to us, so we need this to be configurable at some
level
* I think we should restrict users when entering additional host names
to explicit full domain names, ie not allow them to enter regex matching
patterns
* This restricts the overlap potential and allows for collision checks
against existing explicit names and regexes
* Allow internal staff to enter regex matching patterns
3. Manage DS SSL keys (if applicable)
* Agree, let users manage keys
* Would like to allow users to upload their own certs as well
4. Manage DS URL sig keys (if applicable)
1. We are making the “sig-anchor” a configurable option in the next release
so they need to be able to manipulate this
2. We also need to give them access to manipulate the URL signing bypass
parameters which are regex values, we typically bypass signing for
crossdomain.xml and clientaccesspolicy.xml or for a particular directory like
where they store their thumbnails.
5. Manage DS URI signing keys (if applicable)
1. Agree we should let them manage the keys
6. Manage DS targets (steering* only)
1. Don’t have an opinion on this, haven’t used it.
7. Creating DS invalidate content jobs
1. I want to eventually add purge or true delete as an option but otherwise
this is good.
8. Manage DS / cache assignments
1. Agree, should only be controlled by CDN operations
Ryan Durfey M | 303-524-5099
CDN Support (24x7): 866-405-2993 or
cdn_supp...@comcast.com<mailto:cdn_supp...@comcast.com>
From: Jeremy Mitchell <mitchell...@apache.org>
Reply-To: "dev@trafficcontrol.incubator.apache.org"
<dev@trafficcontrol.incubator.apache.org>
Date: Friday, February 2, 2018 at 1:50 PM
To: "dev@trafficcontrol.incubator.apache.org"
<dev@trafficcontrol.incubator.apache.org>
Subject: Delivery Service Self-Service
As we move in the direction of self-service, there are a few obstacles that
need to be overcome and I'd like to discuss them a bit so grab a cup of
coffee...
When I say self-service, what I really mean is "delivery service
self-service" or the ability to manage your own delivery services (as
dictated by tenancy) and everything related to those delivery services.
"Everything" includes the following (afaik):
1. Create/Read/Update/Delete delivery services
2. Manage DS regexes
3. Manage DS SSL keys (if applicable)
4. Manage DS URL sig keys (if applicable)
5. Manage DS URI signing keys (if applicable)
6. Manage DS targets (steering* only)
7. Creating DS invalidate content jobs
8. Manage DS / cache assignments
If you can't do 1-7 yourself, it's not really self-service is it? #8 is
debatable.
I'll discuss each one:
1. Create/Read/Update/Delete delivery services
Ideally, you could CRUD your own delivery services but our system has some
limitations.
A) Our CDN is not properly insulated from bad DS configurations. If a user
enters a bad value, bad things could potentially happen to a cache or worse
the whole CDN.
B) Certain DS configuration changes requires queue updates and/or snapshot
for the change to take effect. We're not ready (nor will we ever be
probably) to let normal users queue updates and/or snapshot.
So in the interim, we're working on the ability to allow normal users to
create "delivery service requests" to facilitate creating/updating/deleting
a delivery service. These "requests" will have to be reviewed/fulfilled by
a higher level user (Ops or Admin) who can then queue/snapshot if needed.
2. Manage DS regexes
Here's an explanation of this:
http://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/using.html#delivery-service-regexp
Currently, this requires the Operations role and for good reason. The
danger here involves the risk of a normal user entering a bad regex. For
example, it is my understanding that the regex in position zero needs to
always follow this format: .*\.foo\..*.
Maybe with some better API validation we could let normal users manage DS
regexes....or maybe these end up going away in favor of something
better/easier...not sure yet...
3. Manage DS SSL keys
SSL keys are only applicable where protocol > 0 (HTTPS, HTTP AND HTTPS, or
HTTP TO HTTPS) and currently, to manage them requires the Admin role. Why?
I'm not sure. Is their harm in letting normal users manage their own SSL
keys?
4. Manage DS URL sig keys
URL sig keys (
http://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/using.html#generate-url-sig-keys)
are only applicable where signingAlgorithm = 'url_sig' and currently, to
manage them requires NO role apparently (only a tenancy check is
performed). This is the 1st one on the list that a "normal" user can do
currently.
5. Manage DS URI signing keys
URI signing keys are only applicable where signingAlgorithm = 'uri_signing'
and currently, to manage DS URI signing keys requires the Admin role. Is it
necessary to restrict this functionality to Admins only or can we allow
normal users to mange URI signing keys for their DS's?
6. Manage DS targets (steering* only)
Here's an explanation of this:
http://traffic-control-cdn.readthedocs.io/en/latest/admin/quick_howto/steering.html?highlight=steering
Currently, to manage DS targets requires the Admin or Steering role. Is
there any harm in allowing a normal user to "steer" their delivery service
to another delivery service as long as the target delivery service falls in
their tenancy?
7. Creating DS invalidate content jobs
http://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/using.html?highlight=invalidate#invalidate-content
You can currently do this for your own DS's. This is the 2nd one on the
list that a "normal" user can do currently.
8. Manage DS / cache assignments
This is the debatable one. To provide true delivery service self-service
should a user have the ability to determine which caches are assigned to
their delivery service. I'm thinking NO. Currently, this action requires
the Ops role and I'm in favor of leaving it that way...
In summary, to provide true delivery service self-service I think we need
to do a few things:
1. Introduce DS requests until the day in which DS configurations can be
guaranteed and queue updates/snapshot becomes a thing of the past. (this is
in progress)
2. Revisit DS regexes or make their management more fool proof.
3. Tweak the roles of these actions. Currently, a lot of these things are
reserved for Ops/Admin. We have to change that or full DS self-service if
not possible. I'd like to make each of these things accessible to users
with the "Portal" role with the exception of #8.
Thoughts? Concerns? Funny jokes?
Jeremy
