WO2019001110A1 - 权限认证方法、系统、设备及计算机可读存储介质 - Google Patents

权限认证方法、系统、设备及计算机可读存储介质 Download PDF

Info

Publication number
WO2019001110A1
WO2019001110A1 PCT/CN2018/083842 CN2018083842W WO2019001110A1 WO 2019001110 A1 WO2019001110 A1 WO 2019001110A1 CN 2018083842 W CN2018083842 W CN 2018083842W WO 2019001110 A1 WO2019001110 A1 WO 2019001110A1
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
token
information
request
mirror
Prior art date
Application number
PCT/CN2018/083842
Other languages
English (en)
French (fr)
Inventor
刘俊杰
Original Assignee
平安科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 平安科技（深圳）有限公司 filed Critical 平安科技（深圳）有限公司
Publication of WO2019001110A1 publication Critical patent/WO2019001110A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]

Definitions

  • the client receives the unauthorized error message, first parses the unauthorized error information to obtain the authentication method prompt information, and then requests the token from the token server according to the prompt of the authentication method.
  • FIG. 2 is a flowchart of a preferred embodiment of step S20 in the rights authentication method of the Docker image repository provided by the present application.
  • the token server After the token server receives the rights authentication request information, the token server performs the following actions:
  • the format of the header is:
  • Kid - key Id (key identification), which is a unique ID generated by the public part of the signature key. By dividing the DER encrypted public key by 240 bytes, it is divided into 12 base32 packets. The format of the generated kid is: ABCD: EFGH: IJKL: MNOP: QRST: UVWX: YZ12: 3456: ABCD: EFGH: IJKL: MNOP .
  • Access - a list of permissions, consisting of an array of specific permissions, the type of each access Indicates the type of access (such as repository for mirrored repositories), name for the name of the object being accessed (such as the name of the repository), and the actions array for the action to be performed (such as pull, push) Wait).
  • Nbf - not before which is the start time of the token, usually equal to iatt.
  • step S301 the non-content space character in the header and payload format is used in the header and payload components. ]] The spaces before and after, that is, the removal of the space character does not affect the head and load components.
  • step S302 base64 encoding for url (web page address) (Base64 is one of the most common encoding methods for transmitting 8 Bit byte codes on the network) is used to obtain the encoded header and payload, respectively.
  • the method may further include: placing the public key in the mirror warehouse, generating a key identifier of the token header, and placing the private key in the token server, before the step S10. Sign the token.
  • the application Before using the token server, the application needs to generate a certificate, a private key, and a public key in advance, so that the client implements communication between the token server and the mirror warehouse, and specifically places the certificate in the token server, and the private key. Used by the token server to sign the token, and the public key is used to generate the kid of the token header.
  • the public key private key pair is generated by means of openssl (Secure Socket Layer Password Vault), and the generated method is as follows:
  • the pull mirror and the push image of the present application further include: the mirror warehouse receives the token, parses and verifies the token, and returns a mirror to the client when the verification passes.
  • the operation of accessing the mirror warehouse and the token server in this application is completed by the user terminal of the Linux system, and the security of the Docker image is improved by the third party performing the authority authentication.
  • the present application controls the token server in advance.
  • the token request that does not contain the user authentication information in the https request header is rejected.
  • the token server's request for warehouse access is classified according to the warehouse name prefix, which improves the work efficiency.
  • the specific categories include:
  • User repository A warehouse that starts with a username, such as zhangsan001/tomcat, can be pulled by any user, but only the user (such as zhangsan001) can push the image.
  • LDAP Lightweight Directory Access Protocol
  • Lightweight Directory Access Protocol Lightweight Directory Access Protocol
  • the manner in which the token server authenticates the user includes: the token server parses the authority authentication request information, and verifies the user authentication information; after that, the user authentication information is sent to the LDAP server for the identity and authority of the user. Verification; when the LDAP server determines that the authentication is passed, the token server generates a token for the client and returns the token to the client.
  • the rights authentication method of the Docker image warehouse includes:
  • the first step the client uses docker login, docker push, docker pull
  • the client's docker client process issues a request to the mirror repository
  • the third step the docker client process encrypts the user's authentication information according to the prompt and puts it on https.
  • the AUTHORIZATION header of the request, and the content range requested by the user is placed in the request parameter and sent to the token server;
  • the token server parses and verifies the user authentication token and the scope of the request mirror content, and sends the corresponding token to the client in the verification.
  • the mirror warehouse obtains the token
  • the token is parsed and verified, and the docker client process returns the corresponding image when the verification is passed.
  • 2VIP and port will be mirrored and sent to AVIP and port and BVIP and port.
  • the present application further provides a privilege authentication system for the Docker image repository.
  • the privilege authentication system includes a privilege authentication device, and the privilege authentication device can be regarded as a
  • a Docker client includes an access module 21, a receiving module 22, a parsing module 23, and a rights authentication request module 24.
  • a module referred to in this application refers to a series of computer program instruction segments capable of performing a specific function, and is more suitable than the program for describing the execution process of the rights authentication program of the Docker image repository in the Docker client. The following description will specifically describe the functions of the modules 21-24.
  • the access module 21 is configured to access the mirror warehouse
  • the receiving module 22 is configured to receive the unauthorized error information returned by the mirror warehouse when the access mirror warehouse is rejected, and the response header of the unauthorized error information includes the authentication method prompt information;
  • the parsing module 23 is configured to parse the unauthorized error information, and send a permission authentication request to the token server according to the authentication method prompt information to perform the right authentication;
  • the receiving module 22 is further configured to receive a token returned by the token server;
  • the authority authentication requesting module 24 is configured to carry the token to send an access request to the mirror warehouse
  • the receiving module 22 is further configured to receive a mirror returned by the mirror warehouse.
  • the parsing module 23 includes:
  • the parsing unit 231 is configured to parse the unauthorized error information, and the response header for obtaining the unauthorized error information includes the authentication method prompt information.
  • the request information generating unit 232 is configured to generate the authority authentication request information by using the user authentication information and requesting the mirrored content range according to the prompt of the authentication method prompt information;
  • the sending unit 233 is configured to send the rights authentication request information to the token server.
  • the privilege authentication system of the Docker image warehouse of the present application further includes a token server, and the token server performs information interaction with the privilege authentication device, and is used to generate a token for Docker authority authentication, which includes the
  • the token server includes: a verification module, a judgment module, and a token processing module.
  • the determining module 32 is configured to determine, according to the scope of the requested mirror content, whether the client can access the mirrored content of the request when the user passes the authentication;
  • the token processing module 33 is configured to: when the client can access the requested mirrored content, generate a token according to the user authentication information and the requested mirrored content range, and return the token to the client.
  • the token includes a header, a payload, and a signature, and the header, the payload, and the signature are separated by a decimal point.
  • the token processing module 33 includes a signature processing unit 331, configured to generate a signature of the token, including: removing the non-content space in the format in the header and the payload.
  • the header and the payload are respectively compressed; the encoder is used to encode the compressed header and the payload; the encoded header and the payload are connected by a decimal point; using the encryption algorithm specified in the header, using the private key
  • the signature generates the signature of the token as the third segment of the token.
  • the token processing module 33 includes a signature unit 332 for placing the public key in the mirror repository to generate a key identifier for the token header, and placing the private key in the token server for signing the token.
  • the privilege authentication system of the Docker image warehouse of the present application further includes a mirror repository for receiving the token, parsing and verifying the token, and returning the image to the client when the verification is passed.
  • the mirror warehouse is further configured to place the public key in the mirror warehouse, generate a key identifier of the token header, and place the private key in the token server for signing the token.
  • the application improves the security of the image by issuing the authority authentication to the third party for verification and issuing the permission according to the request token.
  • the application of the token server can allow third parties to perform more complicated and complete authentication.
  • the authentication can be combined with database authentication, configuration authentication, LDAP authentication, etc., and provides flexible combination of multiple rights, which has greater flexibility.
  • a computer program to instruct related hardware (such as a processor, a controller, etc.), and the program can be stored in one.
  • the program when executed, may include the processes of the various method embodiments as described above.
  • the storage medium described therein may be a memory, a magnetic disk, an optical disk, or the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本申请公开了Docker镜像仓库的权限认证方法、系统、设备及计算机可读存储介质。其中，权限认证方法先由访问镜像仓库被拒绝时，接收镜像仓库返回的未授权错误信息，所述未授权错误信息的响应头中包含认证方法提示信息；之后，解析所述未授权错误信息，并根据认证方法提示信息生成权限认证请求发送给令牌服务器进行权限认证；之后，接收令牌服务器返回的令牌，并携带所述令牌向镜像仓库发送访问请求；接收镜像仓库返回的镜像，即完成了私有Docker 镜像仓库的访问操作。本申请通过将权限认证交由第三方进行验证，根据请求令牌发放权限，提高了镜像的安全性。

