Securing the Container Platform

Container Orchestration

APIs are key to automating container management at scale. APIs are used to:

  • Validate and configure the data for pods, services, and replication controllers.

  • Perform project validation on incoming requests and invoke triggers on other major system components.

Further Reading

Authentication and Authorization

Controlling Access Using OAuth

You can use API access control via authentication and authorization for securing your container platform. The OKD master includes a built-in OAuth server. Users can obtain OAuth access tokens to authenticate themselves to the API.

As an administrator, you can configure OAuth to authenticate using an identity provider, such as LDAP, GitHub, or Google. The Allow All identity provider is used by default for new OKD deployments, but you can configure this at initial installation time or post-installation. See Configuring authentication and user agent for a full list of identity providers.

For example, to configure the GitHub identity provider post-installation:

  1. Edit the master configuration file at /etc/origin/master-config.yaml.

  2. Modify the oauthConfig stanza per the following:

    1. oauthConfig:
    2.   ...
    3.   identityProviders:
    4.   - name: github
    5.     challenge: false
    6.     login: true
    7.     mappingMethod: claim
    8.     provider:
    9.       apiVersion: v1
    10.       kind: GitHubIdentityProvider
    11.       clientID: ...
    12.       clientSecret: ...
    13.       organizations:
    14.       - myorganization1
    15.       - myorganization2
    16.       teams:
    17.       - myorganization1/team-a
    18.       - myorganization2/team-b

    See the GitHub section in Configuring Authentication for more detailed information and usage.

  3. After saving your changes, restart the master services for the changes to take effect:

    1. # master-restart api
    2. # master-restart controllers

Further Reading

Secure Self-service Web Console

OKD provides a self-service web console to ensure that teams do not access other environments without authorization. OKD ensures a secure multi-tenant master by providing the following:

  • Access to the master uses Transport Layer Security (TLS)

  • Access to the API Server uses X.509 certificates or OAuth access tokens

  • Project quota limits the damage that a rogue token could do

  • Etcd is not exposed directly to the cluster

Further Reading

Managing Certificates for the Platform

OKD has multiple components within its framework that use REST-based HTTPS communication leveraging encryption via TLS certificates. OKD’s Ansible-based installer configures these certificates during installation. There are some primary components that generate this traffic:

  • masters (API server and controllers)

  • etcd

  • nodes

  • registry

  • router

Configuring Custom Certificates

You can configure custom serving certificates for the public host names of the API server and web console during initial installation or when redeploying certificates. You can also use a custom CA.

During initial cluster installations using Ansible playbooks, custom certificates can be configured using the openshift_master_overwrite_named_certificates Ansible variable, which is configurable in the inventory file. For example:

  1. openshift_master_named_certificates=[{"certfile": "/path/on/host/to/custom1.crt", "keyfile": "/path/on/host/to/custom1.key", "cafile": "/path/on/host/to/custom-ca1.crt"}]

See Configuring Custom Certificates section for more options and instructions on how to run the installation playbook.

The installer provides Ansible playbooks for checking on the expiration dates of all cluster certificates. Additional playbooks can automatically redeploy all certificates at once using the current CA, redeploy specific certificates only, or redeploy a newly generated or custom CA on its own. See Redeploying Certificates for more on these playbooks.

Further Reading