一 Kubetcl namespace

1.1 namespace描述

Kubernetes namespace提供了將一組相關資源組合在一起的機制。在Red Hat OpenShift容器平台中，project是一個帶有附加註釋的Kubernetes namespace。

namespace提供以下特性:

1. 命名資源，以避免基本的命名衝突；
2. 將管理權限授予受信任的用戶；
3. 限制用戶資源消耗的能力；
4. 用戶和用戶組隔離。

1.2 project

project提供了一種機制，通過這種機制可以管理普通用戶對資源的訪問。project允許一組用戶獨立於其他組組織和管理其內容，必須允許用戶訪問項目。如果允許創建項目，用戶將自動訪問自己的項目。

項目可以有單獨的name、display name和description。

name是項目的唯一標識符，在使用CLI工具或API時都是基於name，name的最大長度為63個字符。

display name是項目在web控制台中显示的方式(默認為name)。

description是項目的更詳細描述，並且在web控制台中也可見。

以下組件適用於項目:

• Object：pod、service、rc等；
• Policies：決定用戶可以或不能對對象執行哪些操作的規則；
• Constraints：可以限制的每種對象的配額。

1.3 cluster管理

集群管理員可以創建項目並將項目的管理權限委託給任何用戶。在OpenShift容器平台中，項目用於對相關對象進行分組和隔離。

管理員可以讓用戶訪問某些項目，允許他們創建自己的項目，並在單個項目中賦予他們管理權限。

管理員可以將角色應用於允許或限制其創建項目能力的用戶和組，同時可以在用戶初始登錄之前分配角色。

限制項目創建：從通過身份驗證的用戶和組中刪除self-provisioning集群角色，將拒絕任何新項目的權限。

[root@master ~]$ oc adm policy remove-cluster-role-from-group \

self-provisioner \

system:authenticated \

system:authenticated:oauth

授予項目創建：項目創建授予具有self-供應者角色和self-provisione集群角色綁定的用戶。默認情況下，所有經過身份驗證的用戶都可以使用這些角色。

[root@master ~]$ oc adm policy add-cluster-role-to-group \

self-provisioner \

system:authenticated \

system:authenticated:oauth

1.4 創建project

如果項目創建權限被授予用戶，則可以使用oc命令創建project。

[root@master ~]$ oc new-project demoproject \

–description=”Demonstrate project creation” \

–display-name=”demo_project”

二 OpenShift角色

2.1 角色概述

role具有不同級別的訪問和策略，包括集群和本地策略。user和group可以同時與多個role關聯。運行oc description命令查看角色及其綁定的詳細信息。

在集群策略中具有cluster-admin缺省角色的用戶可以查看集群策略和所有本地策略。在給定的本地策略中具有admin缺省角色的用戶可以基於per-project查看策略。

可通過以下命令查看當前的集群綁定集，其中显示綁定到不同角色的用戶和組。

[root@demo ~]# oc describe clusterPolicyBindings :default

2.2 查看本地policy

儘管本地角色列表及其關聯的規則集在本地策略中是不可查看的，但是所有缺省角色仍然適用，並且可以添加到用戶或組中，cluster-admin缺省角色除外。但是，本地綁定是可見的。

可通過以下命令查看當前的本地綁定，其中显示綁定到不同角色的用戶和組。

[root@demo ~]# oc describe policyBindings :default

提示：默認情況下，在本地策略中，只會列出admin角色的綁定。但是，如果將其他默認角色添加到本地策略中的用戶和組，也會列出它們。

2.3 管理role綁定

向用戶或組添加或綁定角色，從而實現向用戶或組提供角色授予的相關訪問權限。可以使用oc adm policy命令在用戶和組之間添加和刪除角色。

當使用以下操作管理本地策略的用戶和組角色時，可以使用-n選項指定項目。如果沒有指定，則使用當前項目。

常見管理本地策略操作：

命令	描述
oc adm policy who-can verb resource	設置哪些用戶可以對資源執行操作
oc adm policy add-role-to-user role username	將指定角色綁定到指定用戶
oc adm policy remove-role-from-user role username	從指定用戶中移除給定角色
oc adm policy remove-user username	刪除指定的用戶及其所有角色
oc adm policy add-role-to-group role groupname	將指定的角色綁定到指定的組
oc adm policy remove-role-fromgroup role groupname	從指定組中移除給定角色
oc adm policy remove-group groupname	刪除指定的組及其所有角色

還可以使用如下所示的的操作管理cluster policy的role binding，這類命令不需要-n選項，因為cluster policy不在namespace級別上操作。

常見管理cluster policy操作：

命令	描述
oc adm policy add-cluster-role-to-user role username	將集群中所有項目的指定角色綁定到指定用戶
oc adm policy remove-cluster-role-from-user role username	為集群中的所有項目從指定用戶中刪除指定角色
oc adm policy add-cluster-role-togroup role groupname	為集群中的所有項目將指定的角色綁定到指定的組
oc adm policy remove-cluster-role-from-group role groupname	從集群中所有項目的指定組中移除給定角色

提示：oc policy命令應用於當前項目，而oc adm policy命令應用於集群範圍的操作。

示例：在example項目中為developer用戶提供admin角色。

[root@demo ~]# oc adm policy add-role-to-user admin developer -n example

[root@demo ~]# oc describe policybindings :default -n example #檢查綁定

三 安全上下文約束（SCCS）

3.1 SCCS概述

OpenShift提供安全上下文約束(SCCS)，它控制pod可以執行的操作和它可以訪問的資源。默認情況下，任何容器的執行都只授予受限制的SCC定義的功能。

SCCS相關命令：

  1 [user@demo ~]$ oc get scc			                        #列出可用的SCC
  2 [user@demo ~]$ oc describe scc scc_name		                #現實特定SCC詳細信息
  3 [user@demo ~]$ oc adm policy add-scc-to-user scc_name user_name
  4 [user@demo ~]$ oc adm policy add-scc-to-group scc_name group_name	#要授予用戶或組特定的SCC
  5 [user@demo ~]$ oc adm policy remove-scc-from-user scc_name user_name
  6 [user@demo ~]$ oc adm policy remove-scc-from-group scc_name group_name	#從特定的SCC中刪除用戶或組

四 服務賬戶

4.1 服務賬戶

service account提供了一種靈活的方法來控制API訪問，而無需共享常規用戶的憑據。如果應用程序需要訪問受限制的SCC未授予的功能，可創建一個新的、特定的service account並將其添加到適當的SCC中。

例如，在缺省情況下，OpenShift不支持部署需要提升特權的應用程序。若有此需求，可創建一個service account，修改dc，然後添加service account至SCC。

示例：將anyuid配置為在容器中作為root用戶運行。

[user@demo ~]$ oc create serviceaccount useroot #創建一個名為useroot的新服務帳戶

[user@demo ~]$ oc patch dc/demo-app \

–patch ‘{“spec”:{“template”:{“spec”:{“serviceAccountName”: “useroot”}}}}’ #修改應用程序的DC

[user@demo ~]$ oc adm policy add-scc-to-user anyuid -z useroot #將useroot服務帳戶添加到anyuid SCC中，作為容器中的根用戶運行

4.2 Web管理user成員

OCP平台的默認配置是，在用戶首次登錄成功時，自動創建該用戶對象。

要管理允許訪問項目的用戶，請以項目管理員或集群管理員的身份登錄到web控制台，並選擇要管理的項目。在左側窗格中，單擊Resources——>membership進入項目member頁面。

在Users列中，在突出显示的文本框中輸入用戶名。在“添加另一個角色”列中，從用戶所在行的列表中選擇一個角色，然後單擊“添加”。

4.3 Cli管理user成員

CLI中如果自動創建對象功能被關閉，集群管理員可通過如下方式創建新用戶：

[root@master ~]$ oc create user demo-user

同時還需要在身份認證軟件中創建用戶，如為HTPasswdIdentityProvider才用戶命令如下：

[root@master ~]$ htpasswd /etc/origin/openshift-passwd demo-user

要向用戶添加項目角色，首先使用oc project命令輸入項目，然後使用oc policy add-role-to-user命令：

[root@master ~]$ oc policy add-role-to-user edit demo-user

要從用戶中刪除項目角色，使用oc policy remove-role-from-user命令：

[root@master ~]$ oc policy remove-role-from-user edit demo-user

並不是所有OpenShift角色都由項目限定範圍。要分配這些規則，請使用oc adm policy command命令。

[root@master ~]$ oc adm policy add-cluster-role-to-user cluster-admin admin

4.4 身份驗證和授權

身份驗證層標識與對OpenShift容器平台API的請求相關聯的用戶，然後授權層使用關於請求用戶的身份信息來確定是否應該允許該請求。

• user和group

OCP容器平台中的用戶是一個可以向OpenShift API發出請求的實體。通常，這表示與OpenShift交互的develop或administrator的帳戶。

可以將用戶分配給一個或多個組，每個組表示一組特定的角色(或權限)。當需要通過管理授權策略給多個客戶授權時候，group會比較合適。例如允許訪問項目中的對象，而不是單獨授予用戶。

• Authentication Tokens

API調用必須使用訪問令牌或X.509證書進行身份驗證，會話token表示用戶，並且是短期的，默認情況下在24小時內到期。

可以通過運行oc whoami命令來驗證經過身份驗證的用戶。

[root@master ~]$ oc login -u demo-user

[root@master ~]$ oc whoami

demo-user

4.5 身份驗證類型

本環境中，身份驗證由HTPasswdIdentityProvider模塊提供，該模塊根據使用htpasswd命令生成的文件驗證用戶名和密碼。

OpenShift容器平台支持的其他認證類型包括:

• Basic Authentication (Remote)

一種通用的後端集成機制，允許用戶使用針對遠程標識提供者驗證的憑據登錄到OpenShift容器平台。用戶將他們的用戶名和密碼發送到OpenShift容器平台，OpenShift平台通過到服務器的請求驗證這些憑據，並將憑據作為基本的Auth頭傳遞。這要求用戶在登錄過程中向OpenShift容器平台輸入他們的憑據。

• Request Header Authentication

用戶使用請求頭值(如X-RemoteUser)登錄到OpenShift容器平台。它通常與身份驗證代理結合使用，身份驗證代理對用戶進行身份驗證，然後通過請求頭值為OpenShift容器平台提供用戶標識。

• Keystone Authentication

Keystone是一個OpenStack項目，提供標識、令牌、目錄和策略服務。OpenShift容器平台與Keystone集成，通過配置OpenStack Keystone v3服務器將用戶存儲在內部數據庫中，從而支持共享身份驗證。這種配置允許用戶使用Keystone憑證登錄OpenShift容器平台。

• LDAP Authentication

用戶使用他們的LDAP憑證登錄到OpenShift容器平台。在身份驗證期間，LDAP目錄將搜索與提供的用戶名匹配的條目。如果找到匹配項，則嘗試使用條目的專有名稱(DN)和提供的密碼進行簡單綁定。

• GitHub Authentication

GitHub使用OAuth，它允許與OpenShift容器平台集成使用OAuth身份驗證來促進令牌交換流。這允許用戶使用他們的GitHub憑證登錄到OpenShift容器平台。為了防止使用GitHub用戶id的未授權用戶登錄到OpenShift容器平台集群，可以將訪問權限限制在特定的GitHub組織中。

五 管理項目及賬戶

5.1 前置準備

準備完整的OpenShift集群，參考《003.OpenShift網絡》2.1。

5.2 本練習準備

[student@workstation ~]$ lab secure-resources setup

5.3 創建htpasswd賬戶

  1 [kiosk@foundation0 ~]$ ssh root@master
  2 [root@master ~]# htpasswd -b /etc/origin/master/htpasswd user1 redhat
  3 [root@master ~]# htpasswd -b /etc/origin/master/htpasswd user2 redhat
  4 #添加基於htpasswd形式的user1和user2，密碼都為redhat。

5.4 設置策略

  1 [student@workstation ~]$ oc login -u admin -p redhat https://master.lab.example.com	#使用管理員登錄
  2 [student@workstation ~]$ oc adm policy remove-cluster-role-from-group \
  3 self-provisioner system:authenticated:oauth
  4 #刪除所有賦予普通創建項目的功能，該命令可參考本環境如下目錄中的命令。
  5 [student@workstation ~]$ cat /home/student/DO280/labs/secure-resources/configure-policy.sh
  6 #!/bin/bash
  7 oc adm policy remove-cluster-role-from-group \
  8     self-provisioner system:authenticated system:authenticated:oauth

5.5 驗證策略

  1 [student@workstation ~]$ oc login -u user1 -p redhat https://master.lab.example.com	#使用普通用戶user1登錄
  2 [student@workstation ~]$ oc new-project test					#測試創建project
  3 Error from server (Forbidden): You may not request a new project via this API.

5.6 創建項目

  1 [student@workstation ~]$ oc login -u admin -p redhat https://master.lab.example.com	#使用集群管理員登錄
  2 [student@workstation ~]$ oc new-project project-user1				#創建兩個項目
  3 [student@workstation ~]$ oc new-project project-user2