Description

权限认证方法、系统、设备及计算机可读存储介质
本申请要求于2017年6月30日提交中国专利局、申请号为201710525379.1、发明名称为“Docker镜像仓库的权限认证方法和系统”的中国专利申请的优先权，其全部内容通过引用结合在申请中。
技术领域
本申请涉及Docker技术领域，具体涉及Docker镜像仓库的权限认证方法、系统、设备及计算机可读存储介质。
背景技术
Docker（Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化）提供的容器技术允许在同一台主机或虚拟机上运行若干个容器(container)，每个容器就是一个独立的虚拟环境或应用。
容器来源于Docker 镜像(image)，而镜像可以由用户自制(build)或由运行中的容器提交(commit)来生成，镜像生成后，可以推送(push)到镜像仓库(registry)中进行保存，也可以从镜像仓库拉取(pull)到本地以运行容器。
Docker 提供了官方镜像仓库(Docker hub)，同时允许用户自行搭建私有镜像仓库(private registry)。对于大多数机构和组织，使用私有镜像仓库是很有必要的，用以保护仓库的镜像内容及使用。
当用户访问Docker镜像时，针对不同镜像仓库内的镜像，需要细化访问权限控制。例如，对于公共镜像（即访问官方镜像仓库），任何用户都能够拉取(Pull)镜像，而只有系统管理员可以推送(Push)镜像；对于用户自己命名空间(Name space)下的镜像（即私有Docker 镜像仓库），只有通过了权限验证的该用户才能够拉取/推送镜像，即在访问时需要根据用户终端的身份判断有哪些仓库中的镜像可以拉取，或者可以往哪些仓库中推送镜像，能够提高镜像的安全性。
目前，Docker镜像服务器的权限设置比较简单，一般采用两种方式，第一种方式是只检查用户认证信息在请求时是否一并提供，并不验证其真假；第二种方式是配置静态的用户名与密码对，且需要预先生成密码文件，通过简单的用户登录就可以操作镜像服务。
可见上述两种方式的权限控制方式都不够安全，都不能满足镜像安全的要求。因此，现有技术还有待于改进和发展。
发明内容
针对现有技术的上述缺陷，本申请提供一种Docker镜像仓库的权限认证方法、系统、设备及计算机可读存储介质，主要解决现有Docker镜像访问不安全的问题。
本申请解决技术问题所采用的技术方案如下：
一种Docker镜像仓库的权限认证方法，包括如下步骤：
访问镜像仓库被拒绝时，接收镜像仓库返回的未授权错误信息，所述未授权错误信息的响应头中包含认证方法提示信息；
解析所述未授权错误信息，并根据认证方法提示信息生成权限认证请求发送给令牌服务器进行权限认证；
接收令牌服务器返回的令牌，并携带所述令牌向镜像仓库发送访问请求；
接收镜像仓库返回的镜像。
此外，为实现上述目的，本申请还提供一种Docker镜像仓库的权限认证系统，其包括权限认证设备；所述权限认证设备包括：
访问模块，用于访问镜像仓库；
接收模块，用于访问镜像仓库被拒绝时，接收镜像仓库返回的未授权错误信息，所述未授权错误信息的响应头中包含认证方法提示信息；
解析模块，用于解析所述未授权错误信息，并根据认证方法提示信息生成权限认证请求发送给令牌服务器进行权限认证；
此外，为实现上述目的，本申请还提供一种Docker镜像仓库的权限认证设备，其特征在于，所述Docker镜像仓库的权限认证设备包括存储器、处理器和存储在所述存储器上并可在所述处理器上运行的Docker镜像仓库的权限认证程序，所述Docker镜像仓库的权限认证程序被所述处理器执行时实现上述的Docker镜像仓库的权限认证方法的步骤。
此外，为实现上述目的，本申请还提供一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有Docker镜像仓库的权限认证程序，所述Docker镜像仓库的权限认证程序被处理器执行时实现上述的Docker镜像仓库的权限认证方法的步骤。
本申请公开了Docker镜像仓库的权限认证方法和系统，其权限认证方法先由访问镜像仓库被拒绝时，接收镜像仓库返回的未授权错误信息，所述未授权错误信息的响应头中包含认证方法提示信息；之后，解析所述未授权错误信息，并根据认证方法提示信息生成权限认证请求发送给令牌服务器进行权限认证；之后，接收令牌服务器返回的令牌，并携带所述令牌向镜像仓库发送访问请求；接收镜像仓库返回的镜像，即完成了私有Docker 镜像仓库的访问操作。本申请通过将权限认证交由第三方进行验证，根据请求令牌发放权限，提高了镜像的安全性。
附图说明
图1为本申请提供的Docker镜像仓库的权限认证方法的较佳实施例的流程图。
图2为本申请提供的Docker镜像仓库的权限认证方法中步骤S20的较佳实施例的流程图。
图3为本申请提供的Docker镜像仓库的权限认证方法中令牌的签名的方法流程示意图。
图4为本申请提供的Docker镜像仓库的权限认证方法中一应用实施例的示意图。
图5为本申请提供的Docker镜像仓库的权限认证系统较佳实施例的功能模块图。
图6为本申请提供的Docker镜像仓库的权限认证系统中权限认证设备的解析模块的功能模块图。
图7为本申请提供的Docker镜像仓库的权限认证系统中令牌服务器的令牌处理模块的功能模块图。
具体实施方式
本申请针对目前镜像权限管理的需求，将认证程序部署在各个镜像仓库中，利用镜像仓库指定外部令牌服务器为用户对私有Docker镜像仓库及其镜像的访问提供认证服务。每当镜像仓库接收到对镜像的访问请求时，指示客户端将用户信息、访问的镜像信息、访问动作发送至令牌服务器，令牌服务器根据用户信息决定是否授予用户所请求的访问权限。
具体为：如果访问的是公共镜像，且访问动作为拉取，则授权访问；如果用户信息通过了LDAP认证，且访问的镜像位于该用户的命名空间下，则授权访问；如果用户信息通过了LDAP认证，且是系统管理员，则授权访问；其他情况不授权，提高了镜像的安全性。本申请利用令牌服务器可以允许第三方更为复杂和完善的认证，同时认证可以结合数据库认证、配置认证、LDAP认证等方式，提供多种权限的灵活组合，具有更大的灵活性。
为使本申请的目的、技术方案及优点更加清楚、明确，以下参照附图并举实施例对本申请进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
请参阅图1，其为本申请提供的Docker镜像仓库的权限认证方法的较佳实施例的流程图。如图1所示，本申请较佳实施例所述的Docker镜像仓库的权限认证方法以下步骤：
S10、访问镜像仓库被拒绝时，接收镜像仓库返回的未授权错误信息，所述未授权错误信息的响应头中包含认证方法提示信息。
本实施例中，所述镜像仓库为私有Docker镜像仓库，在访问时，通过客户端使用登录Docker镜像仓库、推送docker镜像、拉取docker镜像等命令时，由docker客户端进程对镜像仓库发出请求。
在镜像仓库识别客户端为第一次访问时，向客户端返回未授权错误信息，并在授权错误信息的文件头中提示客户端认证的方法，提示客户端需要去令牌服务器中获取令牌。
S20、解析所述未授权错误信息，并根据认证方法提示信息生成权限认证请求发送给令牌服务器进行权限认证。
客户端收到未授权错误信息，首先对未授权错误信息解析获取认证方法提示信息，再根据认证方法的提示向令牌服务器请求令牌。请参阅图2，其为本申请提供的Docker镜像仓库的权限认证方法中步骤S20的较佳实施例的流程图。
如图2所示，所述步骤S20包括：
S21、解析所述未授权错误信息，获取未授权错误信息的响应头中包含认证方法提示信息；
S22、根据认证方法提示信息的提示，利用用户认证信息、请求镜像内容范围生成权限认证请求信息；
S23、将所述权限认证请求信息发送给令牌服务器。
在步骤S22中，在生成权限认证请求信息时，由docker客户端进程根据认证方法提示信息将用户认证信息加密，放在https请求的请求头部，将请求的镜像内容范围置于https请求的请求参数中，基于该https请求的请求头部及请求参数生成权限认证请求信息。
本实施例中，所述认证信息包括用户名和密码，具体实施时，先由docker客户端进程根据镜像仓库返回的提示，将用户的认证信息加密后放在https（Hypertext Transfer Protocol over Secure Socket Layer，是以安全为目标的HTTP通道，简单讲是HTTP的安全版）请求的AUTHORIZATION头部，同时将用户请求的镜像内容范围置于https请求的请求参数中，发送给令牌服务器，将权限认证工作交由令牌服务器处理。
S30、接收令牌服务器返回的令牌，并携带所述令牌向镜像仓库发送访问请求。
具体实施时，docker客户端进程拿到token(令牌)后，带令牌再次向镜像仓库请求相同的镜像内容。在镜像仓库收到令牌后对令牌进行解析，从而决定对用户的请求进行放行或阻挡。
较佳地，在令牌服务器收到权限认证请求信息之后，令牌服务器将执行如下动作：
首先、由令牌服务器解析所述权限认证请求信息，并验证用户认证信息；
接着、在用户认证通过时，根据请求的镜像内容范围判断客户端是否能访问其请求的镜像内容。在用户认证不能通过时返回错误令牌，告之客户端没有权限访问镜像仓库。
之后、当客户端能访问其请求的镜像内容时，根据用户认证信息、请求的镜像内容范围生成令牌返回给客户端。在用户认证信息通过验证，但客户端不能访问指定的镜像内容时，生成错误信息，返回给docker客户端进程，告之客户端没有权限访问其请求的内容。
由于Docker镜像仓库认可令牌格式为JWT(Json Web Token)格式，所述令牌包括头部、载荷和签名，并且头部、载荷、签名之间由小数点隔开。
具体而言，JWT格式的令牌由头部(header)、载荷(claim)及签名(signature)三部分组成，各段由"."（即小数点）符号分隔，token server(令牌服务器)按JWT格式生成令牌。
为了更好的理解本申请的令牌生成过程，以下对令牌的三个组成部分进行详细说明：
1）header（头部）
头部(header)包括令牌的类型、生成签名的算法（如RSS256算法）、密钥标识等。其中，密钥标识是一个由签名密钥的公共部分生成的唯一ID（identification identity，身份）。将DER加密的公钥截取240字节，分成12个base32的分组。
header 的格式为：
{
"typ": "JWT"，
"alg": "RS256"，
"kid": "ABCD:EFGH:IJKL:MNOP:QRST:UVWX:YZ12:3456:ABCD:EFGH:IJKL:MNOP"
}
其中：typ - type（类型），即token 的类型，此处为JWT。
alg - algorithm（算法），即生成签名的算法，此处为RS256算法。
kid - key id（密钥标识），它是一个由签名密钥的公共部分生成的唯一ID。通过将DER加密的公钥截取240字节，分成12个base32的分组，其生成的kid的格式为：ABCD:EFGH:IJKL:MNOP:QRST:UVWX:YZ12:3456:ABCD:EFGH:IJKL:MNOP。
2）claim（载荷）
载荷由主题、签发者、权限列表、超时时间、签发时间、起始时间和令牌的观察/查验者等组成。其中，权限列表为由具体涉及的权限组成的数组。每个权限的类型指明访问的类型（例如repository 代表镜像仓库），name 表示访问的对象名（如镜像仓库名称），actions 数组指定要进行的动作（如pull、push等）。
claim的格式为：
{
"sub": "mySubject"，
"iss": "token-server"，
"access": [
{
"type": "repository"，
"name": "official/tomcat"，
"actions": [
"pull"，"push"
]
}
]，
"exp": 1454289999，
"iat": 1454280000，
"nbf": 1454280000，
"aud": "registry-server"
}
其中：sub - subject（主题），即token 的主题。
iss - issuer（发行人），即token的签发者，此处为令牌服务器。
access - 权限列表，由具体涉及的权限组成的数组，每个access 的type 指明访问的类型（如repository 代表镜像仓库），name 表示访问的对象名（如仓库名称），actions 数组指定要进行的动作（如pull， push 等）。
exp - expiration（届期），即token的超时时间。
iat - issued at（发行时间），即token的签发时间。
nbf - not before（起始时间），即token 的起始时间，通常与iat 相等。
aud - audience（观众），即token 的观察者/查验者，此处为Docker镜像仓库。
3）signature（签名）
signature为使用私钥对JWT格式的令牌进行签名，如图4所示，所述签名的生成方法包括：S301、在头部和载荷中，去掉其格式中的非内容的空格符，分别对头部和载荷进行压缩；S302、采用编码器分别对压缩的头部和载荷进行编码；S303、将编码后的头部和载荷用小数点相连；S304、使用头部中指定的加密算法，利用私钥进行签名生成令牌的签名，作为令牌的第三段。
在步骤S301中，头部和载荷格式中的非内容的空格符，为头部和载荷组成部分中采用了“[ ]”前后的空格，即去掉空格符后不会影响头部和载荷各组成部分。
在步骤S302中，使用针对url（网页地址）的base64编码（Base64是网络上最常见的用于传输8Bit字节代码的编码方式之一）进行编码，分别得到编码后的头部和载荷。
基于上述令牌的生成方式，本申请在步骤S10之前，还可包括：将公钥置于镜像仓库中，用于生成令牌头部的密钥标识，将私钥置于令牌服务器中用于对令牌签名。
本申请在在使用令牌服务器之前，需要预先生成证书、私钥及公钥，用于使客户端实现令牌服务器与镜像仓库之间的通讯，具体将证书置于令牌服务器中，私钥用于令牌服务器对令牌签名，公钥用于生成令牌头部的kid。
其中，公钥私钥对借助openssl（安全套接字层密码库）生成，其生成的方法如下：
生成私钥及证书
openssl req -nodes -newkey rsa:4096 -keyout registry-auth.key -out root.crt -days 3650 -x509
-subj "/CN=caas-issuer"
使用私钥生成公钥，将其编码为DER格式
openssl rsa -in registry-auth.key -pubout -outform DER -out registry-auth.der
S40、接收镜像仓库返回的镜像。
在步骤S40之前，本申请的拉取镜像和推送镜像还包括：镜像仓库接收所述令牌，解析并验证所述令牌，在验证通过时，向客户端返回镜像。
在验证通过时，主要利用公钥验证令牌，及请求的请求的镜像内容范围是否与上一次相同，当二者均验证通过时，反正其请求的镜像。
本申请访问镜像仓库和令牌服务器的操作均通过Linux系统的用户终端完成，通过第三方进行权限认证的方式提高了Docker镜像的安全性。
为了节省网络资源，本申请对令牌服务器预先进行了权限控制，对客户端发送的权限认证请求中，https请求头中不包含用户认证信息的令牌请求一律拒绝。
此外，令牌服务器对仓库访问的请求根据仓库名前缀进行了分类处理，提高了工作效率，具体分类包括：
官方仓库：以official（官方的）/或library（图书馆、文库等）/开头的官方公共仓库，如official/tomcat（服务器），任何用户都可以拉取镜像，但只有管理员可以拉取镜像和推送镜像。
用户仓库：以用户名开头的仓库，如zhangsan001/tomcat，任何用户都可以拉取镜像，但只有该用户自己(如zhangsan001)可以推送镜像。
其它仓库：只有管理员可以拉取镜像和推送镜像，此类仓库通常存放一些内部镜像。
更进一步地，在令牌服务器中验证客户端的身份时，也借助外部LDAP（Lightweight Directory Access Protocol，轻量目录访问协议）进行验证。在验证时，通常只需要验证用户名是否存在、及密码是否正确，但也可以验证用户的某种权限或身份，从而决定是否授予令牌。
在采用LDAP验证时，令牌服务器验证用户身份的方式包括：令牌服务器解析所述权限认证请求信息，并验证用户认证信息；之后，将用户认证信息发送给LDAP服务器进行用户的身份及权限的验证；在LDAP服务器判断认证通过时，令牌服务器为客户端生成令牌，并将令牌返回给客户端。
为了便于更好的理解Docker镜像仓库的权限认证方法，以下例举一应用实施例对本申请的Docker镜像仓库的权限认证方法进行详细说明：
如图4所示，本应用实施例提供的Docker镜像仓库的权限认证方法包括：
第一步、客户端使用docker login、docker push、docker pull 等命令时，均由客户端的docker客户端进程对镜像仓库发出请求；
第二步、镜像仓库接到请求后，向客户端返回未授权错误信息，所述未授权错误信息的响应头中包含提示客户端认证的方法；
第三步、docker客户端进程根据提示将用户的认证信息加密后放在https 请求的AUTHORIZATION 头部，同时将用户请求的内容范围置于请求参数中，发送给令牌服务器；
第四步、令牌服务器解析并验证用户认证令牌及请求镜像内容范围，在验证通过将相应的令牌发送给客户端。
第五步、docker客户端进程拿到令牌 后，带着令牌再次向镜像仓库请求相同的内容；
第六步、镜像仓库拿到令牌后，对令牌进行解析和验证，在验证通过时docker客户端进程返回相应的镜像。
2VIP及端口将镜像推送送AVIP及端口和BVIP及端口。
基于上述Docker镜像仓库的权限认证方法，本申请还提供了一种Docker镜像仓库的权限认证系统，如图5所示，所述权限认证系统包括权限认证设备，所述权限认证设备可认为是一种Docker客户端，其包括：访问模块21、接收模块22、解析模块23和权限认证请求模块24。本申请所称的模块是指能够完成特定功能的一系列计算机程序指令段，比程序更适合于描述所述Docker镜像仓库的权限认证程序在所述Docker客户端中的执行过程。以下描述将具体介绍所述模块21-24的功能。
访问模块21，用于访问镜像仓库；
接收模块22，用于访问镜像仓库被拒绝时，接收镜像仓库返回的未授权错误信息，所述未授权错误信息的响应头中包含认证方法提示信息；
解析模块23，用于解析所述未授权错误信息，并根据认证方法提示信息生成权限认证请求发送给令牌服务器进行权限认证；
所述接收模块22，也用于接收令牌服务器返回的令牌；
权限认证请求模块24，用于携带所述令牌向镜像仓库发送访问请求；
所述接收模块22，还用于接收镜像仓库返回的镜像。
请一并参阅图5和图6，在具体实施时，所述解析模块23包括：
解析单元231，用于解析所述未授权错误信息，获取未授权错误信息的响应头中包含认证方法提示信息；
请求信息生成单元232，用于根据认证方法提示信息的提示，利用用户认证信息、请求镜像内容范围生成权限认证请求信息；
发送单元233，用于将所述权限认证请求信息发送给令牌服务器。
其中，所述请求信息生成单元232，具体用于根据认证方法提示信息将用户认证信息加密，放在https请求的请求头部，将请求的镜像内容范围置于https请求的请求参数中，基于该https请求的请求头部及请求参数生成权限认证请求信息。
请继续参阅图5，本申请的Docker镜像仓库的权限认证系统中还包括令牌服务器，所述令牌服务器与权限认证设备进行信息交互，用于生成Docker权限认证的令牌，其包括所述令牌服务器包括：验证模块、判断模块和令牌处理模块。
所述验证模块31，用于令牌服务器解析所述权限认证请求信息，并验证用户认证信息；
所述判断模块32，用于在用户认证通过时，根据请求的镜像内容范围判断客户端是否能访问其请求的镜像内容；
所述令牌处理模块33，用于当客户端能访问其请求的镜像内容时，根据用户认证信息、请求的镜像内容范围生成令牌返回给客户端。
其中，所述令牌包括头部、载荷和签名，头部、载荷、签名之间由小数点隔开。
请一并参阅图5和图7，所述令牌处理模块33包括签名处理单元331，用于生成令牌的签名，具体包括：在头部和载荷中，去掉其格式中的非内容的空格符，分别对头部和载荷进行压缩；采用编码器分别对压缩的头部和载荷进行编码；将编码后的头部和载荷用小数点相连；使用头部中指定的加密算法，利用私钥进行签名生成令牌的签名，作为令牌的第三段。
令牌处理模块33包括签名单元332，用于将公钥置于镜像仓库中，来生成令牌头部的密钥标识，将私钥置于令牌服务器中用于对令牌签名。
请继续参阅图5，本申请的Docker镜像仓库的权限认证系统还包括镜像仓库，用于接收所述令牌，解析并验证所述令牌，在验证通过时，向客户端返回镜像。
所述镜像仓库还用于将公钥置于镜像仓库中，用于生成令牌头部的密钥标识，将私钥置于令牌服务器中用于对令牌签名。
综上所述，本申请通过将权限认证交由第三方进行验证，根据请求令牌发放权限，提高了镜像的安全性。本申请利用令牌服务器可以允许第三方更为复杂和完善的认证，同时认证可以结合数据库认证、配置认证、LDAP认证等方式，提供多种权限的灵活组合，具有更大的灵活性。
当然，本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关硬件（如处理器，控制器等）来完成，所述的程序可存储于一计算机可读取的存储介质中，该程序在执行时可包括如上述各方法实施例的流程。其中所述的存储介质可为存储器、磁碟、光盘等。
应当理解的是，本申请的应用不限于上述的举例，对本领域普通技术人员来说，可以根据上述说明加以改进或变换，所有这些改进和变换都应属于本申请所附权利要求的保护范围。

