泽民博客 ☰ Menu

k8s_oauth

HTTP协议重定向
HTTP重定向：服务器无法处理浏览器发送过来的请求（request），服务器告诉浏览器跳转到可以处理请求的url上。（浏览器会自动访问该URL地址，以至于用户无法分辨是否重定向了。）
重定向的返回码3XX说明。Location响应首部包含了内容的新地址或是优选地址的URL。



状态码
301：在请求的URL已被移除时使用。响应的Location首部中应该包含资源现在所处的URL。
302：与301状态码类似，但是，客户端应该使用Location首部给出的URL来零食定位资源，将来的请求仍然使用老的URL。



尽量使用301跳转！301和302状态码都表示重定向，就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址，这个地址可以从响应的Location首部中获取（用户看到的效果就是他输入的地址A瞬间变成了另一个地址B）——这是它们的共同点。他们的不同在于。301表示旧地址A的资源已经被永久地移除了（这个资源不可访问了），搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址；302表示旧地址A的资源还在（仍然可以访问），这个重定向只是临时地从旧地址A跳转到地址B，搜索引擎会抓取新的内容而保存旧的网址。



转发过程：客户浏览器发送http请求——》web服务器接受此请求——》调用内部的一个方法在容器内部完成请求处理和转发动作——》将目标资源发送给客户；



在这里，转发的路径必须是同一个web容器下的url，其不能转向到其他的web路径上去，中间传递的是自己的容器内的request。在客户浏览器路径栏显示的仍然是其第一次访问的路径，也就是说客户是感觉不到服务器做了转发的。转发行为是浏览器只做了一次访问请求。



重定向过程：客户浏览器发送http请求——》web服务器接受后发送302状态码响应及对应新的location给客户浏览器——》客户浏览器发现是302响应，则自动再发送一个新的http请求，请求url是新的location地址——》服务器根据此请求寻找资源并发送给客户。



在这里location可以重定向到任意URL，既然是浏览器重新发出了请求，则就没有什么request传递的概念了。在客户浏览器路径栏显示的是其重定向的路径，客户可以观察到地址的变化的。重定向行为是浏览器做了至少两次的访问请求的。



重定向，其实是两次request



https://www.cnblogs.com/bq-med/p/8602629.html



OAuth 2.0 规定了四种获得令牌的流程。你可以选择最适合自己的那一种，向第三方应用颁发令牌。下面就是这四种授权方式。



授权码（authorization-code）
隐藏式（implicit）
密码式（password）：
客户端凭证（client credentials）



第一种授权方式：授权码
授权码（authorization code）方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌。



这种方式是最常用的流程，安全性也最高，它适用于那些有后端的 Web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。



第一步，A 网站提供一个链接，用户点击后就会跳转到 B 网站，授权用户数据给 A 网站使用。下面就是 A 网站跳转 B 网站的一个示意链接。



https://b.com/oauth/authorize?
response_type=code&
client_id=CLIENT_ID&
redirect_uri=CALLBACK_URL&
scope=read
上面 URL 中，response_type参数表示要求返回授权码（code），client_id参数让 B 知道是谁在请求，redirect_uri参数是 B 接受或拒绝请求后的跳转网址，scope参数表示要求的授权范围（这里是只读）。



第二步，用户跳转后，B 网站会要求用户登录，然后询问是否同意给予 A 网站授权。用户表示同意，这时 B 网站就会跳回redirect_uri参数指定的网址。跳转时，会传回一个授权码，就像下面这样。
https://a.com/callback?code=AUTHORIZATION_CODE
上面 URL 中，code参数就是授权码。



第三步，A 网站拿到授权码以后，就可以在后端，向 B 网站请求令牌。
https://b.com/oauth/token?
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
grant_type=authorization_code&
code=AUTHORIZATION_CODE&
redirect_uri=CALLBACK_URL
上面 URL 中，client_id参数和client_secret参数用来让 B 确认 A 的身份（client_secret参数是保密的，因此只能在后端发请求），grant_type参数的值是AUTHORIZATION_CODE，表示采用的授权方式是授权码，code参数是上一步拿到的授权码，redirect_uri参数是令牌颁发后的回调网址



第四步，B 网站收到请求以后，就会颁发令牌。具体做法是向redirect_uri指定的网址，发送一段 JSON 数据。
{

“access_token”:”ACCESS_TOKEN”,
“token_type”:”bearer”,
“expires_in”:2592000,
“refresh_token”:”REFRESH_TOKEN”,
“scope”:”read”,
“uid”:100101,
“info”:{…}
}
上面 JSON 数据中，access_token字段就是令牌，A 网站在后端拿到了



用户就可以通过携带A网站返回的access_token 去访问想要的资源了
https://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html

用户在访问一个资源之前我们需要验证下这个用户是否有权限，也就是校验请求携带的access_token ，一般放在http header 里面，Authorization header 的典型数据为 “Authorization: Basic realm=jdhaHY0=”，其中 Basic 表示基础认证。



那么A网站一般需要一个auth的接口，来判断http header 里面是否有Authorization信息以及Authorization的合法性。如果合法，一般在Ingress里面允许继续访问资源。如果不合法，就会重定向到一个错误页面。在这个错误页面中，用户自己决定是否走认证流程，也就是前面oauth2的认证流程。



所以ingress 里面有两个注解项，对应上述两个接口：


apiVersion: extensions/v1beta1

kind: Ingress

metadata:

  name: ingress

  namespace: nginx-ingress

  annotations:

     nginx.ingress.kubernetes.io/auth-url: "https://$host/oauth2/auth"

     nginx.ingress.kubernetes.io/auth-signin: "https://$host/oauth2/start?rd=$request_uri"


auth-url 代表认证用户信息是否合法的页面



nginx.ingress.kubernetes.io/auth-url: “URL to the authentication service”



auth-signin 代表错误页面



nginx.ingress.kubernetes.io/auth-signin-redirect-param: to specify the URL parameter in the error page which should contain the original URL for a failed signin request.



https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/
https://kubernetes.github.io/ingress-nginx/examples/auth/oauth-external-auth/



简单认证可以使用basic auth


需要在 Ingress 对象中添加auth-type：basic和auth-jenkins-basic-auth两个 annotations：（ingress.yaml）



apiVersion: extensions/v1beta1

kind: Ingress

metadata:

  name: jenkins

  namespace: kube-ops

  annotations:

    kubernetes.io/ingress.class: nginx

    # 认证类型

    nginx.ingress.kubernetes.io/auth-type: basic

    # 包含 user/password 的 Secret 名称

    nginx.ingress.kubernetes.io/auth-secret: jenkins-basic-auth

    # 当认证的时候显示一个合适的上下文信息

    nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required - admin'


https://www.qikqiak.com/post/how-to-protect-exposed-k8s-server/



https://blog.51cto.com/u_15077560/2585140



https://www.it1352.com/2160322.html



如果是ladp认证
ldap验证的服务ingress 上添加以下annotation


apiVersion: extensions/v1beta1

kind: Ingress

metadata:

  annotations:

    nginx.ingress.kubernetes.io/auth-url: https://{server_domain}/auth/ldap/$remote_user/$http_authorization

https://zhuanlan.zhihu.com/p/377931297



https://www.it1352.com/2160250.html


Category k8s