5.7 將項目與user關聯

  1 #選擇項目1
  2 Now using project "project-user1" on server "https://master.lab.example.com:443".
  3 [student@workstation ~]$ oc policy add-role-to-user admin user1		#將user1添加為項目1的管理員
  4 role "admin" added: "user1"
  5 [student@workstation ~]$ oc policy add-role-to-user edit user2		#將user2添加為項目1的開發員
  6 role "edit" added: "user2"
  7 
  8 [student@workstation ~]$ oc project project-user2			        #選擇項目2
  9 Now using project "project-user2" on server "https://master.lab.example.com:443".
 10 [student@workstation ~]$ oc policy add-role-to-user edit user2		#將user2添加為項目2的開發員
 11 role "edit" added: "user2"

5.8 驗證訪問

  1 [student@workstation ~]$ oc login -u user1 -p redhat https://master.lab.example.com	#使用user1登錄
  2 [student@workstation ~]$ oc project project-user1					#驗證項目1的訪問
  3 Already on project "project-user1" on server "https://master.lab.example.com:443".
  4 [student@workstation ~]$ oc project project-user2					#驗證項目2的訪問
  5 error: You are not a member of project "project-user2".
  6 You have one project on this server: project-user1
  7 
  8 [student@workstation ~]$ oc login -u user2 -p redhat https://master.lab.example.com	#使用user2登錄
  9 [student@workstation ~]$ oc project project-user1
 10 Already on project "project-user1" on server "https://master.lab.example.com:443".	#驗證項目1的訪問
 11 [student@workstation ~]$ oc project project-user2
 12 Now using project "project-user2" on server "https://master.lab.example.com:443".	#驗證項目2的訪問

5.9 部署特權應用

  1 [student@workstation ~]$ oc login -u user2 -p redhat https://master.lab.example.com
  2 [student@workstation ~]$ oc project project-user1
  3 Now using project "project-user1" on server "https://master.lab.example.com:443".
  4 [student@workstation ~]$ oc new-app --name=nginx --docker-image=registry.lab.example.com/nginx:latest
  5 #使用在項目1上不具備admin權限的用戶user2登錄，並部署應用，會出現如下提示：

5.10 驗證部署

  1 [student@workstation ~]$ oc get pods

結論：由上可知，部署失敗是因為容器映像需要root用戶，pod以CrashLoopBackOff或錯誤狀態結束。

5.11 故障排除

若要解決此故障需要減少特定項目的安全限制。

要使用特權訪問運行容器，可創建一個允許pod使用操作系統普通用戶運行的service account。

如下部分需要具有項目管理員特權的用戶執行，而另一些操作需要具有集群管理員特權的用戶執行。

本環境中，相關操作命令可以從/home/student/DO280/labs/secure-resources文件夾中的configure-sc.sh腳本運行或複製。

  1 [student@workstation ~]$ oc login -u user1 -p redhat https://master.lab.example.com	#使用項目1的admin賬戶登錄 
  2 [student@workstation ~]$ oc create serviceaccount useroot		  #創建服務賬戶
  3 serviceaccount "useroot" created
  4 [student@workstation ~]$ oc login -u admin -p redhat https://master.lab.example.com	#使用集群管理員登錄
  5 [student@workstation ~]$ oc project project-user1			  #選擇項目1
  6 Already on project "project-user1" on server "https://master.lab.example.com:443".
  7 [student@workstation ~]$ oc adm policy add-scc-to-user anyuid -z useroot  #設置SCC策略
  8 scc "anyuid" added to: ["system:serviceaccount:project-user1:useroot"]    #將服務帳戶與anyuid安全上下文關聯，此操作需要集群管理員用戶。
  9 [student@workstation ~]$ oc login -u user2 -p redhat https://master.lab.example.com	#切換user2用戶
 10 [student@workstation ~]$ oc project project-user1
 11 Already on project "project-user1" on server "https://master.lab.example.com:443".
 12 [student@workstation ~]$ oc patch dc nginx --patch='{"spec":{"template":{"spec":{"serviceAccountName": "useroot"}}}}'

#更新負責管理nginx的dc資源，任何開發人員用戶都可以執行此操作。本環境中，相關操作命令可以從/home/student/DO280/labs/secure-resources文件夾中的configure-sc.sh腳本運行或複製。

5.12 驗證確認

  1 [student@workstation ~]$ oc get pods
  2 NAME            READY     STATUS    RESTARTS   AGE
  3 nginx-2-98k8f   1/1       Running   0          3m
  4 

5.13 暴露服務

  1 [student@workstation ~]$ oc expose svc nginx
  2 route "nginx" exposed
  3 [student@workstation ~]$ oc get svc
  4 NAME      TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
  5 nginx     ClusterIP   172.30.118.63   <none>        80/TCP    13m
  6 [student@workstation ~]$ oc get route
  7 NAME      HOST/PORT                                  PATH      SERVICES   PORT      TERMINATION   WILDCARD
  8 nginx     nginx-project-user1.apps.lab.example.com             nginx      80-tcp                  None

5.14 測試訪問

  1 [student@workstation ~]$ curl -s http://nginx-project-user1.apps.lab.example.com

5.15 策略刪除演示

  1 [student@workstation ~]$ oc login -u admin -p redhat
  2 [student@workstation ~]$ oc adm policy add-cluster-role-to-group self-provisioner system:authenticated system:authenticated:oauth
  3 cluster role "self-provisioner" added: ["system:authenticated" "system:authenticated:oauth"]
  4 [student@workstation ~]$ oc delete project project-user1
  5 project "project-user1" deleted
  6 [student@workstation ~]$ oc delete project project-user2
  7 [root@master ~]# htpasswd -D /etc/origin/master/htpasswd user1 
  8 [root@master ~]# htpasswd -D /etc/origin/master/htpasswd user2

#為所有常規用戶重新啟用項目創建，即重置為初始狀態。本環境中，相關操作命令可以從/home/student/DO280/labs/secure-resources文件夾中的restore-policy.sh腳本運行或複製。

六 管理加密信息

6.1 secret特性

Secret對象類型提供了一種機制來保存敏感信息，如密碼、OCP客戶端配置文件、Docker配置文件和私有倉庫憑據。Secrets將敏感內容與Pod解耦。可以使用Volume插件將Secrets掛載到容器上，或者系統可以使用Secrets代表pod執行操作。

Secrets的主要特徵包括:

• Secrets data可以獨立於其定義引用。
• Secrets data Volume由臨時文件存儲支持。
• 可以在名稱空間中共享Secrets data。

6.2 創建Secrets

在依賴於該Secrets的pod之前創建一個Secrets。

  1 [user@demo ~]$ oc create secret generic secret_name \
  2 --from-literal=key1=secret1 \
  3 --from-literal=key2=secret2	#用secret data創建secret對象
  4 [user@demo ~]$ oc secrets add --for=mount serviceaccount/serviceaccount-name \
  5 secret/secret_name		#更新pod的服務帳戶，允許引用該secrets。

例如，允許一個運行在指定服務帳戶下的pod掛載一個secrets

創建一個pod，該pod使用環境變量或數據卷作為文件的方式使用該secret，通常使用模板完成。

6.3 使用secret暴露Pod

secrets可以作為數據卷掛載，也可以作為環境變量以便供pod中的容器使用。

例如，要向pod公開一個secrets，首先創建一個secrets並將username和password以k/v形式配置，然後將鍵名分配給pod的YAML文件env定義。

示例：創建名為demo-secret的secrets，它定義用戶名和密碼為username/demo-user。

[user@demo ~]$ oc create secret generic demo-secret \

–from-literal=username=demo-user

要使用前面的secret作為MySQL數據庫pod的數據庫管理員密碼，請定義環境變量，並引用secret名稱和密碼。

  1 env:
  2   - name: MYSQL_ROOT_PASSWORD
  3     valueFrom:
  4       secretKeyRef:
  5        key: username
  6        name: demo-secret

6.4 web端管理secret

從web控制台管理secret:

1. 以授權用戶身份登錄到web控制台。

2. 創建或選擇一個項目來承載secret。

3. 導航到resource——>secrets。

6.5 Secret使用場景

• password和user names

敏感信息(如password和user name)可以存儲在一個secret中，該secret被掛載為容器中的數據卷。數據显示為位於容器的數據卷目錄中的文件中的內容。然後，應用程序(如數據庫)可以使用這些secret對用戶進行身份驗證。

• 傳輸層安全性(TLS)和密鑰對

通過讓集群將簽名證書和密鑰對生成到項目名稱空間中的secret中，可以實現對服務的通信的保護。證書和密鑰對使用PEM格式存儲以類似tls.crt和tls.key的格式存儲在secret的pod中。

七 ConfigMap對象

7.1 ConfigMap概述

ConfigMaps對象類似於secret，但其設計目的是支持處理不包含敏感信息的字符串。ConfigMap對象持有配置數據的鍵值對，這些配置數據可以在pods中使用，或者用於存儲系統組件(如控制器)的配置數據。

ConfigMap對象提供了將配置數據注入容器的機制。ConfigMap存儲精細的粒度信息，比如單個屬性，或者詳細信息，比如整個配置文件或JSON blob。

7.2 CLI創建ConfigMap

可以使用–from-literal選項從CLI創建ConfigMap對象。

示例：創建一個ConfigMap對象，該對象將IP地址172.20.30.40分配給名為serverAddress的ConfigMap密鑰。

  1 [user@demo ~]$ oc create configmap special-config \
  2 --from-literal=serverAddress=172.20.30.40
  3 [user@demo ~]$ oc get configmaps special-config -o yaml		#查看configMap
  4 apiVersion: v1
  5 data:
  6   key1: serverAddress=172.20.30.40
  7 kind: ConfigMap
  8 metadata:
  9   creationTimestamp: 2017-07-10T17:13:31Z
 10   name: special-config
 11 ……
 12 在配置映射的pod定義中填充環境變量APISERVER。
 13 env:
 14   - name: APISERVER
 15       valueFrom:
 16         configMapKeyRef:
 17           name: special-config
 18           key: serverAddress

7.3 web管理ConfigMap

從web控制台管理ConfigMap對象:

1. 以授權用戶身份登錄到web控制台。

2. 創建或選擇一個項目來承載ConfigMap。

3. 導航到資源→配置映射。

八 加密練習

8.1 前置準備

準備完整的OpenShift集群，參考《003.OpenShift網絡》2.1。

8.2 本練習準備

[student@workstation ~]$ lab secure-secrets setup

8.3 創建項目

  1 [student@workstation ~]$ oc login -u developer -p redhat
  2 [student@workstation ~]$ cd /home/student/DO280/labs/secure-secrets/
  3 [student@workstation secure-secrets]$ less mysql-ephemeral.yml		#導入本環境MySQL模板

模板解讀：

該mysql-ephemeral.yml模板文件，包含openshift項目中的mysql臨時模板，pod所需的其他環境變量由模板參數初始化，並具有默認值。

但沒有secret定義，後續操作將手動創建模板所需的secret。

根據模板的要求，創建一個包含MySQL容器image使用的憑證的secret，將這個secret命名為mysql。

• 應用程序訪問的數據庫用戶名由database-user定義。
• 數據庫用戶的密碼由database-password定義。
• 數據庫管理員密碼由database-root-password定義

8.4 創建新secret

  1 [student@workstation secure-secrets]$ oc create secret generic mysql \
  2 --from-literal='database-user'='mysql' \
  3 --from-literal='database-password'='redhat' \
  4 --from-literal='database-root-password'='do280-admin'
  5 [student@workstation secure-secrets]$ oc get secret mysql -o yaml	#確認secret

8.5 創建應用

  1 [student@workstation secure-secrets]$ oc new-app --file=mysql-ephemeral.yml
  2 [student@workstation secure-secrets]$ oc get pods		#確認應用
  3 NAME            READY     STATUS    RESTARTS   AGE
  4 mysql-1-j4fnz   1/1       Running   0          1m

8.6 端口轉發

  1 [student@workstation secure-secrets]$ cd
  2 [student@workstation ~]$ oc port-forward mysql-1-j4fnz 3306:3306

提示：驗證完成之前forward不要關閉。

8.7 確認驗證

  1 [student@workstation ~]$ mysql -uroot -pdo280-admin -h127.0.0.1	#新開終端測試MySQL

九 管理security policy

9.1 OCP authorization授權

OCP定義了用戶可以執行的兩組主要操作：

與項目相關的操作(也稱為本地策略)：project-related

與管理相關的操作(也稱為集群策略)：administration-related

由於這兩種策略都有大量可用的操作，所以將一些操作分組並定義為角色。

默認角色	描述
cluster-admin	此角色中的所有用戶都可以管理OpenShift集群。
cluster-status	此角色中的所有用戶都提供對集群信息的只讀訪問。

為管理本地政策，OCP提供以下角色：

默認角色	描述
edit	角色中的用戶可以從項目中創建、更改和刪除公共應用程序資源，比如service和dc。 但是不能對限制範圍和配額等管理資源採取行動，也不能管理對項目的訪問權限。
basic-user	角色中的用戶具有對項目的讀訪問權。
self-provisioner	角色中的用戶可以創建新項目。這是一個集群角色，而不是項目角色。
admin	角色中的用戶可以管理項目中的所有資源，包括授予對項目的其他用戶的訪問權

