在Openshift上保护基于路径的路由 [英] Securing path based routing on Openshift
问题描述
我在openshift上部署的应用程序的URL为https://host:port/app/v1/hello/ 我将ServiceAccount用作Oauth客户端,提供程序是Openshift,因此应将我重定向到Openshift登录页面以进行授权.
My application deployed on openshift has url as https://host:port/app/v1/hello/ I am using ServiceAccount as Oauth client and the provider is Openshift, so I should be redirected to Openshift login page for Authorization.
我们已经配置了openshift/oauth-proxy,并且效果很好. https://github.com/openshift/oauth-proxy/
We have configured openshift/oauth-proxy and it works great. https://github.com/openshift/oauth-proxy/
现在我们进一步需要基于路径的路由,例如URL是否具有/app/v1然后重定向到Service1,如果/app/v2然后重定向到Service2
Now further we have requirement of Path based routing, like if URL has /app/v1 then redirect to Service1 and if /app/v2 then to Service2
这是我的配置的工作示例,
Here is the working example of my configuration,
`kind: Template
apiVersion: v1
metadata:
name: deployment-template
objects:
- apiVersion: v1
kind: ServiceAccount
metadata:
name: my-service-account
annotations:
serviceaccounts.openshift.io/oauth-redirectreference.first: '{"kind":"OAuthRedirectReference","apiVersion":"v1","reference":{"kind":"Route","name":"my-route"}}'
- apiVersion: v1
kind: Service
metadata:
name: my-service
annotations:
service.alpha.openshift.io/serving-cert-secret-name: proxy-tls
spec:
selector:
app: spring-boot-docker-openshift-hello-world
ports:
- name: api
protocol: TCP
port: 443 #Port the service listens on.
targetPort: 8443 #Port on the backing pods to which the service forwards connections.
- apiVersion: v1
kind: Route
metadata:
name: my-route
spec:
port:
targetPort: api
path: "/"
to:
kind: Service
name: my-service
tls:
termination: Reencrypt
- apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
labels:
app: spring-boot-docker-openshift-hello-world
version: 0.0.1-SNAPSHOT.1.dev
name: spring-boot-docker-openshift-hello-world
spec:
replicas: 1
selector:
app: spring-boot-docker-openshift-hello-world
strategy:
rollingParams:
timeoutSeconds: 3600
type: Rolling
template:
metadata:
labels:
app: spring-boot-docker-openshift-hello-world
version: 0.0.1-SNAPSHOT.1.dev
spec:
serviceAccount: my-service-account
serviceAccountName: my-service-account
containers:
- name: spring-boot-docker-openshift-hello-world
env:
- name: KUBERNETES_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
image: pokarjm/spring-boot-docker-openshift-hello-world:0.0.1-SNAPSHOT.1.dev
imagePullPolicy: IfNotPresent
securityContext:
privileged: false
ports:
- containerPort: 8080
protocol: TCP
- name: oauth-proxy
image: openshift/oauth-proxy:latest
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8443
name: public
args:
- --https-address=:8443
- --provider=openshift
- --openshift-service-account=my-service-account
- --upstream=http://localhost:8080
- --tls-cert=/etc/tls/private/tls.crt
- --tls-key=/etc/tls/private/tls.key
- --cookie-secret-file=/etc/proxy/secret/session_secret
- --openshift-ca=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
- --openshift-sar={"namespace":"spring-boot-docker-openshift-hello-world","resource":"services","name":"my-service","verb":"get"}
- --request-logging=true
volumeMounts:
- mountPath: /etc/tls/private
name: proxy-tls
readOnly: true
- mountPath: /etc/proxy/secret
name: oauth-proxy-secret
readOnly: true
volumes:
- name: proxy-tls
secret:
defaultMode: 420
secretName: proxy-tls
- name: oauth-proxy-secret
secret:
defaultMode: 420
secretName: oauth-proxy-secret
triggers:
- type: ConfigChange
`
现在要支持基于路径的路由,即将请求/app/v1映射到Service1,我只是在如下所示的路径中添加了路径,
Now to support path based routing, that is map the request /app/v1 to Service1, I just added the Path in route like below,
- apiVersion: v1
kind: Route
metadata:
name: my-route
spec:
port:
targetPort: api
path: "/app/v1"
to:
kind: Service
name: my-service
tls:
termination: Reencrypt
但是有了这一更改,我可以看到如下所示的初始登录页面
but with this changes I can see a initial sign in page like below
但是,在单击上方的按钮而不是进入openshift登录页面之后,我看到下面的内容,
but after clicking the button above instead of getting the openshift login page, I see below,
如果我将路由中的路径更改为路径:它可以正常工作并显示登录屏幕. 感谢您在openshift/oauth-proxy中解决基于路径的路由方面的任何帮助.
If I change the path in route to path: "/" it works and shows login screen. Appreciate any help on fixing path based routing in openshift/oauth-proxy.
推荐答案
尝试将类似--proxy-prefix=/app/v1
的内容添加到您的oauth代理容器中.
Try adding something like --proxy-prefix=/app/v1
, to your oauth proxy container.
例如:
[...]
args:
- --https-address=:8443
- --provider=openshift
- --proxy-prefix=/app/v1
- --openshift-service-account=my-service-account
[...]
否则,oauth-proxy会假设它正在提供服务的应用程序位于Route的根目录,从而破坏了登录回调重定向.
Otherwise, the oauth-proxy would assume the application it is serving lies at the root of your Route, breaking the login callback redirection.
现在,关于您在评论中的问题,我不确定我自己掌握了所有内容,我没有OpenShift集群可以对此进行测试,...稍加盐味,欢迎进行编辑,如果任何人都可以做到这一点.
Now, regarding your question in comments, I'm no sure I got it all myself, I don't have an OpenShift cluster to test this with, ... take it with a pinch of salt, edits welcome, if anyone can get this right.
据我了解并记得:
- 客户端通过oauth-proxy连接到您的应用.
- 代理会看到您的客户端未经身份验证,并使用其客户端ID和密码(已设置
openshift-service-account
,从/var/run/secrets/kubernetes.io/serviceaccount/
中读取了这些密码)从Oauth门户请求令牌.如果检测无法正常工作,您可以改用client-id=system:serviceaccount:$ns:$sa
和client-secret-file=/var/run/secrets/kubernetes.io/serviceaccount/token
. - Oauth SP使用
serviceaccounts.openshift.io/oauth-redirectreference
OauthClient (我不太熟悉),与客户端请求的应用程序URL匹配.成功匹配后,SP会使用一些临时令牌回复oauth-proxy - 知道了令牌和
proxy-prefix
,oauth-proxy将未经身份验证的用户重定向到Oauth登录门户,并使用一些编码的回调URL作为GET参数 - 用户针对OpenShift用户群登录
- 成功登录后,Oauth门户会使用从代理接收到的回调URL将您重定向到oauth-proxy
- oauth-proxy兑换其令牌
- 如果定义了
openshift-sar
,则oauth-proxy会进行一些其他检查,以确保客户端得到授权,否则任何用户都可以登录 - 用户可以选择同意授予某些权限
- Client connect to your app, going through your oauth-proxy.
- The proxy sees your client is unauthenticated and requests a token from the Oauth portal, using its client ID and secret (having set
openshift-service-account
, reads those out of/var/run/secrets/kubernetes.io/serviceaccount/
). You could instead useclient-id=system:serviceaccount:$ns:$sa
andclient-secret-file=/var/run/secrets/kubernetes.io/serviceaccount/token
, if detection somehow doesn't work. - The Oauth SP checks for our ServiceAccount with an
serviceaccounts.openshift.io/oauth-redirectreference
annotation (though there's another way to do this, with OauthClient, which I'm less familiar with), matching the client requested application URL. On successful match, SP replies to oauth-proxy with some ephemeral token - Knowing that token, and the
proxy-prefix
, the oauth-proxy redirects unauthenticated users to the Oauth login portal, with some encoded callback URL as a GET param - User logs in against OpenShift users base
- On successful login, the Oauth Portal redirects you to the oauth-proxy, using the callback URL it received from your proxy
- the oauth-proxy redeems its token
- If
openshift-sar
was defined, oauth-proxy proceeds with some additional check ensuring client is authorized, otherwise any user may log in - User optionally consent in granting some permissions
在OpenShift上下文中,初始令牌请求是使用login-url
参数(默认为kubernetes.default.svc/oauth/authorize
)完成的,尽管在某些情况下(不确定,某些异常的网络策略),您可能希望强制使用OpenShift而是使用控制台FQDN.
In OpenShift context, the initial token requests is done using the login-url
param, which defaults to kubernetes.default.svc/oauth/authorize
, though in some cases (not sure to remember, some unusual networkpolicies), you may want to force use your OpenShift console FQDN instead.
令牌兑换通过默认为kubernetes.default.svc/oauth/token
的redeem-url
完成.同样,如果SDN否则拒绝此流量,则可以在此处使用公共控制台FQDN.
The token redemption is done through the redeem-url
which defaults to kubernetes.default.svc/oauth/token
. Again, you could use your public console FQDN here, if SDN otherwise denies this traffic.
所以,代理前缀是如何出现的:仅当您的oauth-proxy构建正确的回调URL时才需要,登录表单会将您发送回正确的子路径您的应用程序.
So, how is proxy-prefix coming into the picture: only required for your oauth-proxy to build the proper callback URL, for the login form to send you back to the proper sub-path of your application.
并且OAuthRedirectReference主要由OpenShift使用,以确保请求令牌的客户端确实旨在对给定Route进行身份验证的客户端.在您的情况下,仅匹配FQDN,尽管我认为除了serviceaccounts.openshift.io/oauth-redirectreference.$name: {"kind": ...}
之外,您还可以设置类似serviceaccounts.openshift.io/oauth-redirecturi.name: my-path
And the OAuthRedirectReference is mainly used by OpenShift making sure the client requesting a token is indeed meant to authenticated clients for a given Route. In your case, only matching a FQDN, although I think that in addition to serviceaccounts.openshift.io/oauth-redirectreference.$name: {"kind": ...}
, you may also set something like serviceaccounts.openshift.io/oauth-redirecturi.name: my-path
这篇关于在Openshift上保护基于路径的路由的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!