[tech] Cloudflare dashboard access for ucc.gu.uwa.edu.au, was Re: [wheel] Clarification of requirements and plan of action

[Nick Bannon]

On Tue, Apr 14, 2020 at 02:31:47AM +0000, Paul Fisher wrote:
[...]
> It's good to hear from you, how are you?
> Things have been very busy for us working on the https://unidesk.uwa.edu.au solution.

Likewise, thank you!
We've had some successful online social events and a seminar/tech-talk
that was well-received.

Ah, the Citrix virtual apps/desktops?

[...]
> ucc.guild.uwa.edu.au and ucc.gu.uwa.edu.au, I have created these as subdomains in the account however it is unlikely from the discussion I've had these will be able to be maintained as delegated subdomains.

  * Q: Can we please clarify: What is the progress on getting access to
    the Cloudflare dashboard for ucc.gu.uwa.edu.au in particular?

  * We are not expecting that this is a literal DNS-protocol subdomain
    delegation, we are just asking about access to the Cloudflare
    dashboard for that area.

  * Right now we have the outstanding issue reported as INC0468212 in
    ServiceNow. One of the consequences of that is a Letsencrypt
    certificate that we use for non-web services has expired. We cannot
    renew it without adding DNS challenge entries to ucc.gu.uwa.edu.au
    and this is now urgent.

We were of the understanding after the 2020-03-25 conversation that
we could nominate some Pheme account holders for direct access to the
Cloudflare dashboard for that ucc.gu.uwa.edu.au area, and for Splunk access.

We would like to nominate the following two who you spoke to on 2020-03-25:
  * James Arcus <21954943 at student.uwa.edu.au>
  * Zack Wong <22229618 at student.uwa.edu.au>
...plus our Vice-President:
  * Timothy Chapman <22483878 at student.uwa.edu.au>

In the meantime, we have moved some web services off our
multi-purpose web + non-web machines; and we have been
experimenting with Cloudflare Free tier.

However, we would like to start other migration of services before
ports 443 and 80 start being blocked.

(Such as testing our meetings conference server. It is probably not a
straightforward Cloudflare-proxyable service. Other sevices may require
F5 or Cloudflare Spectrum.)

Specifically, we'd like to turn proxying on and off for test services
under the domain names:
  * ucc.gu.uwa.edu.au
  * ucc.guild.uwa.edu.au

> I've attached the zone files I have for these zones, if you can check these for accuracy. I'll have the records added to the parent zone and delegation removed.

Thanks for the zone files - we can confirm that is only a small portion
of our previously-visible entries.

Visibility over the live contents is vital to us.

> I will confirm a date with you before proceeding.
> 
> Moving forward any records under uwa.edu.au are part of the corporate brand and an approval process will be required to have names allocated in the uwa.edu.au domain.

On Tue, Apr 14, 2020 at 02:58:42AM +0000, Paul Fisher wrote:
[...]
> If you could have a look at the scan list provided and give a brief description of the hosts and there purpose from an educational purpose.
> It doesn't have to be in great detail, just something that provides a value proposition for education within the UWA core business setting.
> Something I can use to justify maintaining the services published in the UWA network space.

We are keenly aware of the need to protect the UWA corporate brand and
I believe we have an excellent track record of being responsible and
responsive with our small portion of uwa.edu.au . We value it highly.

We understand if there has to be some isolation. Clearly, a lot of
department and campus services have to be separated from each other -
especially from students! Some of our sysadmin team have read previous
security reports and lessons learned, including the ANU public report
from last year at the time. Thank you for raising it again, it has been
worth the deeper look.

We are very much hoping that we can make that approval and justification
for our subdomain, network and its changing contents as a whole rather
than on an item-by-item change-request basis.

When changes are made, it's very important to us that we have
visibility and can see the live results directly and know what
should and should not be working.

A workflow that we have to externally pre-approve each
change and experimental service before we can test it out:

  (a) will be very difficult for us gain benefit from; and

  (b) directly conflicts with effective end-to-end security automation
      such as Letsencrypt ACME DNS challenges and DKIM signing.

Thank you,
Nick Bannon
University Computer Club, Sysadmin/tech-contact group
wheel at ucc.gu.uwa.edu.au
https://www.ucc.gu.uwa.edu.au/