除了能夠創建新應用程序之外，admin角色還允許用戶訪問項目資源，比如配額和限制範圍。

edit角色允許用戶在項目中充當開發人員，但要在項目管理員配置的約束下工作。

9.2 相關命令

  1 向集群用戶添加角色
  2 $ oc adm policy add-cluster-role-to-user cluster-role username
  3 示例：將普通用戶更改為集群管理員。
  4 $ oc adm policy add-cluster-role-to-user cluster-role username
  5 從用戶中刪除集群角色
  6 $ oc adm policy remove-cluster-role-from-user cluster-role username
  7 示例：將集群管理員更改為普通用戶。
  8 $ oc adm policy remove-cluster-role-from-user cluster-admin username
  9 將指定的用戶綁定到項目中的角色
 10 $ oc adm policy add-role-to-user role-name username -n project
 11 示例：在WordPress項目中dev用戶綁定basic-user角色。
 12 $ oc adm policy add-role-to-user basic-user dev -n wordpress

9.3 權限及規則

OpenShift將一組規則集合成一個角色，規則由謂詞和資源定義。如create user是OpenShift中的一條規則，它是一個名為cluster-admin的角色的所擁有的權限的一部分。

  1 $ oc adm policy who-can delete user

9.4 user類型

與OCP的交互基於用戶，OCP的user對象表示可以通過向該用戶或用戶組添加角色來從而實現相應權限的授予。

Regular users：通常以這種用戶類型與OCP交互，常規用戶用User對象表。例如，user1，user2。

System users：通常在安裝OCP中定義基礎設施時自動創建的，主要目的是使基礎設施能夠安全地與API交互。包括集群管理員(可以訪問所有內容)、每個節點的用戶、路由器和內部倉庫使用的用戶，以及各種其他用戶。還存在一個匿名系統用戶，默認情況下，該用戶用於未經身份驗證的請求。system user主要包括：system:admin、system:openshift-registry和system:node:node1.example.com。

Service accounts：這些是與項目關聯的特殊系統用戶。有些是在第一次創建項目時自動創建的，項目管理員可以創建多個，以便定義對每個項目內容的訪問。Service accounts由ServiceAccount對象表示。Service accounts主要包括：system:serviceaccount:default:deployer和system:serviceaccount:foo:builder。

每個用戶在訪問OpenShift容器平台之前必須進行身份驗證。沒有身份驗證或身份驗證無效的API請求將使用匿名系統用戶身份驗證來請求服務。身份驗證成功后，策略確定用戶被授權做什麼。

9.5 安全上下文約束（SCCS）

OpenShift提供了一種名為安全上下文約束的安全機制，它限制對資源的訪問，但不限制OpenShift中的操作。

SCC限制從OpenShift中運行的pod到主機環境的訪問：

• 運行特權容器
• 請求容器的額外功能
• 使用主機目錄作為卷
• 更改容器的SELinux上下文
• 更改用戶ID

社區開發的一些容器可能需要放鬆安全上下文約束，因為它們可能需要訪問默認禁止的資源，例如文件系統、套接字或訪問SELinux上下文。

OpenShift定義的安全上下文約束(SCCs)可以使用以下命令作為集群管理員列出。

$ oc get scc

SCC通常有以下7中SCCS：

• anyuid
• hostaccess
• hostmount-anyuid
• nonroot
• privileged
• restricted（默認）

$ oc describe scc anyuid #查看某一種SCC詳情

OpenShift創建的所有容器都使用restricted類型的SCC，它提供了對OpenShift外部資源的有限訪問。

對於anyuid安全上下文，run as user策略被定義為RunAsAny，表示pod可以作為容器中可用的任何用戶ID運行。這允許需要特定用戶使用特定用戶ID運行命令的容器。

要將容器更改為使用不同的SCC運行，需要創建綁定到pod的服務帳戶。

$ oc create serviceaccount service-account-name #首先創建服務賬戶

$ oc adm policy add-scc-to-user SCC -z service-account #將服務帳戶與SCC關聯

要確定哪個帳戶可以創建需要更高安全性要求的pod，可以使用scc-subject-review子命令。

$ oc export pod pod-name > output.yaml

$ oc adm policy scc-subject-review -f output.yaml

9.6 OpenShift與SELinux

OpenShift要求在每個主機上啟用SELinux，以便使用強制訪問控制提供對資源的安全訪問。同樣，由OpenShift管理的Docker容器需要管理SELinux上下文，以避免兼容性問題。

為了最小化在不支持SELinux的情況下運行容器的風險，可以創建SELinux上下文策略。

為了更新SELinux上下文，可以使用現有的SCC作為起點生成一個新的SCC。

$ oc export scc restricted > custom_selinux.yml #導出默認的SCC

編輯導出的YAML文件以更改SCC名稱和SELinux上下文。

$ oc create -f yaml_file #使用修改后的ymal重新創建一個SCC

9.7 特權容器

有些容器可能需要訪問主機的運行時環境。S2I構建器容器需要訪問宿主docker守護進程來構建和運行容器。

例如，S2I構建器容器是一類特權容器，它要求訪問超出其自身容器的限制。這些容器可能會帶來安全風險，因為它們可以使用OpenShift節點上的任何資源。通過創建具有特權訪問權的服務帳戶，可以使用SCCs啟用特權容器的訪問。

十 資源訪問控制綜合實驗

10.1 前置準備

準備完整的OpenShift集群，參考《003.OpenShift網絡》2.1。

10.2 本練習準備

  1 [student@workstation ~]$ lab secure-review setup

10.3 創建用戶

  1 [root@master ~]# htpasswd /etc/origin/master/htpasswd user-review
  2 New password: 【redhat】
  3 Re-type new password: 【redhat】

10.4 修改策略

  1 [student@workstation ~]$ oc login -u admin -p redhat
  2 [student@workstation ~]$ oc adm policy remove-cluster-role-from-group \
  3 self-provisioner system:authenticated system:authenticated:oauth
  4 禁用所有常規用戶的項目創建功能

10.5 確認驗證

  1 [student@workstation ~]$ oc login -u user-review -p redhat
  2 [student@workstation ~]$ oc new-project test			#普通用戶無法創建項目
  3 Error from server (Forbidden): You may not request a new project via this API.

10.6 創建項目

  1 [student@workstation ~]$ oc login -u admin -p redhat
  2 [student@workstation ~]$ oc new-project secure-review		#使用管理員創建項目

10.7 授權用戶

  1 [student@workstation ~]$ oc project secure-review
  2 Already on project "secure-review" on server "https://master.lab.example.com:443".
  3 [student@workstation ~]$ oc policy add-role-to-user edit user-review	#將edit的role和user-review進行關聯

10.8 測試訪問

  1 [student@workstation ~]$ oc login -u user-review -p redhat
  2 [student@workstation ~]$ oc project secure-review		#測試訪問
  3 Already on project "secure-review" on server "https://master.lab.example.com:443".

10.9 檢查模板

  1 [student@workstation ~]$ cd /home/student/DO280/labs/secure-review/
  2 [student@workstation secure-review]$ less mysql-ephemeral.yml

模板解讀：

該mysql-ephemeral.yml模板文件，包含openshift項目中的mysql臨時模板，pod所需的其他環境變量由模板參數初始化，並具有默認值。

但沒有secret定義，後續操作將手動創建模板所需的secret。

根據模板的要求，創建一個包含MySQL容器image使用的憑證的secret，將這個secret命名為mysql。

• 應用程序訪問的數據庫用戶名由database-user定義。
• 數據庫用戶的密碼由database-password定義。
• 數據庫管理員密碼由database-root-password定義

使用user-review developer用戶創建一個名為mysql的secret。這個secret應該存儲用戶名mysql、密碼redhat和數據庫管理員密碼do280-admin。

數據庫用戶名由database-user定義。此用戶的密碼由mysql secret密鑰定義。

數據庫管理員密碼由database-root-password定義。

10.10 創建secret

  1 [student@workstation secure-review]$ oc create secret generic mysql \
  2 --from-literal='database-user'='mysql' \
  3 --from-literal='database-password'='redhat' \
  4 --from-literal='database-root-password'='do280-admin'
  5 [student@workstation secure-review]$ oc get secret mysql -o yaml	#確認驗證secret

10.11 部署應用

  1 [student@workstation secure-review]$ oc new-app --file=mysql-ephemeral.yml
  2 [student@workstation secure-review]$ oc get pods
  3 NAME            READY     STATUS    RESTARTS   AGE
  4 mysql-1-2lr7t   1/1       Running   0          31s

10.12 轉發端口

  1 [student@workstation ~]$ oc port-forward mysql-1-2lr7t 3306:3306

10.13 測試訪問

  1 [student@workstation ~]$ mysql -umysql -predhat -h127.0.0.1

10.14 部署phpmyadmin應用

使用內部倉庫registry.lab.example.com的image部署phpmyadmin:4.7容器。phpmyadmin:4.7容器需要名為PMA_HOST的環境變量來提供MySQL服務器的IP地址。

使用模板創建一個基於FQND的MySQL pod的service。

為使用模板創建的MySQL服務器pod使用服務FQDN，該模板是mysql.secure-review.svc.cluster.local。

  1 [student@workstation ~]$ oc new-app --name=phpmyadmin \
  2 --docker-image=registry.lab.example.com/phpmyadmin/phpmyadmin:4.7 \
  3 -e PMA_HOST=mysql.secure-review.svc.cluster.local

結論：該命令會發出警告，提示需要root特權。默認情況下，OpenShift不支持使用操作系統的root用戶運行容器。

10.15 查看pod

  1 [student@workstation ~]$ oc get pods
  2 NAME                 READY     STATUS    RESTARTS   AGE
  3 mysql-1-2lr7t        1/1       Running   0          8m
  4 phpmyadmin-1-v7tl7   0/1       Error     2          1m
  5 因為沒有root權限，因此部署失敗，需要提權。

10.16 授予權限

  1 [student@workstation ~]$ oc login -u admin -p redhat			#使用管理員登錄
  2 [student@workstation ~]$ oc create serviceaccount phpmyadmin-account	#首先創建服務賬戶
  3 [student@workstation ~]$ oc adm policy add-scc-to-user anyuid -z phpmyadmin-account
  4 scc "anyuid" added to: ["system:serviceaccount:secure-review:phpmyadmin-account"]	#將服務帳戶與anyuid安全上下文關聯

10.17 更新應用

  1 [student@workstation ~]$ oc patch dc phpmyadmin --patch='{"spec":{"template":{"spec":{"serviceAccountName": "phpmyadmin-account"}}}}'

#更新負責管理phpmyadmin的dc資源，任何開發人員用戶都可以執行此操作。

本環境中，相關操作命令可以從/home/student/DO280/labs/secure-review文件夾中的patch-dc.sh腳本運行或複製。

10.18 確認驗證

  1 [student@workstation ~]$ oc login -u user-review -p redhat
  2 [student@workstation ~]$ oc get pods			#確認pod是否正常
  3 NAME                 READY     STATUS    RESTARTS   AGE
  4 mysql-1-2lr7t        1/1       Running   0          13m
  5 phpmyadmin-2-bdjvq   1/1       Running   0          1m

10.19 暴露服務

  1 [student@workstation ~]$ oc expose svc phpmyadmin --hostname=phpmyadmin.apps.lab.example.com

10.20 訪問測試

  1 [student@workstation ~]$ curl -s http://phpmyadmin.apps.lab.example.com

10.21 確認及刪除

  1 [student@workstation ~]$ lab secure-review grade		#環境腳本判斷
  2 [student@workstation ~]$ oc login -u admin -p redhat
  3 [student@workstation ~]$ oc adm policy add-cluster-role-to-group \
  4 self-provisioner system:authenticated system:authenticated:oauth
  5 [student@workstation ~]$ oc delete project secure-review
  6 [student@workstation ~]$ ssh root@master htpasswd -D \
  7 /etc/origin/master/htpasswd user-review			#刪除用戶
  8 [student@workstation ~]$ oc delete user user-review		#刪除項目

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!

前言

ZGC是一款在JDK11中新加入的具有實驗性質的低延遲垃圾收集器，目前僅支持Linux/x86-64。ZGC收集器是一款基於Region內存布局的，（暫時）不設分代的，使用了讀屏障、染色指針和內存多重映射等技術來實現可併發的標記-整理算法的，以低延遲為首要目標的一款垃圾收集器。

ZGC布局

與Shenandoah和G1一樣，ZGC也採取基於Region的堆內存布局，但與他們不同的是，ZGC的Region具有動態性（動態的創建和銷毀，以及動態的區域容量大小）。
ZGC的Region可以分為三類：

• 小型Region：容量固定為2MB，用於放置小於256KB的小對象。
• 中型Region：容量固定為32MB，用於放置大於等於256KB但小於4MB的對象。
• 大型Region：容量不固定，可以動態變化，但必須為2MB的整數倍，用於存放4MB或以上的大對象。並且每個大型Region只會存放一個對象。
  ZGC內存布局圖：

