在 OPENSHIFT 上保护路线

Question

我在 OPENSHIFT 上部署了一个应用程序。并为它创建了一条路线。我希望只有少数用户而不是所有人都可以访问该路线。并且可以访问路由的用户应该由我控制。这就像在 Openshift 中为路由提供 Authentication Scheme 一样。我怎样才能做到这一点。请在这方面帮助我。

Answer 1

虽然 Kubernetes 入口控制器通常嵌入此类功能，但 OpenShift 并非如此。推荐的方法通常是依赖 oauth-proxy，它可以与 OpenShift API 集成，从而可以轻松与 OpenShift 用户集成——同时它也可以用于与第三方提供商（KeyCloak、LemonLDAP-NG、 ...)。

认证

与 OpenShift API 集成，我们将首先创建一个 ServiceAccount，如下所示：

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    serviceaccounts.openshift.io/oauth-redirectreference.my-app: '{"kind":"OAuthRedirectReference","apiVersion":"v1","reference":{"kind":"Route","name":"my-route-name"}}'
  name: my-app
  namespace: my-project

该注释将告诉 OpenShift 如何在成功登录后将您的用户发送回您的应用程序：查找路由 my-route-name。

我们还将创建一个由 OpenShift PKI 签名的证书，稍后我们将使用它来设置我们的 OAuth 代理。这可以通过创建Service 来完成，如下所示：

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.alpha.openshift.io/serving-cert-secret-name: my-app-tls
  name: my-app
  namespace: my-project
spec:
  ports:
  - port: 8443
    name: oauth
  selector:
    [ your deployment selector placeholder ]

然后我们可以在我们的应用部署中添加一个 sidecar 容器：

[...]
containers:
- args:
  - -provider=openshift
  - -proxy-prefix=/oauth2
  - -skip-auth-regex=^/public/
  - -login-url=https://console.example.com/oauth/authorize
  - -redeem-url=https://kubernetes.default.svc/oauth/token
  - -https-address=:8443
  - -http-address=
  - -email-domain=*
  - -upstream=http://localhost:3000
  - -tls-cert=/etc/tls/private/tls.crt
  - -tls-key=/etc/tls/private/tls.key
  - -client-id=system:serviceaccount:my-project:my-app
  - -client-secret-file=/var/run/secrets/kubernetes.io/serviceaccount/token
  - -cookie-refresh=0
  - -cookie-expire=24h0m0s
  - -cookie-name=_oauth2_mycookiename
  name: oauth-proxy
  image: docker.io/openshift/oauth-proxy:latest
  [ resource requests/limits & livenesss/readiness placeholder ]
  volumeMounts:
  - name: cert
    path: /etc/tls/private
 [ your application container placeholder ]
 serviceAccount: my-app
 serviceAccountName: my-app
 volumes:
 - secret:
     name: my-app-tls
   name: cert

假设：

• console.example.com 你的 OpenShift 公共 API FQDN
• ^/public/，可选路径正则表达式，不应进行身份验证
• http://localhost:3000，Oauth 代理将连接的 URL，将端口固定到您的应用程序绑定的任何端口。还可以考虑将您的应用重新配置为仅在其环回接口上绑定，以防止绕过您的 oauth 代理的访问
• my-project / my-app，您的项目和应用名称

确保您的Route tls 终止设置为直通，将其流量发送到端口8443。

结帐https://github.com/openshift/oauth-proxy 以获取详尽的选项列表。 openshift-sar 可能很有趣，它根据用户对 OpenShift 对象的权限过滤哪些用户可以登录。

显然，在某些情况下，您将部署可配置为与某些 OAuth 提供程序集成的应用程序：那么没有理由使用代理。

基本认证

如果您不想与 OpenShift 用户或任何第三方提供商集成，您可能需要使用一些 nginx sidecar 容器 - dockerhub 上有很多可用的容器。

自定义入口

另请注意，使用 OpenShift 3.x，集群管理员可以自定义用于生成 HAProxy 配置的模板，修补他们的入口部署。这是一种相对常见的方法来修复一些标题，处理一些自定义注释供您的用户在他们的Routes 中设置，...在https://docs.openshift.com/container-platform/3.11/architecture/networking/routes.html#env-variables 中查找TEMPLATE_FILE。

截至目前，我认为 OpenShift 4 入口控制器不允许这样做 - 因为它由操作员驱动，配置选项有限，请参阅 https://docs.openshift.com/container-platform/4.5/networking/ingress-operator.html。

虽然对于 OpenShift 3：您可以很好地部署自己的入口控制器，如果您必须处理此类边缘情况。

Answer 2

不幸的是，OpenShift Routes 没有内置任何身份验证机制。有通常的 TLS / 子域 / 基于路径的路由功能，但没有身份验证。

因此，您在 OpenShift 上最直接的路径是部署额外的反向代理作为应用程序的一部分，例如“nginx”、“traefik”或“haproxy”：

                       +-------------+       +-----------------+
                       |   reverse   |       |                 |
+--incoming traffic--->+   proxy     +------>+ your application|
   from your Route     |             |       |                 |
                       +-------------+       +-----------------+

对于身份验证方法，您有多种选择，具体取决于您选择部署的解决方案（最简单的是基本身份验证或摘要式身份验证）。