Claims (20)

  1. 一种Docker镜像仓库的权限认证方法，其特征在于，所述权限认证方法包括如下步骤：
    访问镜像仓库被拒绝时，接收镜像仓库返回的未授权错误信息，所述未授权错误信息的响应头中包含认证方法提示信息；
    解析所述未授权错误信息，并根据认证方法提示信息生成权限认证请求发送给令牌服务器进行权限认证；
    接收令牌服务器返回的令牌，并携带所述令牌向镜像仓库发送访问请求；
    接收镜像仓库返回的镜像。
  2. 根据权利要求1所述的Docker镜像仓库的权限认证方法，其特征在于，所述解析所述未授权错误信息，并根据认证方法提示信息生成权限认证请求发送给令牌服务器进行权限认证的步骤包括：
    解析所述未授权错误信息，获取未授权错误信息的响应头中包含认证方法提示信息；
    根据认证方法提示信息的提示，利用用户认证信息、请求镜像内容范围生成权限认证请求信息；
    将所述权限认证请求信息发送给令牌服务器。
  3. 根据权利要求2所述的Docker镜像仓库的权限认证方法，其特征在于，所述根据认证方法提示信息的提示，利用用户认证信息、请求镜像内容范围生成权限认证请求信息的步骤包括：
    根据认证方法提示信息将用户认证信息加密，放在https请求的请求头部，将请求的镜像内容范围置于https请求的请求参数中，基于该https请求的请求头部及请求参数生成权限认证请求信息。
  4. 根据权利要求2所述的Docker镜像仓库的权限认证方法，其特征在于，在将所述权限认证请求信息发送给令牌服务器的步骤之后、接收令牌服务器返回的令牌，并携带所述令牌向镜像仓库发送访问请求的步骤之前，所述权限认证方法还包括：
    令牌服务器解析所述权限认证请求信息，并验证用户认证信息；
    在用户认证通过时，根据请求的镜像内容范围判断客户端是否能访问其请求的镜像内容；
    当客户端能访问其请求的镜像内容时，根据用户认证信息、请求的镜像内容范围生成令牌返回给客户端。
  5. 根据权利要求1所述的Docker镜像仓库的权限认证方法，其特征在于，在接收令牌服务器返回的令牌，并携带所述令牌向镜像仓库发送访问请求的步骤之后、接收镜像仓库返回的镜像的步骤之前，还包括：
    镜像仓库接收所述令牌，解析并验证所述令牌，在验证通过时，向客户端返回镜像。
  6. 根据权利要求1所述的Docker镜像仓库的权限认证方法，其特征在于，所述令牌包括头部、载荷和签名；所述签名的生成方法包括：
    在头部和载荷中，去掉其格式中的非内容的空格符，分别对头部和载荷进行压缩；
    采用编码器分别对压缩的头部和载荷进行编码；
    将编码后的头部和载荷用小数点相连；
    使用头部中指定的加密算法，利用私钥进行签名生成令牌的签名。
  7. 根据权利要求1所述的Docker镜像仓库的权限认证方法，其特征在于，所述访问镜像仓库被拒绝时，接收镜像仓库返回的未授权错误信息，所述未授权错误信息的响应头中包含认证方法提示信息的步骤之前，所述的权限认证方法还包括：
    将公钥置于镜像仓库中，用于生成令牌头部的密钥标识，将私钥置于令牌服务器中用于对令牌签名。
  8. 根据权利要求2所述的Docker镜像仓库的权限认证方法，其特征在于，所述访问镜像仓库被拒绝时，接收镜像仓库返回的未授权错误信息，所述未授权错误信息的响应头中包含认证方法提示信息的步骤之前，所述的权限认证方法还包括：
    将公钥置于镜像仓库中，用于生成令牌头部的密钥标识，将私钥置于令牌服务器中用于对令牌签名。
  9. 根据权利要求3所述的Docker镜像仓库的权限认证方法，其特征在于，所述访问镜像仓库被拒绝时，接收镜像仓库返回的未授权错误信息，所述未授权错误信息的响应头中包含认证方法提示信息的步骤之前，所述的权限认证方法还包括：
    将公钥置于镜像仓库中，用于生成令牌头部的密钥标识，将私钥置于令牌服务器中用于对令牌签名。
  10. 根据权利要求4所述的Docker镜像仓库的权限认证方法，其特征在于，所述访问镜像仓库被拒绝时，接收镜像仓库返回的未授权错误信息，所述未授权错误信息的响应头中包含认证方法提示信息的步骤之前，所述的权限认证方法还包括：
    将公钥置于镜像仓库中，用于生成令牌头部的密钥标识，将私钥置于令牌服务器中用于对令牌签名。
  11. 根据权利要求5所述的Docker镜像仓库的权限认证方法，其特征在于，所述访问镜像仓库被拒绝时，接收镜像仓库返回的未授权错误信息，所述未授权错误信息的响应头中包含认证方法提示信息的步骤之前，所述的权限认证方法还包括：
    将公钥置于镜像仓库中，用于生成令牌头部的密钥标识，将私钥置于令牌服务器中用于对令牌签名。
  12. 根据权利要求6所述的Docker镜像仓库的权限认证方法，其特征在于，所述访问镜像仓库被拒绝时，接收镜像仓库返回的未授权错误信息，所述未授权错误信息的响应头中包含认证方法提示信息的步骤之前，所述的权限认证方法还包括：
    将公钥置于镜像仓库中，用于生成令牌头部的密钥标识，将私钥置于令牌服务器中用于对令牌签名。
  13. 一种Docker镜像仓库的权限认证系统，其特征在于，包括权限认证设备；所述权限认证设备包括：
    访问模块，用于访问镜像仓库；
    接收模块，用于访问镜像仓库被拒绝时，接收镜像仓库返回的未授权错误信息，所述未授权错误信息的响应头中包含认证方法提示信息；
    解析模块，用于解析所述未授权错误信息，并根据认证方法提示信息生成权限认证请求发送给令牌服务器进行权限认证；
    所述接收模块，也用于接收令牌服务器返回的令牌；
    权限认证请求模块，用于携带所述令牌向镜像仓库发送访问请求；
    所述接收模块，还用于接收镜像仓库返回的镜像。
  14. 根据权利要求13所述的Docker镜像仓库的权限认证系统，其特征在于，所述解析模块还用于：
    解析所述未授权错误信息，获取未授权错误信息的响应头中包含认证方法提示信息；
    根据认证方法提示信息的提示，利用用户认证信息、请求镜像内容范围生成权限认证请求信息；
    将所述权限认证请求信息发送给令牌服务器。
  15. 根据权利要求14所述的Docker镜像仓库的权限认证系统，其特征在于，所述解析模块还用于：
    根据认证方法提示信息将用户认证信息加密，放在https请求的请求头部，将请求的镜像内容范围置于https请求的请求参数中，基于该https请求的请求头部及请求参数生成权限认证请求信息。
  16. 根据权利要求13所述的Docker镜像仓库的权限认证系统，其特征在于，还包括令牌服务器，所述令牌服务器包括：
    验证模块，用于解析所述权限认证请求信息，并验证用户认证信息；
    判断模块，用于在用户认证通过时，根据请求的镜像内容范围判断客户端是否能访问其请求的镜像内容；
    令牌处理模块，用于当客户端能访问其请求的镜像内容时，根据用户认证信息、请求的镜像内容范围生成令牌返回给客户端。
  17. 根据权利要求13所述的Docker镜像仓库的权限认证系统，其特征在于，还包括镜像仓库，用于接收所述令牌，解析并验证所述令牌，在验证通过时，向客户端返回镜像。
  18. 根据权利要求13所述的Docker镜像仓库的权限认证系统，其特征在于，所述权限认证设备包括：
    签名模块，用于将公钥置于镜像仓库中，用于生成令牌头部的密钥标识，将私钥置于令牌服务器中用于对令牌签名。
  19. 一种Docker镜像仓库的权限认证设备，其特征在于，所述Docker镜像仓库的权限认证设备包括存储器、处理器和存储在所述存储器上并可在所述处理器上运行的Docker镜像仓库的权限认证程序，所述Docker镜像仓库的权限认证程序被所述处理器执行时实现如权利要求1所述的Docker镜像仓库的权限认证方法的步骤。
  20. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有Docker镜像仓库的权限认证程序，所述Docker镜像仓库的权限认证程序被处理器执行时实现如权利要求1所述的Docker镜像仓库的权限认证方法的步骤。