染色指針

HotSpot的垃圾收集器，有幾種不同的標記實現方案。

• 把標記直接記錄在對象頭上（Serial 收集器）。
• 把標記記錄在於對象相互獨立的數據結構上（G1、Shenandoah使用了一種相當於堆內存的1/64大小的，稱為BitMap的結構來記錄標記信息）。
• ZGC染色指針直接把標記信息記載引用對象的指針上。
  染色指針是一種直接將少量額外的信息存儲在指針上的技術。
  目前Linux下64位指針的高18位不能用來尋址，但剩餘的46位指針所能支持的64TB內存仍然鞥呢夠充分滿足大型服務器的需要。鑒於此，ZGC將其高4位提取出來存儲四個標誌信息。
  通過這些標誌虛擬機就可以直接從指針中看到器引用對象的三色標記狀態（Marked0、Marked1）、是否進入了重分配集（是否被移動過——Remapped）、是否只能通過finalize()方法才能被訪問到(Finalizable)。由於這些標誌位進一步壓縮了原本只有46位的地址空寂，導致ZGC能夠管理的內存不可以超過4TB。
  染色指針示意圖：

染色指針的優勢

• 染色指針可以使得一旦某個Region的存活對象被移走之後，這個Region立即就能夠被釋放和重用掉，而不必等待整個堆中所有指令向該Region的引用都被修正後才能清理。
• 染色指針可以大幅減少在垃圾收集過程中內存屏障的使用數量，設置內存屏障，尤其是在寫屏障的目的通常是為了記錄對象引用的變動情況，如果將這些信息直接維護在指針中，顯然就可以省去一些專門的記錄操作。
• 染色指針可以作為一種可擴展的存儲結構用來記錄更多與對象標記、重定位過程相關的數據，以便日後進一步提高性能。

內存多重映射

Linux/x86-64平台上ZGC使用了多重映射（Multi-Mapping）將多個不同的虛擬內存地址映射到同一物理內存地址上，這是一種多對一映射，意味着ZGC在虛擬內存中看到的地址空寂要比實際的堆內存容量來的更大。把染色指針中的標誌位看作是地址的分段符，那隻要將這些不同的地址段都映射到同一物理內褲空間，經過多重映射轉換后，就可以使用染色指針正常進行尋址了。
多重映射下的尋址：

ZGC的運作過程

ZGC的運作過程大致可劃分為以下四個大的階段。四個階段都是可以併發執行的，僅是兩個階段中間會存在短暫的停頓小階段。
運作過程如下：

• 併發標記（Concurrent Mark）： 與G1、Shenandoah一樣，併發標記是遍歷對象圖做可達性分析的階段，前後也要經過類似於G1、Shenandoah的初始標記、最終標記的短暫停頓，而且這些停頓階段所做的事情在目標上也是相類似的。
• 併發預備重分配（ Concurrent Prepare for Relocate）： 這個階段需要根據特定的查詢條件統計得出本次收集過程要清理哪些Region，將這些Region組成重分配集（Relocation Set）。
• 併發重分配（Concurrent Relocate）： 重分配是ZGC執行過程中的核心階段，這個過程要把重分配集中的存活對象複製到新的Region上，併為重分配集中的每個Region維護一個轉發表（Forward Table）,記錄從舊對象到新對象的轉向關係。
• 併發重映射（Concurrent Remap）： 重映射所做的就是修正整個堆中指向重分配集中舊對象的所有引用，ZGC的併發映射並不是以一個必須要“迫切”去完成的任務。ZGC很巧妙地把併發重映射階段要做的工作，合併到下一次垃圾收集循環中的併發標記階段里去完成，反正他們都是要遍歷所有對象的，這樣合併節省了一次遍歷的開銷。

ZGC的優劣勢

• 缺點：浮動垃圾
  當ZGC準備要對一個很大的堆做一次完整的併發收集，駕駛其全過程要持續十分鐘以上，由於應用的對象分配速率很高，將創造大量的新對象，這些新對象很難進入當次收集的標記範圍，通常就只能全部作為存活對象來看待（儘管其中絕大部分對象都是朝生夕滅），這就產生了大量的浮動垃圾。
  目前唯一的辦法就是盡可能地去增加堆容量大小，獲取更多喘息的時間。但若要從根本上解決，還是需要引入分代收集，讓新生對象都在一個專門的區域中創建，然後針對這個區域進行更頻繁、更快的收集。
• 優點：高吞吐量、低延遲。
  ZGC是支持“NUMA-Aware”的內存分配。MUMA（Non-Uniform Memory Access，非統一內存訪問架構）是一種多處理器或多核處理器計算機所設計的內存架構。
  現在多CPU插槽的服務器都是Numa架構，比如兩顆CPU插槽(24核)，64G內存的服務器，那其中一顆CPU上的12個核，訪問從屬於它的32G本地內存，要比訪問另外32G遠端內存要快得多。
  ZGC默認支持NUMA架構，在創建對象時，根據當前線程在哪個CPU執行，優先在靠近這個CPU的內存進行分配，這樣可以顯著的提高性能，在SPEC JBB 2005 基準測試里獲得40%的提升。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※想知道最厲害的網頁設計公司"嚨底家"!

※別再煩惱如何寫文案,掌握八大原則!

※產品缺大量曝光嗎?你需要的是一流包裝設計!

內容概要：

單一數據讀取方式：

　　第一種：slice_input_producer()

# 返回值可以直接通過 Session.run([images, labels])查看，且第一個參數必須放在列表中，如[...]

[images, labels] = tf.train.slice_input_producer([images, labels], num_epochs=None, shuffle=True)

　　第二種：string_input_producer()

# 需要定義文件讀取器，然後通過讀取器中的 read()方法來獲取數據（返回值類型 key,value），再通過 Session.run(value)查看

file_queue = tf.train.string_input_producer(filename, num_epochs=None, shuffle=True)

reader = tf.WholeFileReader()           # 定義文件讀取器

key, value = reader.read(file_queue)    # key：文件名；value：文件中的內容

　　！！！num_epochs=None，不指定迭代次數，這樣文件隊列中元素個數也不限定（None*數據集大小）。

　　！！！如果它不是None，則此函數創建本地計數器 epochs，需要使用local_variables_initializer()初始化局部變量

　　！！！以上兩種方法都可以生成文件名隊列。

（隨機）批量數據讀取方式：

batchsize=2　　# 每次讀取的樣本數量

tf.train.batch(tensors, batch_size=batchsize)

tf.train.shuffle_batch(tensors, batch_size=batchsize, capacity=batchsize*10, min_after_dequeue=batchsize*5) # capacity > min_after_dequeue

　　！！！以上所有讀取數據的方法，在Session.run()之前必須開啟文件隊列線程 tf.train.start_queue_runners()

 TFRecord文件的打包與讀取

 

 一、單一數據讀取方式

第一種：slice_input_producer()

def slice_input_producer(tensor_list, num_epochs=None, shuffle=True, seed=None, capacity=32, shared_name=None, name=None)

案例1：

import tensorflow as tf

images = ['image1.jpg', 'image2.jpg', 'image3.jpg', 'image4.jpg']
labels = [1, 2, 3, 4]

# [images, labels] = tf.train.slice_input_producer([images, labels], num_epochs=None, shuffle=True)

# 當num_epochs=2時，此時文件隊列中只有 2*4=8個樣本，所有在取第9個樣本時會出錯
# [images, labels] = tf.train.slice_input_producer([images, labels], num_epochs=2, shuffle=True)

data = tf.train.slice_input_producer([images, labels], num_epochs=None, shuffle=True)
print(type(data))   # <class 'list'>

with tf.Session() as sess:
    # sess.run(tf.local_variables_initializer())
    sess.run(tf.local_variables_initializer())
    coord = tf.train.Coordinator()  # 線程的協調器
    threads = tf.train.start_queue_runners(sess, coord)  # 開始在圖表中收集隊列運行器

    for i in range(10):
        print(sess.run(data))

    coord.request_stop()
    coord.join(threads)

"""
運行結果：
[b'image2.jpg', 2]
[b'image1.jpg', 1]
[b'image3.jpg', 3]
[b'image4.jpg', 4]
[b'image2.jpg', 2]
[b'image1.jpg', 1]
[b'image3.jpg', 3]
[b'image4.jpg', 4]
[b'image2.jpg', 2]
[b'image3.jpg', 3]
"""

　　！！！slice_input_producer() 中的第一個參數需要放在一個列表中，列表中的每個元素可以是 List 或 Tensor，如 [images，labels]，

　　！！！num_epochs設置

 

 第二種：string_input_producer()

def string_input_producer(string_tensor, num_epochs=None, shuffle=True, seed=None, capacity=32, shared_name=None, name=None, cancel_op=None)

文件讀取器

　　不同類型的文件對應不同的文件讀取器，我們稱為 reader對象；

　　該對象的 read 方法自動讀取文件，並創建數據隊列，輸出key/文件名，value/文件內容；

reader = tf.TextLineReader()      ### 一行一行讀取，適用於所有文本文件

reader = tf.TFRecordReader()      ### A Reader that outputs the records from a TFRecords file

reader = tf.WholeFileReader()     ### 一次讀取整個文件，適用圖片

 案例2：讀取csv文件

iimport tensorflow as tf

filename = ['data/A.csv', 'data/B.csv', 'data/C.csv']

file_queue = tf.train.string_input_producer(filename, shuffle=True, num_epochs=2)   # 生成文件名隊列
reader = tf.WholeFileReader()           # 定義文件讀取器（一次讀取整個文件）
# reader = tf.TextLineReader()            # 定義文件讀取器(一行一行的讀)
key, value = reader.read(file_queue)    # key：文件名；value：文件中的內容
print(type(file_queue))

init = [tf.global_variables_initializer(), tf.local_variables_initializer()]
with tf.Session() as sess:
    sess.run(init)
    coord = tf.train.Coordinator()
    threads = tf.train.start_queue_runners(sess=sess, coord=coord)
    try:
        while not coord.should_stop():
            for i in range(6):
                print(sess.run([key, value]))
            break
    except tf.errors.OutOfRangeError:
        print('read done')
    finally:
        coord.request_stop()
    coord.join(threads)

"""
reader = tf.WholeFileReader()           # 定義文件讀取器（一次讀取整個文件）
運行結果：
[b'data/C.csv', b'7.jpg,7\n8.jpg,8\n9.jpg,9\n']
[b'data/B.csv', b'4.jpg,4\n5.jpg,5\n6.jpg,6\n']
[b'data/A.csv', b'1.jpg,1\n2.jpg,2\n3.jpg,3\n']
[b'data/A.csv', b'1.jpg,1\n2.jpg,2\n3.jpg,3\n']
[b'data/B.csv', b'4.jpg,4\n5.jpg,5\n6.jpg,6\n']
[b'data/C.csv', b'7.jpg,7\n8.jpg,8\n9.jpg,9\n']
"""
"""
reader = tf.TextLineReader()           # 定義文件讀取器(一行一行的讀)
運行結果：
[b'data/B.csv:1', b'4.jpg,4']
[b'data/B.csv:2', b'5.jpg,5']
[b'data/B.csv:3', b'6.jpg,6']
[b'data/C.csv:1', b'7.jpg,7']
[b'data/C.csv:2', b'8.jpg,8']
[b'data/C.csv:3', b'9.jpg,9']
"""

案例3：讀取圖片（每次讀取全部圖片內容，不是一行一行）

import tensorflow as tf

filename = ['1.jpg', '2.jpg']
filename_queue = tf.train.string_input_producer(filename, shuffle=False, num_epochs=1)
reader = tf.WholeFileReader()              # 文件讀取器
key, value = reader.read(filename_queue)   # 讀取文件 key:文件名；value：圖片數據，bytes

with tf.Session() as sess:
    tf.local_variables_initializer().run()
    coord = tf.train.Coordinator()      # 線程的協調器
    threads = tf.train.start_queue_runners(sess, coord)

    for i in range(filename.__len__()):
        image_data = sess.run(value)
        with open('img_%d.jpg' % i, 'wb') as f:
            f.write(image_data)
    coord.request_stop()
    coord.join(threads)

 

 二、（隨機）批量數據讀取方式：

　　功能：shuffle_batch() 和 batch() 這兩個API都是從文件隊列中批量獲取數據，使用方式類似；

案例4：slice_input_producer() 與 batch()

import tensorflow as tf
import numpy as np

images = np.arange(20).reshape([10, 2])
label = np.asarray(range(0, 10))
images = tf.cast(images, tf.float32)　　# 可以註釋掉，不影響運行結果
label = tf.cast(label, tf.int32)　　　　 # 可以註釋掉，不影響運行結果

batchsize = 6   # 每次獲取元素的數量
input_queue = tf.train.slice_input_producer([images, label], num_epochs=None, shuffle=False)
image_batch, label_batch = tf.train.batch(input_queue, batch_size=batchsize)

