Deploy Kubernetes API Server w/ Ingress and Keystone Webhook

OpenStack Keystone will the be single authentication mechanism for Airship users. As such, we need to deploy a Kubernetes API server endpoint that can utilize Keystone for authentication and authorization. The avenue to support this is using the Kubernetes webhook admission controller with a webhook supporting Keystone.

Links

None

Problem description

While Airship component APIs should care for most lifecycle tasks for the Kubernetes cluster, there will be some maintenance and recovery operations that will require direct access to the Kubernetes API. To properly secure this API, it needs to utilize the common single sign-on that operators use for accessing Airship APIs, i.e. Keystone. However, the external facing API should minimize risk to the core Kubernetes API servers used by other Kubernetes core components. This specification proposes a design to maximize the security of this external facing API endpoint and minimizes the risk to the core operations of the cluster by avoiding the need to add complexity to core apiserver configuration or sending extra traffic through the core apiservers and Keystone.

Impacted components

The following Airship components would be impacted by this solution:

Promenade - Maintenance of the chart for external facing Kubernetes API servers

Proposed change

Create a chart, webhook_apiserver, for an external facing Kubernetes API server that would create a Kubernetes Ingress entrypoint for the API server and, optionally, also spin up a webhook side-car for each API server (i.e. sidecar mode). The other mode of operation is federated mode where the webhook will be accessed over a Kubernetes service.

A new chart is needed because the standard apiserver chart <https://github.com/openstack/airship-promenade/tree/master/charts/apiserver> relies on the anchor pattern creating static pods. The webhook_apiserver chart should be based on the standard apiserver chart and use helm_toolkit standards.

The chart would provide for configuration of the Keystone webhook (also Keystone webhook addl and Keystone webhook chart) in sidecar mode and allow for configuring the webhook service address in federated mode. The Kubernetes apiserver would be configured to only allow for authentication/authorization via webhook. No other authorization modes would be enabled. All kube-apiserver` command line options should match the with the following exceptions:

authorization-mode: Webhook

audit-log-path: -

authentication-token-webhook-config-file: path to configuration file for accessing the webhook.

authorization-webhook-config-file: path to configuration file for accessing the webhook.

apiserver-count: omit

endpoint-reconciler-type: none

Webhook Configuration

The configuration for how the Kubernetes API server will contact the webhook service is stored in a YAML configuration file based on the kubeconfig file format. The below example would be used in sidecar mode.

# clusters refers to the remote service.
clusters:
  - name: keystone-webhook
    cluster:
      # CA for verifying the remote service.
      certificate-authority: /path/to/webhook_ca.pem
      # URL of remote service to query. Must use 'https'. May not include parameters.
      server: https://localhost:4443/

# users refers to the API Server's webhook configuration.
users:
  - name: external-facing-api
    user:
      client-certificate: /path/to/apiserver_webhook_cert.pem # cert for the webhook plugin to use
      client-key: /path/to/apiserver_webhook_key.pem          # key matching the cert

# kubeconfig files require a context. Provide one for the API Server.
current-context: webhook
contexts:
- context:
    cluster: keystone-webhook
    user: external-facing-api
  name: webhook

Documentation impact

Documentation of the overrides to this chart for controlling webhook authorization mapping policy.

Security impact

Additional TLS certificates for apiserver <-> webhook connections
Keystone webhook must have an admin-level Keystone account
Optionally, the Keystone webhook minimizes attack surface by becoming a sidecar without external facing service.

Performance impact

This should not have any performance impacts as the only traffic handled by the webhook will be from users specifically using Keystone for authentication and authorization.

Testing impact

The chart should include a Helm test that validates a valid Keystone token is usable with kubectl to successfully get a respond from the Kubernetes API.

Implementation

Milestone 1

Chart support for sidecar mode

Milestone 2

Addition of federated mode

Dependencies