PCT/CN2018/083842 2017-06-30 2018-04-20 权限认证方法、系统、设备及计算机可读存储介质 WO2019001110A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710525379.1 2017-06-30
CN201710525379.1A CN107239688B (zh) 2017-06-30 2017-06-30 Docker镜像仓库的权限认证方法和系统

Publications (1)

Publication Number Publication Date
WO2019001110A1 true WO2019001110A1 (zh) 2019-01-03

Family

ID=59990812

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/083842 WO2019001110A1 (zh) 2017-06-30 2018-04-20 权限认证方法、系统、设备及计算机可读存储介质

Country Status (2)

Country Link
CN (1) CN107239688B (zh)
WO (1) WO2019001110A1 (zh)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108011862A (zh) * 2016-10-31 2018-05-08 中兴通讯股份有限公司 镜像仓库授权、访问、管理方法及服务器和客户端
CN107239688B (zh) * 2017-06-30 2019-07-23 平安科技（深圳）有限公司 Docker镜像仓库的权限认证方法和系统
CN107786343A (zh) * 2017-10-27 2018-03-09 浪潮软件股份有限公司 一种私有镜像仓库的访问方法和系统
CN108200155A (zh) * 2017-12-29 2018-06-22 平安科技（深圳）有限公司 Docker镜像仓库的镜像同步方法和镜像同步系统
CN107948201B (zh) * 2017-12-29 2020-11-13 平安科技（深圳）有限公司 Docker镜像仓库的权限认证方法和系统
CN108241797A (zh) * 2018-01-10 2018-07-03 郑州云海信息技术有限公司 镜像仓库用户权限管理方法、装置、系统及可读存储介质
CN108245132B (zh) * 2018-01-15 2020-07-14 浙江大学 一种基于蓝牙的医疗可穿戴设备智能交互方法
CN108429638B (zh) * 2018-02-22 2021-12-10 北京奇艺世纪科技有限公司 一种服务器运维方法、装置、系统及电子设备
CN108549821B (zh) * 2018-04-02 2021-08-17 云知声智能科技股份有限公司 数据权限管理方法及系统
CN108512784A (zh) * 2018-06-21 2018-09-07 珠海宏桥高科技有限公司 基于网关路由转发的鉴权认证方法
CN109343934A (zh) * 2018-09-17 2019-02-15 北京北信源信息安全技术有限公司 一种基于容器的私服架构及其搭建和可视化方法
CN110069921B (zh) * 2019-04-12 2021-01-01 中国科学院信息工程研究所 一种面向容器平台的可信软件授权验证系统及方法
CN110138564B (zh) * 2019-04-22 2021-12-24 福建天晴数码有限公司 自编码器数据安全传输的方法、存储介质
CN111787116B (zh) * 2020-07-07 2021-08-20 上海道客网络科技有限公司 一种基于区块链技术的容器镜像可信认证的系统与方法
CN112667998B (zh) * 2020-12-08 2024-03-01 中国科学院信息工程研究所 一种容器镜像仓库的安全访问方法及系统
CN112860335B (zh) * 2021-01-25 2024-02-20 启明星辰信息技术集团股份有限公司 一种私有仓库Docker镜像信息采集系统及其采集方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104506510A (zh) * 2014-12-15 2015-04-08 百度在线网络技术（北京）有限公司 用于设备认证的方法、装置及认证服务系统
CN105653901A (zh) * 2015-12-29 2016-06-08 深圳市科漫达智能管理科技有限公司 一种组件仓库管理的方法及系统
US20170070504A1 (en) * 2015-09-03 2017-03-09 Vmware, Inc. Access control policy management in a cloud services environment
US20170177877A1 (en) * 2015-12-18 2017-06-22 Amazon Technologies, Inc. Software container registry inspection
CN107239688A (zh) * 2017-06-30 2017-10-10 平安科技（深圳）有限公司 Docker镜像仓库的权限认证方法和系统
CN108011862A (zh) * 2016-10-31 2018-05-08 中兴通讯股份有限公司 镜像仓库授权、访问、管理方法及服务器和客户端

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105069353B (zh) * 2015-08-11 2017-10-24 武汉大学 一种基于Docker的可信容器安全加固方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104506510A (zh) * 2014-12-15 2015-04-08 百度在线网络技术（北京）有限公司 用于设备认证的方法、装置及认证服务系统
US20170070504A1 (en) * 2015-09-03 2017-03-09 Vmware, Inc. Access control policy management in a cloud services environment
US20170177877A1 (en) * 2015-12-18 2017-06-22 Amazon Technologies, Inc. Software container registry inspection
CN105653901A (zh) * 2015-12-29 2016-06-08 深圳市科漫达智能管理科技有限公司 一种组件仓库管理的方法及系统
CN108011862A (zh) * 2016-10-31 2018-05-08 中兴通讯股份有限公司 镜像仓库授权、访问、管理方法及服务器和客户端
CN107239688A (zh) * 2017-06-30 2017-10-10 平安科技（深圳）有限公司 Docker镜像仓库的权限认证方法和系统