# 隨機獲取 batchsize個元素，其中，capacity：隊列容量，這個參數一定要比 min_after_dequeue 大
# image_batch, label_batch = tf.train.shuffle_batch(input_queue, batch_size=batchsize, capacity=64, min_after_dequeue=10)

with tf.Session() as sess:
    coord = tf.train.Coordinator()      # 線程的協調器
    threads = tf.train.start_queue_runners(sess, coord)     # 開始在圖表中收集隊列運行器
    for cnt in range(2):
        print("第{}次獲取數據,每次batch={}...".format(cnt+1, batchsize))
        image_batch_v, label_batch_v = sess.run([image_batch, label_batch])
        print(image_batch_v, label_batch_v, label_batch_v.__len__())

    coord.request_stop()
    coord.join(threads)

"""
運行結果：
第1次獲取數據,每次batch=6...
[[ 0.  1.]
 [ 2.  3.]
 [ 4.  5.]
 [ 6.  7.]
 [ 8.  9.]
 [10. 11.]] [0 1 2 3 4 5] 6
第2次獲取數據,每次batch=6...
[[12. 13.]
 [14. 15.]
 [16. 17.]
 [18. 19.]
 [ 0.  1.]
 [ 2.  3.]] [6 7 8 9 0 1] 6
"""

 案例5：從本地批量的讀取圖片 — string_input_producer() 與 batch()

 1 import tensorflow as tf
 2 import glob
 3 import cv2 as cv
 4 
 5 def read_imgs(filename, picture_format, input_image_shape, batch_size=1):
 6     """
 7     從本地批量的讀取圖片
 8     :param filename: 圖片路徑（包括圖片的文件名），[]
 9     :param picture_format: 圖片的格式，如 bmp,jpg,png等; string
10     :param input_image_shape: 輸入圖像的大小; (h,w,c)或[]
11     :param batch_size: 每次從文件隊列中加載圖片的數量; int
12     :return: batch_size張圖片數據, Tensor
13     """
14     global new_img
15     # 創建文件隊列
16     file_queue = tf.train.string_input_producer(filename, num_epochs=1, shuffle=True)
17     # 創建文件讀取器
18     reader = tf.WholeFileReader()
19     # 讀取文件隊列中的文件
20     _, img_bytes = reader.read(file_queue)
21     # print(img_bytes)    # Tensor("ReaderReadV2_19:1", shape=(), dtype=string)
22     # 對圖片進行解碼
23     if picture_format == ".bmp":
24         new_img = tf.image.decode_bmp(img_bytes, channels=1)
25     elif picture_format == ".jpg":
26         new_img = tf.image.decode_jpeg(img_bytes, channels=3)
27     else:
28         pass
29     # 重新設置圖片的大小
30     # new_img = tf.image.resize_images(new_img, input_image_shape)
31     new_img = tf.reshape(new_img, input_image_shape)
32     # 設置圖片的數據類型
33     new_img = tf.image.convert_image_dtype(new_img, tf.uint8)
34 
35     # return new_img
36     return tf.train.batch([new_img], batch_size)
37 
38 
39 def main():
40     image_path = glob.glob(r'F:\demo\FaceRecognition\人臉庫\ORL\*.bmp')
41     image_batch = read_imgs(image_path, ".bmp", (112, 92, 1), 5)
42     print(type(image_batch))
43     # image_path = glob.glob(r'.\*.jpg')
44     # image_batch = read_imgs(image_path, ".jpg", (313, 500, 3), 1)
45 
46     sess = tf.Session()
47     sess.run(tf.local_variables_initializer())
48     tf.train.start_queue_runners(sess=sess)
49 
50     image_batch = sess.run(image_batch)
51     print(type(image_batch))    # <class 'numpy.ndarray'>
52 
53     for i in range(image_batch.__len__()):
54         cv.imshow("win_"+str(i), image_batch[i])
55     cv.waitKey()
56     cv.destroyAllWindows()
57 
58 def start():
59     image_path = glob.glob(r'F:\demo\FaceRecognition\人臉庫\ORL\*.bmp')
60     image_batch = read_imgs(image_path, ".bmp", (112, 92, 1), 5)
61     print(type(image_batch))    # <class 'tensorflow.python.framework.ops.Tensor'>
62 
63 
64     with tf.Session() as sess:
65         sess.run(tf.local_variables_initializer())
66         coord = tf.train.Coordinator()      # 線程的協調器
67         threads = tf.train.start_queue_runners(sess, coord)     # 開始在圖表中收集隊列運行器
68         image_batch = sess.run(image_batch)
69         print(type(image_batch))    # <class 'numpy.ndarray'>
70 
71         for i in range(image_batch.__len__()):
72             cv.imshow("win_"+str(i), image_batch[i])
73         cv.waitKey()
74         cv.destroyAllWindows()
75 
76         # 若使用 with 方式打開 Session，且沒加如下2行語句，則會出錯
77         # ERROR:tensorflow:Exception in QueueRunner: Enqueue operation was cancelled；
78         # 原因：文件隊列線程還處於工作狀態（隊列中還有圖片數據），而加載完batch_size張圖片會話就會自動關閉，同時關閉文件隊列線程
79         coord.request_stop()
80         coord.join(threads)
81 
82 
83 if __name__ == "__main__":
84     # main()
85     start()

從本地批量的讀取圖片案例

 

案列6：TFRecord文件打包與讀取

 1 def write_TFRecord(filename, data, labels, is_shuffler=True):
 2     """
 3     將數據打包成TFRecord格式
 4     :param filename: 打包後路徑名，默認在工程目錄下創建該文件；String
 5     :param data: 需要打包的文件路徑名；list
 6     :param labels: 對應文件的標籤；list
 7     :param is_shuffler:是否隨機初始化打包后的數據，默認：True；Bool
 8     :return: None
 9     """
10     im_data = list(data)
11     im_labels = list(labels)
12 
13     index = [i for i in range(im_data.__len__())]
14     if is_shuffler:
15         np.random.shuffle(index)
16 
17     # 創建寫入器，然後使用該對象寫入樣本example
18     writer = tf.python_io.TFRecordWriter(filename)
19     for i in range(im_data.__len__()):
20         im_d = im_data[index[i]]    # im_d:存放着第index[i]張圖片的路徑信息
21         im_l = im_labels[index[i]]  # im_l：存放着對應圖片的標籤信息
22 
23         # # 獲取當前的圖片數據  方式一：
24         # data = cv2.imread(im_d)
25         # # 創建樣本
26         # ex = tf.train.Example(
27         #     features=tf.train.Features(
28         #         feature={
29         #             "image": tf.train.Feature(
30         #                 bytes_list=tf.train.BytesList(
31         #                     value=[data.tobytes()])), # 需要打包成bytes類型
32         #             "label": tf.train.Feature(
33         #                 int64_list=tf.train.Int64List(
34         #                     value=[im_l])),
35         #         }
36         #     )
37         # )
38         # 獲取當前的圖片數據  方式二：相對於方式一，打包文件佔用空間小了一半多
39         data = tf.gfile.FastGFile(im_d, "rb").read()
40         ex = tf.train.Example(
41             features=tf.train.Features(
42                 feature={
43                     "image": tf.train.Feature(
44                         bytes_list=tf.train.BytesList(
45                             value=[data])), # 此時的data已經是bytes類型
46                     "label": tf.train.Feature(
47                         int64_list=tf.train.Int64List(
48                             value=[im_l])),
49                 }
50             )
51         )
52 
53         # 寫入將序列化之後的樣本
54         writer.write(ex.SerializeToString())
55     # 關閉寫入器
56     writer.close()

TFRecord文件打包案列

 

 1 import tensorflow as tf
 2 import cv2
 3 
 4 def read_TFRecord(file_list, batch_size=10):
 5     """
 6     讀取TFRecord文件
 7     :param file_list: 存放TFRecord的文件名，List
 8     :param batch_size: 每次讀取圖片的數量
 9     :return: 解析後圖片及對應的標籤
10     """
11     file_queue = tf.train.string_input_producer(file_list, num_epochs=None, shuffle=True)
12     reader = tf.TFRecordReader()
13     _, ex = reader.read(file_queue)
14     batch = tf.train.shuffle_batch([ex], batch_size, capacity=batch_size * 10, min_after_dequeue=batch_size * 5)
15 
16     feature = {
17         'image': tf.FixedLenFeature([], tf.string),
18         'label': tf.FixedLenFeature([], tf.int64)
19     }
20     example = tf.parse_example(batch, features=feature)
21 
22     images = tf.decode_raw(example['image'], tf.uint8)
23     images = tf.reshape(images, [-1, 32, 32, 3])
24 
25     return images, example['label']
26 
27 
28 
29 def main():
30     # filelist = ['data/train.tfrecord']
31     filelist = ['data/test.tfrecord']
32     images, labels = read_TFRecord(filelist, 2)
33     with tf.Session() as sess:
34         sess.run(tf.local_variables_initializer())
35         coord = tf.train.Coordinator()
36         threads = tf.train.start_queue_runners(sess=sess, coord=coord)
37 
38         try:
39             while not coord.should_stop():
40                 for i in range(1):
41                     image_bth, _ = sess.run([images, labels])
42                     print(_)
43 
44                     cv2.imshow("image_0", image_bth[0])
45                     cv2.imshow("image_1", image_bth[1])
46                 break
47         except tf.errors.OutOfRangeError:
48             print('read done')
49         finally:
50             coord.request_stop()
51         coord.join(threads)
52         cv2.waitKey(0)
53         cv2.destroyAllWindows()
54 
55 if __name__ == "__main__":
56     main()

TFReord文件的讀取案列

 

,

內容概要：

單一數據讀取方式：

　　第一種：slice_input_producer()

# 返回值可以直接通過 Session.run([images, labels])查看，且第一個參數必須放在列表中，如[...]

[images, labels] = tf.train.slice_input_producer([images, labels], num_epochs=None, shuffle=True)

　　第二種：string_input_producer()

# 需要定義文件讀取器，然後通過讀取器中的 read()方法來獲取數據（返回值類型 key,value），再通過 Session.run(value)查看

file_queue = tf.train.string_input_producer(filename, num_epochs=None, shuffle=True)

reader = tf.WholeFileReader()           # 定義文件讀取器

key, value = reader.read(file_queue)    # key：文件名；value：文件中的內容

　　！！！num_epochs=None，不指定迭代次數，這樣文件隊列中元素個數也不限定（None*數據集大小）。

　　！！！如果它不是None，則此函數創建本地計數器 epochs，需要使用local_variables_initializer()初始化局部變量

　　！！！以上兩種方法都可以生成文件名隊列。

（隨機）批量數據讀取方式：

batchsize=2　　# 每次讀取的樣本數量

tf.train.batch(tensors, batch_size=batchsize)

tf.train.shuffle_batch(tensors, batch_size=batchsize, capacity=batchsize*10, min_after_dequeue=batchsize*5) # capacity > min_after_dequeue

　　！！！以上所有讀取數據的方法，在Session.run()之前必須開啟文件隊列線程 tf.train.start_queue_runners()

 TFRecord文件的打包與讀取

 

 一、單一數據讀取方式

第一種：slice_input_producer()

def slice_input_producer(tensor_list, num_epochs=None, shuffle=True, seed=None, capacity=32, shared_name=None, name=None)

案例1：

import tensorflow as tf

images = ['image1.jpg', 'image2.jpg', 'image3.jpg', 'image4.jpg']
labels = [1, 2, 3, 4]

# [images, labels] = tf.train.slice_input_producer([images, labels], num_epochs=None, shuffle=True)

# 當num_epochs=2時，此時文件隊列中只有 2*4=8個樣本，所有在取第9個樣本時會出錯
# [images, labels] = tf.train.slice_input_producer([images, labels], num_epochs=2, shuffle=True)

data = tf.train.slice_input_producer([images, labels], num_epochs=None, shuffle=True)
print(type(data))   # <class 'list'>

with tf.Session() as sess:
    # sess.run(tf.local_variables_initializer())
    sess.run(tf.local_variables_initializer())
    coord = tf.train.Coordinator()  # 線程的協調器
    threads = tf.train.start_queue_runners(sess, coord)  # 開始在圖表中收集隊列運行器

    for i in range(10):
        print(sess.run(data))

    coord.request_stop()
    coord.join(threads)

"""
運行結果：
[b'image2.jpg', 2]
[b'image1.jpg', 1]
[b'image3.jpg', 3]
[b'image4.jpg', 4]
[b'image2.jpg', 2]
[b'image1.jpg', 1]
[b'image3.jpg', 3]
[b'image4.jpg', 4]
[b'image2.jpg', 2]
[b'image3.jpg', 3]
"""

　　！！！slice_input_producer() 中的第一個參數需要放在一個列表中，列表中的每個元素可以是 List 或 Tensor，如 [images，labels]，

　　！！！num_epochs設置

 

 第二種：string_input_producer()

def string_input_producer(string_tensor, num_epochs=None, shuffle=True, seed=None, capacity=32, shared_name=None, name=None, cancel_op=None)

文件讀取器

　　不同類型的文件對應不同的文件讀取器，我們稱為 reader對象；

