support for dataclass annotations on routes created with kube api

[ikethecoder]

The kube-api is responsible for any custom provisioning based on the infrastructure that Kong data planes are deployed to. For BC Government Emerald Openshift cluster, there is a requirement to annotation the DataClass based on the sensitivity of the data being passed through the endpoint.

This ticket is the work on the kube-api to provide a way of specifying a DataClass on a Kong Route and then have the appropriate annotation be applied on the Route resource in Openshift.

[ikethecoder]

Similar to how #112 worked, have a custom annotation that will specify the desired DataClass:

services:
- name: my-service
  routes:
  - name: my-route
    tags: [ ns.NS, aps.route.dataclass.medium ]

With valid values: aps.route.dataclass=low aps.route.dataclass=medium and aps.route.dataclass=high

The kube-api will then use the information to add the appropriate annotation on the Route.

[rustyjux]

Requirements

• k8s route needs this annotation with this format:

  aviinfrasetting.ako.vmware.com/name: dataclass-medium
  

Implementation

• should be adding tag at the service level (in gateway configuration), and need to read the overrides from service and pass down to the routes (in the prep for kube API part of gwa api
  • gatewayApi passes to kube api an object with "hosts" as an array, and then the overrides have values that represent an array of hosts that the particular override applies to - https://github.com/bcgov/gwa-api/blob/dev/microservices/gatewayApi/v2/routes/gateway.py#L337
  • "eval_services" can be enhanced to check service tags for matching "override_tag", not just route tags..
    https://github.com/bcgov/gwa-api/blob/dev/microservices/gatewayApi/clients/ocp_routes.py#L263

Tests

• adding a data class / removing a dataclass
• changing between data classes

[rustyjux]

There is actually no need for dataclass=low since that is the default for all routes in Emerald. Users can add it, but we need not apply anything.

This is potentially a need for dataclass=public however - see https://digital.gov.bc.ca/cloud/services/private/internal-resources/emerald/#:~:text=How%20to%20assign%20security%20classifications%20to%20routes:

...For routes, you use “aviinfrasetting.ako.vmware.com/name” and assign it a value from one of the following: “dataclass-medium”, “dataclass-high” or “dataclass-public”.

For the route Security Classification, all settings result in a private IP address that cannot be accessed from the Internet. If internet access is required, then add the annotation with a value of “dataclass-public”.

The default “apps.emerald.devops.gov.bc.ca” subdomain cannot be resolved by DNS from the public internet, so public routes will need to use a vanity domain and dedicated TLS certificates to be accessible from the internet.

@ikethecoder, we'll be able to support this?

[ikethecoder]

I would say we still allow dataclass=low as it helps with the validation on the gateway API to enforce a dataclass selection for gateways on Emerald. Not sure about dataclass=public - maybe exclude it for now, and wait for a need so we understand why this type of need is there. But even if we add it, it shouldn't be an issue to support it.

If low and public are equivalent, then in this case, we can include dataclass=public together with dataclass=medium and dataclass=high as valid values.

[rustyjux]

Docs read to me like public is not equivalent to low:

• low is the default and results in a private IP. No need to specify on routes in Emerald (unlike pods). We can ask for it but don't need to do anything with it.
• public is a valid value to annotate on a route (alongside medium and `high) and results in a public IP which could be accessed from the public internet given a vanity domain (we already do that?) and TLS certs (do we do that?)

[ikethecoder]

Ok.. yes we support vanity domain and TLS certs for all the data classes so no issue there.

[rustyjux]

Manual validation in dev:

• create a new service w/o data class
  • add data class tag on service ✅
  • add another route to the service - it gets annotated too ✅
  • remove tag - annotations removed ✅
• create a new service w/ data class tag on only one route ✅
  • add a different data class tag on another route in same service - each route has its own data class ✅
  • put a conflicting data class tag on service - tags with later alphabetical order take precedence (ie medium overrides low, public overrides medium) 🤷‍♀️ - does this matter? not really an expected use
  • remove route-level tags - service-level tag is applied ✅

To fix:

• gwa scheduler (key error on dataClass)

To validate:

• Emerald

[rustyjux]

@ikethecoder hit a roadblock here -
When routes are synced with gwa-scheduler, they do not include the data class because the source_routes from Kong Admin API (get_routes()) don't include data class in the tags included with each route. Why not? gatewayApi does not add this tag to the Kong route, only the service.
Only when making the PUT call to the gatewayApi do we have get_route_overrides() and eval_services() which this is passed to kubeApi.

Possible solutions I can imagine:

1. Add another enrichment to apply the tags down onto routes in Kong? https://github.com/bcgov/gwa-api/blob/feature/dataclass-annotation/microservices/gatewayApi/v2/routes/gateway.py#L235 (and have the aps.route.dataclass tag on services override any route tags in the config)
2. Add a step to gwa-scheduler to get info on services from Kong Admin API
3. Require Gold/DR users to tag on the route level

Or can you think of a simpler solution to support syncing data classes in gwa-scheduler?
I think I am going to implement the first solution.

[rustyjux]

lol after adding this I realized it doesn't even matter... gold wont be using data class so as long as there aren't errors really it's fine.
Added in 863ba9c