Also Published As

Publication number Publication date
CN107239688A (zh) 2017-10-10
CN107239688B (zh) 2019-07-23

Similar Documents

Publication Publication Date Title
WO2019001110A1 (zh) 权限认证方法、系统、设备及计算机可读存储介质
WO2015172684A1 (en) Ap connection method, terminal, and server
WO2011079753A1 (zh) 认证方法、认证交易系统和认证装置
WO2019205280A1 (zh) 服务器的测试方法、装置、设备及计算机可读存储介质
WO2016178548A1 (ko) 프로파일 제공 방법 및 장치
WO2013085281A1 (ko) 클라우딩 컴퓨팅 서비스에서의 보안을 위한 방법 및 장치
WO2014036977A1 (en) Data security management system
WO2017054481A1 (zh) 一种信息验证和处理方法、装置、以及信息处理系统
WO2016126052A2 (ko) 인증 방법 및 시스템
WO2016167536A1 (en) Method and apparatus for managing a profile of a terminal in a wireless communication system
WO2021167417A1 (en) Methods and systems for authenticating devices using 3gpp network access credentials for providing mec services
WO2016101745A1 (zh) 一种激活移动终端令牌的方法
WO2019100531A1 (zh) 数字签名生成、验证方法及其设备和存储介质
WO2011149214A2 (ko) 오티피를 생성하기 위해 홍채정보를 이용한 쓰리-팩터 사용자 인증방식과 무선통신단말기의 오티피 인증모듈을 이용한 안전한 상호인증시스템
WO2018082482A1 (zh) 一种网络共享方法、接入网络方法及系统
WO2016108468A1 (en) User terminal, service providing apparatus, driving method of user terminal, driving method of service providing apparatus, and encryption indexing-based search system
WO2020235782A1 (ko) 분산 환경에서의 신원 인증 방법
WO2015061992A1 (zh) 一种密钥配置方法、系统和装置
WO2017096599A1 (zh) 安全通信系统、方法及装置
WO2019037395A1 (zh) 密钥管理方法、装置及可读存储介质
WO2010124565A1 (zh) 签名方法、设备及系统
WO2015061941A1 (zh) 一种密钥配置方法和装置
EP3284274A1 (en) Method and apparatus for managing a profile of a terminal in a wireless communication system
WO2017035695A1 (zh) 信息传输方法及移动设备
WO2019196213A1 (zh) 接口测试方法、装置、设备及计算机可读存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18824552

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 17/04/2020)

122 Ep: pct application non-entry in european phase

Ref document number: 18824552

Country of ref document: EP

Kind code of ref document: A1