　　該對象的 read 方法自動讀取文件，並創建數據隊列，輸出key/文件名，value/文件內容；

reader = tf.TextLineReader()      ### 一行一行讀取，適用於所有文本文件

reader = tf.TFRecordReader()      ### A Reader that outputs the records from a TFRecords file

reader = tf.WholeFileReader()     ### 一次讀取整個文件，適用圖片

 案例2：讀取csv文件

iimport tensorflow as tf

filename = ['data/A.csv', 'data/B.csv', 'data/C.csv']

file_queue = tf.train.string_input_producer(filename, shuffle=True, num_epochs=2)   # 生成文件名隊列
reader = tf.WholeFileReader()           # 定義文件讀取器（一次讀取整個文件）
# reader = tf.TextLineReader()            # 定義文件讀取器(一行一行的讀)
key, value = reader.read(file_queue)    # key：文件名；value：文件中的內容
print(type(file_queue))

init = [tf.global_variables_initializer(), tf.local_variables_initializer()]
with tf.Session() as sess:
    sess.run(init)
    coord = tf.train.Coordinator()
    threads = tf.train.start_queue_runners(sess=sess, coord=coord)
    try:
        while not coord.should_stop():
            for i in range(6):
                print(sess.run([key, value]))
            break
    except tf.errors.OutOfRangeError:
        print('read done')
    finally:
        coord.request_stop()
    coord.join(threads)

"""
reader = tf.WholeFileReader()           # 定義文件讀取器（一次讀取整個文件）
運行結果：
[b'data/C.csv', b'7.jpg,7\n8.jpg,8\n9.jpg,9\n']
[b'data/B.csv', b'4.jpg,4\n5.jpg,5\n6.jpg,6\n']
[b'data/A.csv', b'1.jpg,1\n2.jpg,2\n3.jpg,3\n']
[b'data/A.csv', b'1.jpg,1\n2.jpg,2\n3.jpg,3\n']
[b'data/B.csv', b'4.jpg,4\n5.jpg,5\n6.jpg,6\n']
[b'data/C.csv', b'7.jpg,7\n8.jpg,8\n9.jpg,9\n']
"""
"""
reader = tf.TextLineReader()           # 定義文件讀取器(一行一行的讀)
運行結果：
[b'data/B.csv:1', b'4.jpg,4']
[b'data/B.csv:2', b'5.jpg,5']
[b'data/B.csv:3', b'6.jpg,6']
[b'data/C.csv:1', b'7.jpg,7']
[b'data/C.csv:2', b'8.jpg,8']
[b'data/C.csv:3', b'9.jpg,9']
"""

案例3：讀取圖片（每次讀取全部圖片內容，不是一行一行）

import tensorflow as tf

filename = ['1.jpg', '2.jpg']
filename_queue = tf.train.string_input_producer(filename, shuffle=False, num_epochs=1)
reader = tf.WholeFileReader()              # 文件讀取器
key, value = reader.read(filename_queue)   # 讀取文件 key:文件名；value：圖片數據，bytes

with tf.Session() as sess:
    tf.local_variables_initializer().run()
    coord = tf.train.Coordinator()      # 線程的協調器
    threads = tf.train.start_queue_runners(sess, coord)

    for i in range(filename.__len__()):
        image_data = sess.run(value)
        with open('img_%d.jpg' % i, 'wb') as f:
            f.write(image_data)
    coord.request_stop()
    coord.join(threads)

 

 二、（隨機）批量數據讀取方式：

　　功能：shuffle_batch() 和 batch() 這兩個API都是從文件隊列中批量獲取數據，使用方式類似；

案例4：slice_input_producer() 與 batch()

import tensorflow as tf
import numpy as np

images = np.arange(20).reshape([10, 2])
label = np.asarray(range(0, 10))
images = tf.cast(images, tf.float32)　　# 可以註釋掉，不影響運行結果
label = tf.cast(label, tf.int32)　　　　 # 可以註釋掉，不影響運行結果

batchsize = 6   # 每次獲取元素的數量
input_queue = tf.train.slice_input_producer([images, label], num_epochs=None, shuffle=False)
image_batch, label_batch = tf.train.batch(input_queue, batch_size=batchsize)

# 隨機獲取 batchsize個元素，其中，capacity：隊列容量，這個參數一定要比 min_after_dequeue 大
# image_batch, label_batch = tf.train.shuffle_batch(input_queue, batch_size=batchsize, capacity=64, min_after_dequeue=10)

with tf.Session() as sess:
    coord = tf.train.Coordinator()      # 線程的協調器
    threads = tf.train.start_queue_runners(sess, coord)     # 開始在圖表中收集隊列運行器
    for cnt in range(2):
        print("第{}次獲取數據,每次batch={}...".format(cnt+1, batchsize))
        image_batch_v, label_batch_v = sess.run([image_batch, label_batch])
        print(image_batch_v, label_batch_v, label_batch_v.__len__())

    coord.request_stop()
    coord.join(threads)

"""
運行結果：
第1次獲取數據,每次batch=6...
[[ 0.  1.]
 [ 2.  3.]
 [ 4.  5.]
 [ 6.  7.]
 [ 8.  9.]
 [10. 11.]] [0 1 2 3 4 5] 6
第2次獲取數據,每次batch=6...
[[12. 13.]
 [14. 15.]
 [16. 17.]
 [18. 19.]
 [ 0.  1.]
 [ 2.  3.]] [6 7 8 9 0 1] 6
"""

 案例5：從本地批量的讀取圖片 — string_input_producer() 與 batch()

 1 import tensorflow as tf
 2 import glob
 3 import cv2 as cv
 4 
 5 def read_imgs(filename, picture_format, input_image_shape, batch_size=1):
 6     """
 7     從本地批量的讀取圖片
 8     :param filename: 圖片路徑（包括圖片的文件名），[]
 9     :param picture_format: 圖片的格式，如 bmp,jpg,png等; string
10     :param input_image_shape: 輸入圖像的大小; (h,w,c)或[]
11     :param batch_size: 每次從文件隊列中加載圖片的數量; int
12     :return: batch_size張圖片數據, Tensor
13     """
14     global new_img
15     # 創建文件隊列
16     file_queue = tf.train.string_input_producer(filename, num_epochs=1, shuffle=True)
17     # 創建文件讀取器
18     reader = tf.WholeFileReader()
19     # 讀取文件隊列中的文件
20     _, img_bytes = reader.read(file_queue)
21     # print(img_bytes)    # Tensor("ReaderReadV2_19:1", shape=(), dtype=string)
22     # 對圖片進行解碼
23     if picture_format == ".bmp":
24         new_img = tf.image.decode_bmp(img_bytes, channels=1)
25     elif picture_format == ".jpg":
26         new_img = tf.image.decode_jpeg(img_bytes, channels=3)
27     else:
28         pass
29     # 重新設置圖片的大小
30     # new_img = tf.image.resize_images(new_img, input_image_shape)
31     new_img = tf.reshape(new_img, input_image_shape)
32     # 設置圖片的數據類型
33     new_img = tf.image.convert_image_dtype(new_img, tf.uint8)
34 
35     # return new_img
36     return tf.train.batch([new_img], batch_size)
37 
38 
39 def main():
40     image_path = glob.glob(r'F:\demo\FaceRecognition\人臉庫\ORL\*.bmp')
41     image_batch = read_imgs(image_path, ".bmp", (112, 92, 1), 5)
42     print(type(image_batch))
43     # image_path = glob.glob(r'.\*.jpg')
44     # image_batch = read_imgs(image_path, ".jpg", (313, 500, 3), 1)
45 
46     sess = tf.Session()
47     sess.run(tf.local_variables_initializer())
48     tf.train.start_queue_runners(sess=sess)
49 
50     image_batch = sess.run(image_batch)
51     print(type(image_batch))    # <class 'numpy.ndarray'>
52 
53     for i in range(image_batch.__len__()):
54         cv.imshow("win_"+str(i), image_batch[i])
55     cv.waitKey()
56     cv.destroyAllWindows()
57 
58 def start():
59     image_path = glob.glob(r'F:\demo\FaceRecognition\人臉庫\ORL\*.bmp')
60     image_batch = read_imgs(image_path, ".bmp", (112, 92, 1), 5)
61     print(type(image_batch))    # <class 'tensorflow.python.framework.ops.Tensor'>
62 
63 
64     with tf.Session() as sess:
65         sess.run(tf.local_variables_initializer())
66         coord = tf.train.Coordinator()      # 線程的協調器
67         threads = tf.train.start_queue_runners(sess, coord)     # 開始在圖表中收集隊列運行器
68         image_batch = sess.run(image_batch)
69         print(type(image_batch))    # <class 'numpy.ndarray'>
70 
71         for i in range(image_batch.__len__()):
72             cv.imshow("win_"+str(i), image_batch[i])
73         cv.waitKey()
74         cv.destroyAllWindows()
75 
76         # 若使用 with 方式打開 Session，且沒加如下2行語句，則會出錯
77         # ERROR:tensorflow:Exception in QueueRunner: Enqueue operation was cancelled；
78         # 原因：文件隊列線程還處於工作狀態（隊列中還有圖片數據），而加載完batch_size張圖片會話就會自動關閉，同時關閉文件隊列線程
79         coord.request_stop()
80         coord.join(threads)
81 
82 
83 if __name__ == "__main__":
84     # main()
85     start()

從本地批量的讀取圖片案例

 

案列6：TFRecord文件打包與讀取

 1 def write_TFRecord(filename, data, labels, is_shuffler=True):
 2     """
 3     將數據打包成TFRecord格式
 4     :param filename: 打包後路徑名，默認在工程目錄下創建該文件；String
 5     :param data: 需要打包的文件路徑名；list
 6     :param labels: 對應文件的標籤；list
 7     :param is_shuffler:是否隨機初始化打包后的數據，默認：True；Bool
 8     :return: None
 9     """
10     im_data = list(data)
11     im_labels = list(labels)
12 
13     index = [i for i in range(im_data.__len__())]
14     if is_shuffler:
15         np.random.shuffle(index)
16 
17     # 創建寫入器，然後使用該對象寫入樣本example
18     writer = tf.python_io.TFRecordWriter(filename)
19     for i in range(im_data.__len__()):
20         im_d = im_data[index[i]]    # im_d:存放着第index[i]張圖片的路徑信息
21         im_l = im_labels[index[i]]  # im_l：存放着對應圖片的標籤信息
22 
23         # # 獲取當前的圖片數據  方式一：
24         # data = cv2.imread(im_d)
25         # # 創建樣本
26         # ex = tf.train.Example(
27         #     features=tf.train.Features(
28         #         feature={
29         #             "image": tf.train.Feature(
30         #                 bytes_list=tf.train.BytesList(
31         #                     value=[data.tobytes()])), # 需要打包成bytes類型
32         #             "label": tf.train.Feature(
33         #                 int64_list=tf.train.Int64List(
34         #                     value=[im_l])),
35         #         }
36         #     )
37         # )
38         # 獲取當前的圖片數據  方式二：相對於方式一，打包文件佔用空間小了一半多
39         data = tf.gfile.FastGFile(im_d, "rb").read()
40         ex = tf.train.Example(
41             features=tf.train.Features(
42                 feature={
43                     "image": tf.train.Feature(
44                         bytes_list=tf.train.BytesList(
45                             value=[data])), # 此時的data已經是bytes類型
46                     "label": tf.train.Feature(
47                         int64_list=tf.train.Int64List(
48                             value=[im_l])),
49                 }
50             )
51         )
52 
53         # 寫入將序列化之後的樣本
54         writer.write(ex.SerializeToString())
55     # 關閉寫入器
56     writer.close()

TFRecord文件打包案列

 

 1 import tensorflow as tf
 2 import cv2
 3 
 4 def read_TFRecord(file_list, batch_size=10):
 5     """
 6     讀取TFRecord文件
 7     :param file_list: 存放TFRecord的文件名，List
 8     :param batch_size: 每次讀取圖片的數量
 9     :return: 解析後圖片及對應的標籤
10     """
11     file_queue = tf.train.string_input_producer(file_list, num_epochs=None, shuffle=True)
12     reader = tf.TFRecordReader()
13     _, ex = reader.read(file_queue)
14     batch = tf.train.shuffle_batch([ex], batch_size, capacity=batch_size * 10, min_after_dequeue=batch_size * 5)
15 
16     feature = {
17         'image': tf.FixedLenFeature([], tf.string),
18         'label': tf.FixedLenFeature([], tf.int64)
19     }
20     example = tf.parse_example(batch, features=feature)
21 
22     images = tf.decode_raw(example['image'], tf.uint8)
23     images = tf.reshape(images, [-1, 32, 32, 3])
24 
25     return images, example['label']
26 
27 
28 
29 def main():
30     # filelist = ['data/train.tfrecord']
31     filelist = ['data/test.tfrecord']
32     images, labels = read_TFRecord(filelist, 2)
33     with tf.Session() as sess:
34         sess.run(tf.local_variables_initializer())
35         coord = tf.train.Coordinator()
36         threads = tf.train.start_queue_runners(sess=sess, coord=coord)
37 
38         try:
39             while not coord.should_stop():
40                 for i in range(1):
41                     image_bth, _ = sess.run([images, labels])
42                     print(_)
43 
44                     cv2.imshow("image_0", image_bth[0])
45                     cv2.imshow("image_1", image_bth[1])
46                 break
47         except tf.errors.OutOfRangeError:
48             print('read done')
49         finally:
50             coord.request_stop()
51         coord.join(threads)
52         cv2.waitKey(0)
53         cv2.destroyAllWindows()
54 
55 if __name__ == "__main__":
56     main()

TFReord文件的讀取案列

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!

目錄

• 前言
• 為什麼需要TLS協議
• 發展歷史
• 協議設計目標
• 記錄協議
  • 握手步驟
  • 握手協議
    • Hello Request
    • Client Hello
    • Server Hello
    • Certificate
    • Server Key Exchange
    • Certificate Request
    • Server Hello Done
    • Client Certificate
    • Client Key Exchange
    • Certificate Verify
    • Finished
  • 改變密碼標準協議
  • 警報協議
  • 應用程序數據協議
• 結語
• 參考文獻

前言

最近對TLS1.2協議處理流程進行了學習及實現，本篇文章對TLS1.2的理論知識和處理流程進行分析，TLS協議的實現建議直接看The Transport Layer Security (TLS) Protocol Version 1.2

為什麼需要TLS協議

通常我們使用TCP協議或UDP協議進行網絡通信。TCP協議提供一種面向連接的、可靠的字節流服務。但是TCP並不提供數據的加密，也不提供數據的合法性校驗。

我們通常可以對數據進行加密、簽名、摘要等操作來保證數據的安全。目前常見的加密方式有對稱加密和非對稱加密。使用對稱加密，雙方使用共享密鑰。

但是對於部署在互聯網上的服務，如果我們為每個客戶端都使用相同的對稱加密密鑰，那麼任何人都可以將數據解密，那麼數據的隱私性將得不到保障。

如果我們使用非對稱密鑰加密，客戶端使用服務端的公鑰進行公鑰加密，服務端在私鑰不泄露的情況下，只有服務端可以使用私鑰可以對數據進行解密，從而保障數據的隱私性，但是非對稱加密比對稱加密的成本高得多。

我們可以採用對稱加密和非對稱加密相結合的方式實現數據的隱私性的同時性能又不至於太差。

1. 首先客戶端和服務端通過一個稱為密鑰交換的流程進行密鑰協商及交換密鑰所系的信息。
2. 通過公鑰加密對稱密鑰保證對稱密鑰的安全傳輸。
3. 服務端使用私鑰解密出對稱密鑰。
4. 最後雙方使用協商好的對稱密鑰對數據進行加解密。

TLS協議就是實現了這一過程安全協議。TLS是在TCP之上，應用層之下實現的網絡安全方案。在TCP/IP四層網絡模型中屬於應用層協議。TLS協議在兩個通信應用程序之間提供數據保密性和數據完整性，另外還提供了連接身份可靠性方案。

UDP則使用DTLS協議實現安全傳輸，和TLS協議類似。

發展歷史

TLS協議的前身SSL協議是網景公司設計的主要用於Web的安全傳輸協議，這種協議在Web上獲得了廣泛的應用。

• 1994年，網景公司設計了SSL協議的1.0版，因為存在嚴重的安全漏洞，未公開。
• 2.0版本在1995年2月發布，但因為存在數個嚴重的安全漏洞(比如使用MD5摘要、握手消息沒有保護等)，2011年RFC 6176 標準棄用了SSL 2.0。
• 3.0版本在1996年發布，是由網景工程師完全重新設計的，同時寫入RFC，較新版本的SSL/TLS基於SSL 3.0。2015年，RFC 7568 標準棄用了SSL 3.0。
• 1999年，IETF將SSL標準化，並將其稱為TLS（Transport Layer Security）。從技術上講，TLS 1.0與SSL 3.0的差異非常微小。
• TLS 1.1在RFC 4346中定義，於2006年4月發表,主要修復了CBC模式的BEAST攻擊等漏洞。
  

  微軟、Google、蘋果、Mozilla四家瀏覽器業者將在2020年終止支持TLS 1.0及1.1版。

• TLS 1.2在RFC 5246中定義，於2008年8月發表，添加了增加AEAD加密算法，如支持GCM模式的AES。
• TLS 1.3在RFC 8446中定義，於2018年8月發表，砍掉了AEAD之外的加密方式。

協議設計目標

1. 加密安全：TLS應用於雙方之間建立安全連接，通過加密，簽名，數據摘要保障信息安全。
2. 互操作性：程序員在不清楚TLS協議的情況下，只要對端代碼符合RFC標準的情況下都可以實現互操作。
3. 可擴展性：在必要時可以通過擴展機制添加新的公鑰和機密方法，避免創建新協議。
4. 相對效率：加密需要佔用大量CPU，尤其是公鑰操作。TLS協議握手完成后，通過對稱密鑰加密數據。TLS還集成了會話緩存方案，減少需要從頭建立連接的情況。

記錄協議

TLS協議是一個分層協議，第一層為TLS記錄層協議(Record Layer Protocol)，該協議用於封裝各種高級協議。目前封裝了4種協議：握手協議（Handshake Protocol）、改變密碼標準協議（Change Cipher Spec Protocol）、應用程序數據協議（Application Data Protocol）和警報協議（Alert Protocol）。

Change Cipher Spec Protocol在TLS1.3被去除。

記錄層包含協議類型、版本號、長度、以及封裝的高層協議內容。記錄層頭部為固定5字節大小。

在TLS協議規定了，如接收到了未定義的協議協議類型，需要發送一個unexpected_message警報。

握手步驟

• 當客戶端連接到支持TLS協議的服務端要求創建安全連接並列出了受支持的算法套件（包括加密算法、散列算法等），握手開始。
• 服務端從客戶端的算法套件列表中指定自己支持的一個算法套件，並通知客戶端，若沒有則使用一個默認的算法套件。
• 服務端發回其数字證書，此證書通常包含服務端的名稱、受信任的證書頒發機構（CA）和服務端的公鑰。
• 客戶端確認其頒發的證書的有效性。
• 為了生成會話密鑰用於安全連接，客戶端使用服務端的公鑰加密隨機生成的密鑰，並將其發送到服務端，只有服務端才能使用自己的私鑰解密。
• 利用隨機數，雙方生成用於加密和解密的對稱密鑰。這就是TLS協議的握手，握手完畢后的連接是安全的，直到連接（被）關閉。如果上述任何一個步驟失敗，TLS握手過程就會失敗，並且斷開所有的連接。

握手協議

TLS 握手協議允許服務端和客戶端相互進行身份驗證，並在應用程序協議傳輸或接收其第一個字節數據之前協商協議版本、會話ID、壓縮方法、密鑰套件、以及加密密鑰。

完整的TLS握手流程，流程如下

  Client                                                       Server

  ClientHello                  -------->
                                                          ServerHello
                                                          Certificate*
                                                    ServerKeyExchange*
                                                  CertificateRequest*
                                <--------              ServerHelloDone
  Certificate*
  ClientKeyExchange
  CertificateVerify*
  [ChangeCipherSpec]
  Finished                     -------->
                                                    [ChangeCipherSpec]
                                <--------                     Finished
  Application Data             <------->             Application Data

• 表示可選步驟或與實際握手情況相關。比如重建已有連接，服務端無需執行Certificate，再比如使用RSA公鑰加密時，無需ServerKeyExchange。
  握手協議消息必須按上面流程的發送數據進行發送，否則需要以致命錯誤告知對方並關閉連接。

完整的握手流程有時候也被稱為2-RTT流程，即完整的握手流程需要客戶端和服務端交互2次才能完成握手。

交互應用請求到響應的交互時間被稱為往返時間(Round-trip Time)

握手協議的結構如下，其中協議頭的ContentType固定為22，接下來是TLS版本號，TLS1.2為0303，最後是用2字節表示長度。

握手協議類型包含以下：

• hello_request：0
• client_hello：1
• server_hello：2
• certificate：3
• server_key_exchange ：12
• certificate_request：13
• server_hello_done：14
• certificate_verify：15
• client_key_exchange：16
• finished：20

Hello Message是具體的握手協議類型內容，不同協議內容有所不同。

Hello Request

Hello Request消息用於客戶端與服務端重新協商握手，該消息可能由服務端在任何時刻發送。Hello Request消息非常簡單，沒有其他冗餘信息。

當客戶端收到了服務端的Hello Request時可以有以下4種行為：

• 當客戶端正在協商會話，可以忽略該消息。
• 若客戶端未在協商會話但不希望重新協商時，可以忽略該消息。
• 若客戶端未在協商會話但不希望重新協商時，可以發送no_renegotiation警報。
• 若客戶端希望重新協商會話，則需要發送ClientHello重新進行TLS握手。

服務端發送完HelloRequest消息，可以有以下幾種行為：

• 服務端發送了HelloRequest消息，但未收到ClientHello時，可以通過致命連接警報關閉連接。
• 服務端發送了HelloRequest消息，必須等待握手協商處理完成后才可以繼續處理應用數據消息。

Finished和Certificate的握手消息驗證不包括該消息的hash。

Client Hello

當客戶端首次與服務端建立連接或需要重新協商加密握手會話時，需要將Client Hello作為第一條消息發送給服務端。

Client Hello消息包含了許多重要信息，包括客戶端版本號、客戶端隨機數、會話ID、密鑰套件、壓縮方式、擴展字段等。

• 客戶端版本號：客戶端支持的最新TLS版本號，服務端會根據該協議號進行協議協商。
• 32位隨機數：客戶端生成的32位隨機數。前4位是Unix時間戳，該時間戳為1970年1月1日0點以來的秒數。不過TLS並沒有強制要求校驗該時間戳，因此允許定義為其他值。後面28位為一個隨機數。
  

  通過前4字節填寫時間方式，有效的避免了周期性的出現一樣的隨機數。使得”隨機”更加”隨機”。
  在TLS握手時，客戶端和服務端需要協商數據傳輸時的加密密鑰。為了保證加密密鑰的安全性。密鑰需要通過客戶端和服務端一起生成。客戶端和服務端都提供一個32位的隨機數，通過該隨機數使用基於HMAC的PRF算法生成客戶端和服務端的密鑰。

• 會話ID：用於表示客戶端和服務端之間的會話。實際的會話ID是由服務端定義的，因此即使是新的連接，服務端返回的會話ID可能也會和客戶端不一致，由於會話ID是明文傳輸的，因此不能存放機密信息。
  • 若會話ID是新的，則客戶端和服務端需要建立完整的TLS握手連接流程。
  • 若會話ID是較早連接的會話ID，則服務端可以選擇無需執行完整的握手協議。
• 算法套件：客戶端將支持的加密算法組合排列后發送給服務端，從而和服務端協商加密算法。服務端根據支持算法在ServerHello返回一個最合適的算法組合。
  算法套件的格式為TLS_密鑰交換算法_身份認證算法_WITH_對稱加密算法_消息摘要算法，比如TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,密鑰交換算法是DHE,身份認證算法是RSA,對稱加密算法是AES_256_CBC,消息摘要算法是SHA256，由於RSA又可以用於加密也可以用於身份認證，因此密鑰交換算法使用RSA時，只寫一個RSA,比如TLS_RSA_WITH_AES_256_CBC_SHA256
• 壓縮方式：用於和服務端協商數據傳輸的壓縮方式。由於TLS壓縮存在安全漏洞，因此在TLS1.3中已經將TLS壓縮功能去除，TLS1.2算法也建議不啟用壓縮功能。
• 擴展字段：可以在不改變底層協議的情況下，添加附加功能。客戶端使用擴展請求其他功能，服務端若不提供這些功能，客戶端可能會中止握手。對於擴展字段的詳細定義可以看Transport Layer Security (TLS) Extensions

客戶端發送完 ClientHello 消息后，將等待 ServerHello 消息。 服務端返回的任何握手消息（HelloRequest 除外）將被視為致命錯誤。

Server Hello

當服務端接收到ClientHello，則開始TLS握手流程， 服務端需要根據客戶端提供的加密套件，協商一個合適的算法簇，其中包括對稱加密算法、身份驗證算法、非對稱加密算法以及消息摘要算法。若服務端不能找到一個合適的算法簇匹配項，則會響應握手失敗的預警消息。

• 版本號：服務端根據客戶端發送的版本號返回一個服務端支持的最高版本號。若客戶端不支持服務端選擇的版本號，則客戶端必須發送protocol_version警報消息並關閉連接。

  若服務端接收到的版本號小於當前支持的最高版本，且服務端希望與舊客戶端協商，則返回不大於客戶端版本的服務端最高版本。
  若服務端僅支持大於client_version的版本，則必須發送protocol_version警報消息並關閉連接。
  若服務端收到的版本號大於服務端支持的最高版本的版本，則必須返回服務端所支持的最高版本。

• 32位隨機數：服務端生成的32位隨機數，生成方式和客戶端一樣。服務端生成隨機數的可以有效的防範中間人攻擊，主要是通過防止重新握手后的重放攻擊。

• 會話ID：用於表示客戶端和服務端之間的會話。若客戶端提供了會話ID，則可以校驗是否與歷史會話匹配。

  • 若不匹配，則服務端可以選擇直接使用客戶端的會話ID或根據自定義規則生成一個新的會話ID，客戶端需要保存服務端返回的會話ID當作本次會話的ID。

  • 若匹配，則可以直接執行1-RTT握手流程，返回ServerHello后直接返回ChangeCipherSpec和Finished消息。

        Client                                                Server
    
        ClientHello                   -------->
                                                        ServerHello
                                                    [ChangeCipherSpec]
                                        <--------             Finished
        [ChangeCipherSpec]
        Finished                      -------->
        Application Data              <------->     Application Data
    

    在Finished消息中和完整握手一樣都需要校驗VerifyData。

• 算法套件：服務端根據客戶端提供的算法套件列表和自己當前支持算法進行匹配，選擇一個最合適的算法組合，若沒有匹配項，則使用默認的TLS_RSA_WITH_AES_128_CBC_SHA。

  TLS1.2協議要求客戶端和服務端都必須實現密碼套件TLS_RSA_WITH_AES_128_CBC_SHA

• 壓縮方式：用於和服務端協商數據傳輸的壓縮方式。由於TLS壓縮存在安全漏洞，因此在TLS1.3中已經將TLS壓縮功能去除，TLS1.2算法也建議不啟用壓縮功能。

• 擴展字段：服務端需要支持接收具有擴展和沒有擴展的ClientHello。服務端響應的擴展類型必須是ClientHello出現過才行，否則客戶端必須響應unsupported_extension嚴重警告並中斷握手。

RFC 7568要求客戶端和服務端握手時不能發送{3,0}版本，任何收到帶有協議Hello消息的一方版本設置為{3,0}必須響應protocol_version警報消息並關閉連接。

通過ClientHello和ServerHello，客戶端和服務端就協商好算法套件和用於生成密鑰的隨機數。

Certificate

假設客戶端和服務端使用默認的TLS_RSA_WITH_AES_128_CBC_SHA算法，在ServerHello完成后，服務端必須將本地的RSA證書傳給客戶端，以便客戶端和服務端之間可以進行非對稱加密保證對稱加密密鑰的安全性。
RSA的證書有2個作用：

• 客戶端可以對服務端的證書進行合法性進行校驗。
• 對Client Key Exchange生成的pre-master key進行公鑰加密，保證只有服務端可以解密，確保對稱加密密鑰的安全性。

發送給客戶端的是一系列證書，服務端的證書必須排列在第一位，排在後面的證書可以認證前面的證書。
當客戶端收到了服務端的ServerHello時，若客戶端也有證書需要服務端驗證，則通過該握手請求將客戶端的證書發送給服務端，若客戶端沒有證書，則無需發送證書請求到服務端。

證書必須為X.509v3格式。

Server Key Exchange

使用RSA公鑰加密，必須要保證服務端私鑰的安全。若私鑰泄漏，則使用公鑰加密的對稱密鑰就不再安全。同時RSA是基於大數因式分解。密鑰位數必須足夠大才能避免密鑰被暴力破解。

1999年，RSA-155 (512 bits) 被成功分解。
2009年12月12日，RSA-768 (768 bits)也被成功分解。
在2013年的稜鏡門事件中，某個CA機構迫於美國政府壓力向其提交了CA的私鑰，這就是十分危險的。

相比之下，使用DH算法通過雙方在不共享密鑰的情況下雙方就可以協商出共享密鑰，避免了密鑰的直接傳輸。DH算法是基於離散對數，計算相對較慢。而基於橢圓曲線密碼（ECC）的DH算法計算速度更快，而且用更小的Key就能達到RSA加密的安全級別。ECC密鑰長度為224~225位幾乎和RSA2048位具有相同的強度。

ECDH:基於ECC的DH算法。

另外在DH算法下引入動態隨機數，可以避免密鑰直接傳輸。同時即使密鑰泄漏，也無法解密其他消息，因為雙方生成的動態隨機數無法得知。

在密碼學中該特性被稱為前向保密

DHE: 通過引入動態隨機數，具有前向保密的DH算法。
ECDHE：通過引入動態隨機數，具有前保密的ECDH算法。

Certificate Request

當需要TLS雙向認證的時候，若服務端需要驗證客戶端的證書，則向客戶端發送Certificate Request請求獲取客戶端指定類型的證書。

• 服務端會指定客戶端的證書類型。
• 客戶端會確定是否有合適的證書。

Server Hello Done

當服務端處理Hello請求結束時，發送Server Hello Done消息，然後等待接收客戶端握手消息。客戶端收到服務端該消息，有必要時需要對服務端的證書進行有效性校驗。

Client Certificate

當客戶端收到了服務端的CertificateRequest請求時，需要發送Client Certificate消息，若客戶端無法提供證書，則仍要發送此消息，消息內容可以不包含證書。

Client Key Exchange

客戶端接收到ServerHelloDone消息后，計算密鑰，通過發送Client Key Exchange消息給服務端。客戶端和服務端通過Key Exchange消息交換密鑰，使得雙方的主密鑰協商達成一致。

以RSA的密鑰協商為例。在ClientHello和ServerHello分別在客戶端和服務端創建了一個32位的隨機數。客戶端接收到Server Hello Done消息時，生成最後一個48位的預主密鑰。通過服務端提供的證書進行公鑰加密，以保證只有服務端的私鑰才能解密。

其中預主密鑰的前2位要求使用Client Hello傳輸的TLS版本號（存在一些TLS客戶端傳遞的時協商后的TLS版本號，對該版本號檢查時可能會造成握手失敗）。

需要注意的是，若RSA證書的填空格式不正確，則可能會存在一個漏洞導致客戶端發送的PreMasterSecret被中間人解密造成數據加密的對賬密鑰泄漏。可以看下Attacking RSA-based Sessions in SSL/TLS

Certificate Verify

若服務端要求客戶端發送證書，且客戶端發送了非0長度的證書，此時客戶端想要證明自己擁有該證書，則需要使用客戶端私鑰簽名一段數據發送給服務端繼續驗證。該數據為客戶端收發的所有握手數據的hash值（不包括本次消息）。

Finished

當發送完Change Cipher Spec消息后必須立即發送該消息。當該消息用於驗證密鑰交換和身份驗證過程是否成功。

Finished消息是第一個使用協商的算法簇進行加密和防篡改保護的消息。一旦雙方都通過了該消息驗證，就完成了TLS握手。
VerifyData為客戶端收發的所有握手數據的hash值（不包括本次消息）。與Certificate Verify的hash值可能會不一樣。如果發送過Certificate Verify消息，服務端的握手消息會包含Certificate Verify握手的數據。

需要注意的是，握手數據不包括協議頭的握手協議明文數據（服務端返回Finished的驗證握手數據是包含接收到客戶端的Finished的明文hash值）。

Finished消息數據加密和Appilication Data一致，具體數據加密在Application Data段進行說明。

改變密碼標準協議

改變密碼標準協議是為了在密碼策略中發出信號轉換信號。 該協議由一條消息組成，該消息在當前（不是掛起的）連接狀態下進行加密和壓縮。 消息由值 1 的單個字節組成。

在接收到該協議后，所有接收到的數據都需要解密。

警報協議

警報消息傳達消息的嚴重性（警告或致命）和警報的說明。具有致命級別的警報消息會導致立即終止連接。
若在改變密碼標準協議前接收到警報消息，是明文傳輸的，無需解密。

與其他消息一樣，警報消息按當前連接狀態指定進行加密和壓縮。在接收到改變密碼標準協議後接收到警報協議，則需要進行解密。解密后即為警報協議明文格式。

加密的Alert消息和加密數據一樣，都需要遞增加密序號，在數據解密時，遞增解密序號。

應用程序數據協議

當客戶端和服務端Finished發送完畢並驗證通過後，握手就結束了。後續所有數據都會使用握手協商的對稱密鑰進行數據加密。

TLS協議實現了數據加密和MAC計算。一般來說有3種加密模式，分別為：

1. Mac-then-Encrypt：在明文上計算MAC，將其附加到數據，然後加密明和+MAC的完整數據。
2. 加密和MAC：在明文上計算MAC，加密明文，然後將MAC附加到密文的末尾
3. Encrypt-then-Mac：加密明文，然後在密文上計算MAC，並將其附加到密文。

TLS協議使用的是Mac-then-Encrypt。首先將加密的序號、ContentType、數據長度、數據進計算HMAC-SHA256摘要。然後將摘要拼接到數據后，通過PKCS7格式對摘要+MAC數據進行填充對其和加密塊大小一致。最後摘要+MAC+對其填充塊進行加密。

需要注意的是應用程序數據消息有最大長度限制2^14 + 2048，當超過長度后，數據需要分段傳輸。每一段都當作單獨的數據段進行單獨MAC地址並加密。

結語

TLS1.2版本是目前最常用的TLS協議，TLS1.3版本於2018年發表，目前並沒有廣泛使用。
使用TLS1.2需要注意以下幾點:

1. 若使用RSA非對稱加密，則需要盡可能使用2048位長度的密鑰。
2. 盡可能可以使用具有前向安全性的加密算法，如ECDHE算法進行非對稱加密。
3. 使用AEAD認證加密(GCM)代替CBC塊加密。

參考文獻

1. The Transport Layer Security (TLS) Protocol Version 1.2
2. TLS發展歷史
3. 前向安全性
4. TLS/SSL 協議詳解 (30) SSL中的RSA、DHE、ECDHE、ECDH流程與區別
5. TLS Extensions
6. Session會話恢復：兩種簡短的握手總結SessionID&SessionTicket
7. Why using the premaster secret directly would be vulnerable to replay attack?
8. Why does the SSL/TLS handshake have a client and server random?
9. Transport Layer Security (TLS) Extensions
10. 什麼是AEAD加密
11. Padding Oracle Attacks
12. Lucky13攻擊
13. Padding Oracle Attack
14. ssl perfect forward secrecy
15. Transport Layer Security (TLS) Session Resumption without Server-Side State
16. Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
17. DTLS協議中client/server的認證過程和密鑰協商過程

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計最專業,超強功能平台可客製化

電動車與能源儲存設備製造商特斯拉 (Tesla) 要招募 1,656 人，一下子釋出這麼多職缺，讓人好奇這家執行長光環大過一切的公司，到底再找甚麼樣的能人，順便一窺特斯拉的營運布局。 彭博報導，特斯拉在找的人包括一到三年經驗的汽車雷達系統工程師，墨西哥市的客服經理，阿姆斯特丹、米蘭、上海、成都等大城市的產品專員。

自從 2007 年虧損 18.8 億美元後，特斯拉推出更多車款，打造世界最大的電池工廠，在全球擴張版圖，包括在墨西哥市與愛丁堡開店，所以他們一直在找人，即便投資巨大，但 Elon Musk 仍然誓言明年第一季就要創造正的現金流。   分析師認為，特斯拉在一連串投資之後，2016 年必須對市場展現他們有獲利能力，擺在眼前的就是汽車製造與電池事業兩大任務，他們必須擴大每個部門的人力。   報導指出，自 2010 年底特斯拉上市之後，至今員工人數已經成長十五倍，超過 14,000 人，可媲美市值的增長幅度。五年前，這家公司只賣一款汽車 Roadster，且市場只在美國，現在在世界三大洲賣兩款電動車，以及提供家用、商用、公用固定式電池系統特斯拉能源  (Tesla Energy)。   大量招募是快速成長的公司典型的作風，特斯拉九月發表第一款 Model X SUV 系列車款時表示，第四季預計可賣出 1.7 萬到 1.9 萬台，今年至少可賣出五萬台。   特斯拉於十月發表自動駕駛功能 Autopilot，Musk 當時表示自動化與電子化是兩項最前瞻的創新，去年第四季後出貨的汽車都配有結合照相機、雷達、超聲波傳感器的設備，功能像是巡航控制或自動車道變換。Musk 曾說 Autopilot 軟體團隊有 50 人，硬體方面約 100 人。   上月 Musk 表示他打造了一個專門的團隊來做全自動汽車，同時表示他們在找硬核軟體工程師，不需要有汽車相關經驗，強調 Autopilot 團隊直接向他報告，所以他會親自面試。   報導指出，蘋果開發自動車，Google 在做無駕駛汽車，還有新創公司 Cruise Automation 等等，現在不管何種汽車工程師在矽谷都相當搶手，但特斯拉說他們接到的履歷仍然非常多，有 150 萬份來自世界各地的履歷，其 HR 對媒體表示，「大家都很想來特斯拉工作。」

（首圖來源： CC By 2.0）

（本文授權轉載自《》─〈〉）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※想知道最厲害的網頁設計公司"嚨底家"!

※幫你省時又省力,新北清潔一流服務好口碑

※別再煩惱如何寫文案,掌握八大原則!

※產品缺大量曝光嗎?你需要的是一流包裝設計!