Tubo Man

Tubo Man

1550715100

Where does Hyperledger Sawtooth store its ledger?

Where does Hyperledger Sawtooth store its ledger entries within the validator? Is it in a readable format?

What kind of a database does it maintain?

Can the transactions performed on the network be seen?

#hyperledger #blockchain

What is GEEK

Buddha Community

By default, the blockchain is stored under /var/lib/sawtooth/ unless you have $SAWTOOTH_HOME set, then it uses that directory.

The blockchain (transactions) is stored as a sparse file in a LMDB database in file block-00.lmdb . The global state (variables) is stored in file merkle-00.lmdb as a Merkle Trie.

More details in the FAQ at https://sawtooth.hyperledger.org/faq/validator/#what-files-does-sawtooth-use

Trung  Nguyen

Trung Nguyen

1646796184

Vượt Qua Kỳ Thi Chuyên Gia Bảo Mật Kubernetes Được Chứng Nhận

Bài viết này dựa trên kinh nghiệm của tôi khi học và vượt qua kỳ thi Chuyên gia bảo mật Kubernetes được chứng nhận. Tôi đã vượt qua kỳ thi trong lần thử đầu tiên vào tháng 9 năm 2021.

Tôi đã vượt qua kỳ thi Nhà phát triển ứng dụng Kubernetes được chứng nhận vào tháng 2 năm 2020, tiếp theo là Quản trị viên Kubernetes được chứng nhận vào tháng 3 năm 2020.

Kỳ thi CKS hoặc Chuyên gia bảo mật Kubernetes được chứng nhận đã được phát hành vào khoảng tháng 11 năm 2020, nhưng tôi không có cơ hội tham gia kỳ thi đó trước tháng 9 năm 2021.

Như một chút thông tin cơ bản, tôi đã làm việc với Kubernetes trong 3 năm qua gần như hàng ngày và kinh nghiệm đó là một lợi thế bổ sung giúp tôi vượt qua CKS.

Trong bài viết này, tôi sẽ chia sẻ một số tài nguyên sẽ giúp bạn học tập và vượt qua kỳ thi, cùng với một bảng đánh giá hữu ích mà bạn có thể sử dụng khi chuẩn bị. Tôi cũng sẽ chia sẻ một số lời khuyên sẽ giúp ích cho bạn trong suốt quá trình.

Kubernetes là gì?

Kubernetes là hệ thống Điều phối vùng chứa phong phú và phát triển nhất hiện có và nó tiếp tục trở nên tốt hơn.

Nó có một cộng đồng khổng lồ để hỗ trợ và nó luôn xây dựng các tính năng mới và giải quyết các vấn đề. Kubernetes chắc chắn đang phát triển với tốc độ chóng mặt, và nó trở thành một thách thức để theo kịp tốc độ phát triển của nó. Điều này làm cho nó trở thành lựa chọn tốt nhất cho giải pháp điều phối vùng chứa.


Tài nguyên cho kỳ thi

Sau đây là một số tài nguyên tuyệt vời có sẵn để vượt qua kỳ thi CKS:

  1. Chuyên gia bảo mật Kubernetes được chứng nhận bởi Killer.sh
  2. Chuyên gia bảo mật Kubernetes được chứng nhận (CKS) bởi KodeKloud
  3. Walid Shaari đã tập hợp một số tài liệu không thể thiếu cho kỳ thi CKS
  4. Tài liệu tham khảo của Abdennour cho các mục tiêu kỳ thi CKS
  5. Bộ sưu tập tài nguyên của Ibrahim Jelliti để chuẩn bị cho kỳ thi Chuyên gia bảo mật Kubernetes được chứng nhận (CKSS)

Các khóa học cho KodeKloud và Killer.sh cung cấp các trình mô phỏng kỳ thi thử rất hữu ích trong việc chuẩn bị cho kỳ thi và cung cấp một ý tưởng khá tốt về kỳ thi trông như thế nào. Tôi thực sự khuyên bạn nên đăng ký vào một hoặc cả hai khóa học.

Mua bài kiểm tra từ Linux Foundation mang đến cho bạn 2 lần thử miễn phí trong trình mô phỏng kỳ thi từ killer.sh. Bằng cách đó, nếu bạn đã thành thạo với nội dung của chương trình học, bạn có thể bỏ qua các khóa học và trực tiếp đến với trình mô phỏng kỳ thi được cung cấp kèm theo kỳ thi.

Kỳ thi có giá $ 375 nhưng có các ưu đãi và giao dịch có sẵn, và nếu bạn tìm kiếm chúng, bạn có thể có được mức giá tốt hơn. Thời gian của kỳ thi là 2 giờ và có giá trị trong 2 năm, không giống như CKA và CKAD có giá trị trong 3 năm.

Bí danh

CKS là một kỳ thi dựa trên thành tích, nơi bạn được cung cấp một trình mô phỏng kỳ thi mà bạn phải tìm ra các vấn đề. Bạn chỉ được phép mở một tab ngoài tab kỳ thi.

Vì kỳ thi này yêu cầu bạn viết rất nhiều lệnh, tôi đã sớm nhận ra rằng tôi sẽ phải dựa vào bí danh để giảm số lần nhấn phím nhằm tiết kiệm thời gian.

Tôi đã sử dụng trình soạn thảo vi trong suốt kỳ thi, vì vậy ở đây tôi sẽ chia sẻ một số mẹo hữu ích cho trình soạn thảo này.

vi mặc định cho ~ / .vimrc:

vi ~/.vimrc
---
:set number
:set et
:set sw=2 ts=2 sts=2
---
^: Start of word in line
0: Start of line
$: End of line
w: End of word
GG: End of file

kubectl mặc định cho ~ / .bashrc:

vi ~/.bashrc
---
alias k='kubectl'
alias kg='k get'
alias kd='k describe'
alias kl='k logs'
alias ke='k explain'
alias kr='k replace'
alias kc='k create'
alias kgp='k get po'
alias kgn='k get no'
alias kge='k get ev'
alias kex='k exec -it'
alias kgc='k config get-contexts'
alias ksn='k config set-context --current --namespace'
alias kuc='k config use-context'
alias krun='k run'
export do='--dry-run=client -oyaml'
export force='--grace-period=0 --force'

source <(kubectl completion bash)
source <(kubectl completion bash | sed 's/kubectl/k/g' )
complete -F __start_kubectl k


alias krp='k run test --image=busybox --restart=Never'
alias kuc='k config use-context'
---

Các phím tắt

Lệnh kubectl get này cung cấp các tên ngắn gọn hấp dẫn để truy cập tài nguyên và tương tự như pvc đối với persistentstorageclaim. Những điều này có thể giúp tiết kiệm rất nhiều thao tác gõ phím và thời gian quý báu trong kỳ thi.

  • po cho pods
  • rs cho replicasets
  • triển khai cho deployments
  • svc cho services
  • ns cho namespace
  • netpol cho networkpolicy
  • pv cho persistentstorage
  • pvc cho persistentstorageclaim
  • sa cho serviceaccounts

Kubernetes Cheat Sheet

lệnh chạy kubectl

Lệnh kubectl run cung cấp một cờ --restart cho phép bạn tạo các loại đối tượng Kubernetes khác nhau từ Triển khai đến CronJob.

Đoạn mã dưới đây cho thấy các tùy chọn khác nhau có sẵn cho --restart cờ.

k run:
--restart=Always                             #Creates a deployment
--restart=Never                              #Creates a Pod
--restart=OnFailure                          #Creates a Job
--restart=OnFailure --schedule="*/1 * * * *" #Creates a CronJob

Cách tạo thông số yaml từ một nhóm hiện có

Đôi khi, việc tạo một thông số kỹ thuật từ một nhóm hiện có và thực hiện các thay đổi đối với nó dễ dàng hơn là tạo một nhóm mới từ đầu. Lệnh kubectl get pod cung cấp cho chúng ta các cờ cần thiết để xuất ra thông số nhóm ở định dạng chúng ta muốn.

kgp <pod-name> -o wide

# Generating YAML Pod spec
kgp <pod-name> -o yaml
kgp <pod-name> -o yaml > <pod-name>.yaml

# Get a pod's YAML spec without cluster specific information
kgp my-pod -o yaml --export > <pod-name>.yaml

lệnh pod kubectl

Lệnh kubectl run cung cấp rất nhiều tùy chọn, chẳng hạn như chỉ định các yêu cầu và giới hạn mà một nhóm phải sử dụng hoặc các lệnh mà một vùng chứa sẽ chạy sau khi được tạo.

# Output YAML for a nginx pod running an echo command
krun nginx --image=nginx --restart=Never --dry-run -o yaml -- /bin/sh -c 'echo Hello World!'
# Output YAML for a busybox pod running a sleep command
krun busybox --image=busybox:1.28 --restart=Never --dry-run -o yaml -- /bin/sh -c 'while true; do echo sleep; sleep 10; done'
# Run a pod with set requests and limits
krun nginx --image=nginx --restart=Never --requests='cpu=100m,memory=512Mi' --limits='cpu=300m,memory=1Gi'
# Delete pod without delay
k delete po busybox --grace-period=0 --force

Cách in nhật ký và xuất chúng

Nhật ký là nguồn thông tin cơ bản khi nói đến gỡ lỗi một ứng dụng. Lệnh kubectl logs cung cấp chức năng kiểm tra nhật ký của một nhóm nhất định. Bạn có thể sử dụng các lệnh dưới đây để kiểm tra nhật ký của một nhóm nhất định.

kubectl logs deploy/<podname>
kubectl logs deployment/<podname>
#Follow logs
kubectl logs deploy/<podname> --tail 1 --follow

Ngoài việc chỉ xem nhật ký, chúng tôi cũng có thể xuất nhật ký thành tệp để gỡ lỗi thêm khi chia sẻ cùng một tệp với bất kỳ ai.

kubectl logs <podname> --namespace <ns> > /path/to/file.format

Cách tạo bản đồ cấu hình và bí mật

Lệnh kubectl create cho phép chúng tôi tạo Bản đồ cấu hình và Bí mật từ dòng lệnh. Chúng tôi cũng có thể sử dụng tệp YAML để tạo cùng một tài nguyên và bằng cách sử dụng kubectl apply -f <filename>, chúng tôi có thể áp dụng các lệnh.

kc cm my-cm --from-literal=APP_ENV=dev
kc cm my-cm --from-file=test.txt
kc cm my-cm --from-env-file=config.env

kc secret generic my-secret --from-literal=APP_SECRET=sdcdcsdcsdcsdc
kc secret generic my-secret --from-file=secret.txt
kc secret generic my-secret --from-env-file=secret.env

Các lệnh hữu ích để gỡ lỗi

Gỡ lỗi là một kỹ năng rất quan trọng khi bạn đang đối mặt với các vấn đề và lỗi trong công việc hàng ngày của chúng tôi và khi giải quyết các vấn đề trong kỳ thi CKS.

Ngoài khả năng xuất nhật ký từ vùng chứa, các kubectl exec lệnh cho phép bạn đăng nhập vào vùng chứa đang chạy và gỡ lỗi các vấn đề. Khi ở bên trong vùng chứa, bạn cũng có thể sử dụng các tiện ích như ncnslookup để chẩn đoán các sự cố liên quan đến mạng.

# Run busybox container
k run busybox --image=busybox:1.28 --rm --restart=Never -it sh
# Connect to a specific container in a Pod
k exec -it busybox -c busybox2 -- /bin/sh
# adding limits and requests in command
kubectl run nginx --image=nginx --restart=Never --requests='cpu=100m,memory=256Mi' --limits='cpu=200m,memory=512Mi'
# Create a Pod with a service
kubectl run nginx --image=nginx --restart=Never --port=80 --expose
# Check port
nc -z -v -w 2 <service-name> <port-name>
# NSLookup
nslookup <service-name>
nslookup 10-32-0-10.default.pod

Cập nhật lần lượt và triển khai

Lệnh kubectl rollout cung cấp khả năng kiểm tra trạng thái của các bản cập nhật và nếu được yêu cầu, quay trở lại phiên bản trước đó.

k set image deploy/nginx nginx=nginx:1.17.0 --record
k rollout status deploy/nginx
k rollout history deploy/nginx
# Rollback to previous version
k rollout undo deploy/nginx
# Rollback to revision number
k rollout undo deploy/nginx --to-revision=2
k rollout pause deploy/nginx
k rollout resume deploy/nginx
k rollout restart deploy/nginx
kubectl run nginx-deploy --image=nginx:1.16 --replias=1 --record

Lệnh scale và autoscale

Lệnh kubectl scale cung cấp chức năng mở rộng hoặc thu nhỏ các nhóm trong một triển khai nhất định.

Sử dụng kubectl autoscale lệnh, chúng tôi có thể xác định số lượng nhóm tối thiểu sẽ chạy cho một triển khai nhất định và số lượng nhóm tối đa mà việc triển khai có thể mở rộng cùng với các tiêu chí mở rộng như tỷ lệ phần trăm CPU.

k scale deploy/nginx --replicas=6
k autoscale deploy/nginx --min=3 --max=9 --cpu-percent=80

Chính sách mạng

Trong một cụm Kubernetes, tất cả các nhóm có thể giao tiếp với tất cả các nhóm theo mặc định, đây có thể là một vấn đề bảo mật trong một số triển khai.

Để giải quyết vấn đề này, Kubernetes đã giới thiệu Chính sách mạng để cho phép hoặc từ chối lưu lượng truy cập đến và đi từ các nhóm dựa trên các nhãn nhóm là một phần của thông số nhóm.

Ví dụ dưới đây từ chối cả lưu lượng vào và ra cho các nhóm đang chạy trong tất cả các không gian tên.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: example
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  - Ingress

Ví dụ dưới đây từ chối cả lưu lượng vào và ra cho các nhóm đang chạy trong tất cả các không gian tên. Nhưng nó cho phép truy cập vào các dịch vụ phân giải DNS chạy trên cổng 53.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  - Ingress
  egress:
  - to:
    ports:
      - port: 53
        protocol: TCP
      - port: 53
        protocol: UDP

Ví dụ dưới đây từ chối quyền truy cập vào Máy chủ siêu dữ liệu đang chạy trên địa chỉ IP 169.256.169.256trong Phiên bản AWS EC2.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name:cloud-metadata-deny
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
      - ipBlock: 
          cidr: 0.0.0.0/0
          except:
          - 169.256.169.256/32

Ví dụ dưới đây cho phép Truy cập vào máy chủ siêu dữ liệu đang chạy trên địa chỉ IP 169.256.169.256trong Phiên bản AWS EC2.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cloud-metadata-accessor
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: metadata-accessor
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 169.256.169.256/32

Phân tích tĩnh bằng Kubesec

Kubesec là một công cụ Phân tích tĩnh để phân tích các tệp YAML để tìm ra các vấn đề với tệp.

kubesec scan pod.yaml

# Using online kubesec API
curl -sSX POST --data-binary @pod.yaml https://v2.kubesec.io/scan

# Running the API locally
kubesec http 8080 &

kubesec scan pod.yaml -o pod_report.json -o json

Quét lỗ hổng bảo mật bằng Trivvy

Trivvy là một công cụ Quét lỗ hổng bảo mật để quét các hình ảnh vùng chứa để tìm các vấn đề bảo mật.

trivy image nginx:1.18.0
trivy image --severity CRITICAL nginx:1.18.0
trivy image --severity CRITICAL, HIGH nginx:1.18.0
trivy image --ignore-unfixed nginx:1.18.0

# Scanning image tarball
docker save nginx:1.18.0 > nginx.tar
trivy image --input archive.tar

# Scan and output results to file
trivy image --output python_alpine.txt python:3.10.0a4-alpine
trivy image --severity HIGH --output /root/python.txt python:3.10.0a4-alpine

# Scan image tarball
trivy image --input alpine.tar --format json --output /root/alpine.json

Cách xóa các dịch vụ không mong muốn

Tính năng này systemctl cho thấy các khả năng khởi động, dừng, bật, tắt và liệt kê các dịch vụ đang chạy trên Máy ảo Linux.

Liệt kê các dịch vụ:

systemctl list-units --type service

Dừng phục vụ:

systemctl stop apache2

Tắt dịch vụ:

systemctl disable apache2

Xóa dịch vụ:

apt remove apache2

Các lớp thời gian chạy

Kubernetes đã giới thiệu tính năng RuntimeClass trong phiên bản v1.12để chọn cấu hình thời gian chạy vùng chứa. Cấu hình thời gian chạy của vùng chứa được sử dụng để chạy các vùng chứa bên dưới của một nhóm.

Hầu hết các cụm Kubernetes sử dụng dockershim làm lớp Thời gian chạy cho các vùng chứa đang chạy, nhưng bạn có thể sử dụng Thời gian chạy vùng chứa khác nhau.

Phiên dockershim bản Kubernetes đã không còn được dùng nữa v1.20và sẽ bị xóa trong v1.24.

Cách tạo một Lớp thời gian chạy:

apiversion: node.k8s.io/v1beta1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc

Cách sử dụng một lớp thời gian chạy cho bất kỳ nhóm nào đã cho:

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: nginx
  name: nginx
spec:
  runtimeClassName: gvisor
  containers:
  - name: nginx
    image: nginx 

Lệnh RBAC

Trong các chính phủ,

Các lệnh kiểm soát truy cập dựa trên vai trò (RBAC) cung cấp một phương pháp điều chỉnh quyền truy cập vào tài nguyên Kubernetes dựa trên vai trò của từng người dùng hoặc tài khoản dịch vụ. ( Nguồn )

Đây là cách tạo một vai trò:

kubectl create role developer --resource=pods --verb=create,list,get,update,delete --namespace=development

Cách tạo ràng buộc vai trò:

kubectl create rolebinding developer-role-binding --role=developer --user=faizan --namespace=development

Cách xác thực:

kubectl auth can-i update pods --namespace=development --as=faizan

Cách tạo vai trò cụm:

kubectl create clusterrole pvviewer-role --resource=persistentvolumes --verb=list

Và cách tạo liên kết Clusterrole Binding với tài khoản dịch vụ:

kubectl create clusterrolebinding pvviewer-role-binding --clusterrole=pvviewer-role --serviceaccount=default:pvviewer

Bảo trì cụm

Bạn sử dụng kubectl drain lệnh để xóa tất cả khối lượng công việc đang chạy (nhóm) khỏi một Node nhất định.

Bạn sử dụng kubectl cordon lệnh để buộc một nút để đánh dấu nó là có thể lập lịch.

Bạn sử dụng kubectl uncordon lệnh để đặt nút là có thể lập lịch, nghĩa là Trình quản lý bộ điều khiển có thể lập lịch các nhóm mới cho nút đã cho.

Cách thoát một nút của tất cả các nhóm:

kubectl drain node-1

Làm thế nào để rút một nút và bỏ qua daemonsets:

kubectl drain node01 --ignore-daemonsets

Làm thế nào để buộc thoát nước:

kubectl drain node02 --ignore-daemonsets --force

Cách đánh dấu một nút là không thể lập lịch để không có nhóm mới nào có thể được lập lịch trên nút này:

kubectl cordon node-1

Đánh dấu một nút có thể lập lịch

kubectl uncordon node-1

Mẹo thi CKS

Lệnh Kubernetes kubectl get cung cấp cho người dùng cờ đầu ra -o hoặc --output giúp chúng tôi định dạng đầu ra ở dạng JSON, yaml, wide hoặc tùy chỉnh-cột.

JSON và JSONPath

Cách xuất nội dung của tất cả các nhóm ở dạng Đối tượng JSON:

kubectl get pods -o json

JSONPath xuất ra một khóa cụ thể từ Đối tượng JSON:

kubectl get pods -o=jsonpath='{@}'
kubectl get pods -o=jsonpath='{.items[0]}'

Được sử dụng khi chúng ta có nhiều đối tượng , .items[*]ví dụ như nhiều vùng chứa với cấu hình nhóm:

# For list of items use .items[*]
k get pods -o 'jsonpath={.items[*].metadata.labels.version}'
# For single item
k get po busybox -o jsonpath='{.metadata}'
k get po busybox -o jsonpath="{['.metadata.name', '.metadata.namespace']}{'\n'}"

Lệnh trả về IP nội bộ của một Node sử dụng JSONPath:

kubectl get nodes -o=jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}'

Lệnh kiểm tra sự bình đẳng trên một khóa cụ thể:

kubectl get pod api-stag-765797cf-lrd8q -o=jsonpath='{.spec.volumes[?(@.name=="api-data")].persistentVolumeClaim.claimName}'
kubectl get pod -o=jsonpath='{.items[*].spec.tolerations[?(@.effect=="NoSchedule")].key}'

Các Cột Tùy chỉnh rất hữu ích để xuất ra các trường cụ thể:

kubectl get pods -o='custom-columns=PODS:.metadata.name,Images:.spec.containers[*].image'

Chủ đề kỳ thi CKS

Kỳ thi CKS bao gồm các chủ đề liên quan đến bảo mật trong hệ sinh thái Kubernetes. Bảo mật Kubernetes là một chủ đề rộng lớn cần đề cập trong một bài báo, vì vậy bài viết này bao gồm một số chủ đề được đề cập trong kỳ thi.

Cách bảo mật và làm cứng hình ảnh vùng chứa

Trong khi thiết kế hình ảnh vùng chứa để chạy mã của bạn, hãy đặc biệt chú ý đến các biện pháp bảo mật và tăng cường để ngăn chặn các vụ hack và tấn công leo thang đặc quyền. Hãy ghi nhớ những điểm dưới đây khi xây dựng hình ảnh vùng chứa:

  1. Sử dụng các phiên bản gói cụ thể như alpine:3.13.
  2. Không chạy dưới quyền root - sử dụng USER <username>để chặn quyền truy cập root.
  3. Đặt hệ thống tệp ở chế độ chỉ đọc khi securityContext sử dụng readOnlyRootFilesystem: true
  4. Xóa quyền truy cập shell bằng cách sử dụng RUN rm -rf /bin/*

Cách giảm thiểu dấu chân của hệ điều hành

Các lớp chứa

Hướng dẫn RUNCOPY tạo ADD các lớp vùng chứa. Các hướng dẫn khác tạo hình ảnh trung gian tạm thời và không làm tăng kích thước của bản dựng. Các hướng dẫn tạo lớp sẽ bổ sung vào kích thước của hình ảnh kết quả.

Một Dockerfile điển hình trông giống như một tệp được đưa ra bên dưới. Nó thêm một lớp duy nhất bằng cách sử dụng RUN hướng dẫn.

FROM ubuntu

RUN apt-get update && apt-get install -y golang-go

CMD ["sh"]

Bản dựng nhiều giai đoạn

Multi-Stage xây dựng đòn bẩy nhiều FROM câu lệnh trong Dockerfile. Hướng FROM dẫn đánh dấu một giai đoạn mới trong quá trình xây dựng. Nó kết hợp nhiều FROM câu lệnh cho phép tận dụng từ bản dựng trước để sao chép có chọn lọc các tệp nhị phân sang giai đoạn xây dựng mới loại bỏ các mã nhị phân không cần thiết. Hình ảnh Docker kết quả có kích thước nhỏ hơn đáng kể với bề mặt tấn công giảm đáng kể.

FROM ubuntu:20.04 AS build
ARG DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y golang-go
COPY app.go .
RUN CGO_ENABLED=0 go build app.go

FROM alpine:3.13
RUN chmod a-w /etc
RUN addgroup -S appgroup && adduser -S appuser -G appgroup -h /home/appuser
RUN rm -rf /bin/*
COPY --from=build /app /home/appuser/
USER appuser
CMD ["/home/appuser/app"]

Cách giới hạn quyền truy cập vào nút

Các tệp Kiểm soát Truy cập chứa thông tin nhạy cảm về người dùng / nhóm trong Hệ điều hành Linux.

#Stores information about the UID/GID, user shell, and home directory for a user
/etc/passwd
#Stores the user password in a hashed format
/etc/shadow
#Stores information about the group a user belongs
/etc/group
#Stored information about the Sudoers present in the system
/etc/sudoers

Vô hiệu hóa tài khoản người dùng giúp đảm bảo quyền truy cập vào Node bằng cách tắt đăng nhập vào một tài khoản người dùng nhất định.

usermod -s /bin/nologin <username>

Việc vô hiệu hóa root tài khoản người dùng có ý nghĩa đặc biệt, vì tài khoản gốc có tất cả các khả năng.

usermod -s /bin/nologin root

Đây là cách thêm người dùng với thư mục chính và trình bao:

adduser --home /opt/faizanbashir --shell /bin/bash --uid 2328 --ingroup admin faizanbashir
useradd -d /opt/faizanbashir -s /bin/bash -G admin -u 2328 faizanbashir

Cách xóa tài khoản người dùng:

userdel <username>

Cách xóa một nhóm:

groupdel <groupname>

Cách thêm người dùng vào nhóm:

adduser <username> <groupname>

Cách xóa người dùng khỏi nhóm:

#deluser faizanbashir admin
deluser <username> <groupname>

Cách đặt mật khẩu cho người dùng:

passwd <username>

Cách nâng cao người dùng lên thành sudoer:

vim /etc/sudoers
>>>
faizanbashir ALL=(ALL:ALL) ALL

Cách bật sudo không cần mật khẩu:

vim /etc/sudoers
>>>
faizanbashir ALL=(ALL) NOPASSWD:ALL

visudo
usermod -aG sudo faizanbashir
usermod faizanbashir -G admin

Làm cứng SSH

Cách tắt SSH

Cấu hình được đưa ra trong /etc/ssh/sshd_config có thể được tận dụng để bảo mật quyền truy cập SSH vào các nút Linux. Đặt PermitRootLogin để no tắt đăng nhập gốc trên một nút.

Để thực thi việc sử dụng khóa để đăng nhập và vô hiệu hóa đăng nhập bằng mật khẩu vào các nút, bạn có thể đặt PasswordAuthentication thành no.

vim /etc/ssh/sshd_config
>>
PermitRootLogin no
PasswordAuthentication no
<<
# Restart SSHD Service
systemctl restart sshd

Cách đặt không có đăng nhập cho người dùng root:

usermod -s /bin/nologin root

SSH Sao chép khóa người dùng / SSH không mật khẩu:

ssh-copy-id -i ~/.ssh/id_rsa.pub faizanbashir@node01
ssh faizanbashir@node01

Cách xóa các gói và dịch vụ lỗi thời

Đây là cách bạn có thể liệt kê tất cả các dịch vụ đang chạy trên máy Ubuntu:

systemctl list-units --type service
systemctl list-units --type service --state running

Cách dừng, tắt và xóa một dịch vụ:

systemctl stop apache2
systemctl disable apache2
apt remove apache2

Cách hạn chế mô-đun hạt nhân

Trong Linux, mô-đun Kernel là những đoạn mã có thể được tải và dỡ xuống kernel theo yêu cầu. Chúng mở rộng chức năng của hạt nhân mà không cần khởi động lại hệ thống. Một mô-đun có thể được cấu hình dưới dạng tích hợp sẵn hoặc có thể tải được.

Cách liệt kê tất cả các Mô-đun nhân:

lsmod

Cách tải thủ công mô-đun vào Kernel:

modprobe pcspkr

Cách đưa vào danh sách đen một mô-đun: (Tham khảo: CIS Benchmarks -> 3.4 Giao thức mạng không phổ biến)

cat /etc/modprobe.d/blacklist.conf
>>>
blacklist sctp
blacklist dccp

# Shutdown for changes to take effect
shutdown -r now

# Verify
lsmod | grep dccp

Cách xác định và tắt các cổng đang mở

Cách kiểm tra các cổng đang mở:

netstat -an | grep -w LISTEN
netstat -natp | grep 9090

nc -zv <hostname|IP> 22
nc -zv <hostname|IP> 10-22

ufw deny 8080

Cách kiểm tra việc sử dụng cổng:

/etc/services | grep -w 53

Đây là tài liệu tham khảo cho danh sách các cổng đang mở .

Cách hạn chế quyền truy cập mạng

Cách xác định một dịch vụ đang chạy trên cổng:

systemctl status ssh
cat /etc/services | grep ssh
netstat -an | grep 22 | grep -w LISTEN

Tường lửa UFW

Tường lửa không phức tạp (UFW) là một công cụ để quản lý các quy tắc tường lửa trong Arch Linux, Debian hoặc Ubuntu. UFW cho phép bạn cho phép và chặn lưu lượng truy cập trên một cổng nhất định và từ một nguồn nhất định.

Đây là cách cài đặt Tường lửa UFW:

apt-get update
apt-get install ufw
systemctl enable ufw
systemctl start ufw
ufw status
ufw status numbered

Cách cho phép tất cả các kết nối đi và đến:

ufw default allow outgoing
ufw default allow incoming

Cách cho phép các quy tắc:

ufw allow 22
ufw allow 1000:2000/tcp
ufw allow from 172.16.238.5 to any port 22 proto tcp
ufw allow from 172.16.238.5 to any port 80 proto tcp
ufw allow from 172.16.100.0/28 to any port 80 proto tcp

Cách từ chối các quy tắc:

ufw deny 8080

Cách bật và kích hoạt Tường lửa:

ufw enable

Cách xóa các quy tắc:

ufw delete deny 8080
ufw delete <rule-line>

Cách đặt lại quy tắc:

ufw reset

Linux Syscalls

Linux Syscalls được sử dụng để thực hiện các yêu cầu từ không gian người dùng vào nhân Linux. Ví dụ: trong khi tạo tệp, không gian người dùng yêu cầu Nhân Linux tạo tệp.

Kernel Space có những thứ sau:

  • Mã hạt nhân
  • Phần mở rộng Kernel
  • Trình điều khiển thiết bị

Cách theo dõi Syscalls bằng Strace

Đây là cách bạn có thể theo dõi các cuộc gọi tổng hợp bằng cách sử dụng strace:

which strace
strace touch /tmp/error.log

Cách lấy PID của một dịch vụ:

pidof sshd
strace -p <pid>

Cách liệt kê tất cả các cuộc gọi tổng hợp được thực hiện trong một hoạt động:

strace -c touch /tmp/error.log

Cách hợp nhất các cuộc gọi hệ thống danh sách: (Đếm và tóm tắt)

strace -cw ls /

Cách theo dõi PID và hợp nhất:

strace -p 3502 -f -cw

AquaSec Tracee

AquaSec Tracee được tạo ra bởi Aqua Security, sử dụng eBPF để theo dõi các sự kiện trong vùng chứa. Tracee sử dụng eBPF (Bộ lọc gói Berkeley mở rộng) trong thời gian chạy trực tiếp trong không gian hạt nhân mà không can thiệp vào nguồn hạt nhân hoặc tải bất kỳ mô-đun hạt nhân nào.

  • Nhị phân được lưu trữ tại/tmp/tracee
  • Cần quyền truy cập vào phần sau, ở chế độ chỉ đọc nếu chạy bằng vùng chứa có --privileged khả năng:
    • /tmp/tracee-> Không gian làm việc mặc định
    • /lib/modules-> Tiêu đề hạt nhân
    • /usr/src-> Tiêu đề hạt nhân

Làm thế nào để Tracee thú vị trong vùng chứa Docker:

docker run --name tracee --rm --privileged --pid=host \
  -v /lib/modules/:/lib/modules/:ro -v /usr/src/:/usr/src/ro \
  -v /tmp/tracee:/tmp/tracee aquasec/tracee:0.4.0 --trace comm=ls

# List syscalls made by all the new process on the host
docker run --name tracee --rm --privileged --pid=host \
  -v /lib/modules/:/lib/modules/:ro -v /usr/src/:/usr/src/ro \
  -v /tmp/tracee:/tmp/tracee aquasec/tracee:0.4.0 --trace pid=new

# List syscalls made from any new container
docker run --name tracee --rm --privileged --pid=host \
  -v /lib/modules/:/lib/modules/:ro -v /usr/src/:/usr/src/ro \
  -v /tmp/tracee:/tmp/tracee aquasec/tracee:0.4.0 --trace container=new

Cách hạn chế Syscalls với Seccomp

SECCOMP - Chế độ Điện toán Bảo mật - là một tính năng cấp Kernel của Linux mà bạn có thể sử dụng cho các ứng dụng hộp cát để chỉ sử dụng các cuộc gọi hệ thống mà chúng cần.

Cách kiểm tra hỗ trợ cho seccomp:

grep -i seccomp /boot/config-$(uname -r)

Cách kiểm tra để thay đổi thời gian hệ thống:

docker run -it --rm docker/whalesay /bin/sh
# date -s '19 APR 2013 22:00:00'

ps -ef

Cách kiểm tra trạng thái seccomp cho bất kỳ PID nào:

grep -i seccomp /proc/1/status

Chế độ Seccomp:

  • Chế độ 0: Đã tắt
  • Chế độ 1: Nghiêm ngặt
  • Chế độ 2: Đã lọc

Cấu hình sau được sử dụng để đưa vào danh sách trắng các cuộc gọi tổng hợp. Hồ sơ danh sách trắng được bảo mật nhưng các cuộc gọi tổng hợp phải được bật có chọn lọc vì nó chặn tất cả các cuộc gọi tổng hợp theo mặc định.

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": [
    "SCMP_ARCH_X86_64",
    "SCMP_ARCH_X86",
    "SCMP_ARCH_X32"
  ],
  "syscalls": [
    {
      "names": [
        "<syscall-1>",
        "<syscall-2>",
        "<syscall-3>"
      ],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

Cấu hình sau được sử dụng để danh sách đen các cuộc gọi tổng hợp. Hồ sơ danh sách đen có bề mặt tấn công lớn hơn danh sách trắng.

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "architectures": [
    "SCMP_ARCH_X86_64",
    "SCMP_ARCH_X86",
    "SCMP_ARCH_X32"
  ],
  "syscalls": [
    {
      "names": [
        "<syscall-1>",
        "<syscall-2>",
        "<syscall-3>"
      ],
      "action": "SCMP_ACT_ERRNO"
    }
  ]
}

Cấu hình seccomp Docker chặn 60 trong số hơn 300 cuộc gọi tổng hợp trên kiến ​​trúc x86.

Cách sử dụng hồ sơ seccomp với Docker:

docker run -it --rm --security-opt seccomp=/root/custom.json docker/whalesay /bin/sh

Cách cho phép tất cả các cuộc gọi tổng hợp với vùng chứa:

docker run -it --rm --security-opt seccomp=unconfined docker/whalesay /bin/sh

# Verify
grep -i seccomp /proc/1/status

# Output should be:
Seccomp:         0

Cách sử dụng vùng chứa Docker để nhận thông tin liên quan đến thời gian chạy của vùng chứa:

docker run r.j3ss.co/amicontained amicontained

Seccomp trong Kubernetes

Chế độ điện toán an toàn (SECCOMP) là một tính năng của hạt nhân Linux. Bạn có thể sử dụng nó để hạn chế các tác vụ có sẵn trong vùng chứa. Tài liệu Seccomp

Cách chạy không kiểm soát trong Kubernetes:

kubectl run amicontained --image r.j3ss.co/amicontained amicontained -- amicontained

Kể từ phiên bản v1.20Kubernetes không triển khai seccomp theo mặc định.

Cấu hình docker Seccomp 'RuntimeDefault' trong Kubernetes:

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: amicontained
  name: amicontained
spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  containers:
  - args:
    - amicontained
    image: r.j3ss.co/amicontained
    name: amicontained
    securityContext:
      allowPrivilegeEscalation: false

Vị trí seccomp mặc định trong kubelet

/var/lib/kubelet/seccomp

Cách tạo hồ sơ seccomp trong nút:

mkdir -p /var/lib/kubelet/seccomp/profiles

# Add a profile for audit
vim /var/lib/kubelet/seccomp/profiles/audit.json
>>>
{
  defaultAction: "SCMP_ACT_LOG"
}

# Add a profile for violations (Blocks all syscalls by default, will let nothing run)
vim /var/lib/kubelet/seccomp/profiles/violation.json
>>>
{
  defaultAction: "SCMP_ACT_ERRNO"
}

Hồ sơ seccomp cục bộ - tệp này phải tồn tại cục bộ trên một nút để có thể hoạt động:

...
securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: profiles/audit.json
...

Cấu hình trên sẽ cho phép các cuộc gọi tổng hợp được lưu vào một tệp.

grep syscall /var/log/syslog

Cách ánh xạ số syscall với tên syscall:

grep -w 35 /usr/include/asm/unistd_64.h

# OR
grep -w 35 /usr/include/asm-generic/unistd.h

AppArmor

AppArmor là một mô-đun bảo mật Linux được sử dụng để giới hạn một chương trình trong một nhóm tài nguyên giới hạn.

Cách cài đặt AppArmor utils:

apt-get install apparmor-utils

Cách kiểm tra xem AppArmor có đang chạy và được kích hoạt hay không:

systemctl status apparmor

cat /sys/module/apparmor/parameters/enabled
Y

Các cấu hình AppArmor được lưu trữ tại:

cat /etc/apparmor.d/root.add_data.sh

Cách liệt kê hồ sơ AppArmor:

cat /sys/kernel/security/apparmor/profiles

Cách từ chối tất cả các cấu hình ghi tệp:

profile apparmor-deny-write flags=(attach_disconnected) {
  file,
  # Deny all file writes.
  deny /** w,
}

Cách từ chối ghi vào /proc tệp:

profile apparmor-deny-proc-write flags=(attach_disconnected) {
  file,
  # Deny all file writes.
  deny /proc/* w,
}

Cách từ chối remount root FS:

profile apparmor-deny-remount-root flags=(attach_disconnected) {

  # Deny all file writes.
  deny mount options=(ro, remount) -> /,
}

Cách kiểm tra trạng thái hồ sơ:

aa-status

Chế độ tải hồ sơ

  • Enforce, giám sát và thực thi các quy tắc
  • Complain, sẽ không thực thi các quy tắc nhưng ghi lại chúng dưới dạng các sự kiện
  • Unconfined, sẽ không thực thi hoặc ghi lại các sự kiện

Cách kiểm tra xem hồ sơ có hợp lệ không:

apparmor_parser /etc/apparmor.d/root.add_data.sh

Cách tắt cấu hình:

apparmor_parser -R /etc/apparmor.d/root.add_data.sh
ln -s /etc/apparmor.d/root.add_data.sh /etc/apparmor.d/disable/

Cách tạo hồ sơ và trả lời một loạt câu hỏi sau:

aa-genprof /root/add_data.sh

Cách tạo cấu hình cho một lệnh:

aa-genprof curl

Cách tắt cấu hình khỏi nhật ký:

aa-logprof

Cách sử dụng AppArmor trong Kubernetes

Để sử dụng AppArmor với Kubernetes, bạn phải đáp ứng các điều kiện tiên quyết sau:

  • Phiên bản Kubernetes phải lớn hơn1.4
  • Mô-đun AppArmor Kernel nên được bật
  • Cấu hình AppArmor phải được tải trong hạt nhân
  • Thời gian chạy vùng chứa phải được hỗ trợ

Cách sử dụng mẫu trong Kubernetes:

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-sleeper
  annotations:
    container.apparmor.security.beta.kubernetes.io/<container-name>: localhost/<profile-name>
spec:
  containers:
  - name: ubuntu-sleeper
    image: ubuntu
    command: ["sh", "-c", "echo 'Sleeping for an hour!' && sleep 1h"]

Lưu ý : Vùng chứa phải chạy trong nút chứa cấu hình AppArmor.

Khả năng của Linux

Tính năng khả năng của Linux chia nhỏ các đặc quyền có sẵn cho các quy trình chạy khi root người dùng thành các nhóm đặc quyền nhỏ hơn. Bằng cách này, một tiến trình đang chạy với root đặc quyền có thể bị giới hạn để chỉ nhận được những quyền tối thiểu mà nó cần để thực hiện hoạt động của nó.

Docker hỗ trợ các khả năng của Linux như một phần của lệnh chạy Docker: with --cap-add--cap-drop. Theo mặc định, một vùng chứa được khởi động với một số khả năng được cho phép theo mặc định và có thể bị loại bỏ. Các quyền khác có thể được thêm theo cách thủ công.

Cả hai --cap-add--cap-drophỗ trợ giá trị TẤT CẢ, để cho phép hoặc loại bỏ tất cả các khả năng. Theo mặc định, vùng chứa Docker chạy với 14 khả năng.

  • Kernel <2,2
    • Quy trình đặc quyền
    • Quy trình đặc quyền
  • Kernel> = 2.2
    • Quy trình đặc quyền
      • CAP_CHOWN
      • CAP_SYS_TIME
      • CAP_SYS_BOOT
      • CAP_NET_ADMIN

Tham khảo tài liệu này để biết danh sách đầy đủ các Khả năng của Linux .

Cách kiểm tra những khả năng mà lệnh cần:

getcap /usr/bin/ping

Cách nhận các khả năng của quy trình:

getpcaps <pid>

Cách thêm khả năng bảo mật:

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-sleeper
spec:
  containers:
  - name: ubuntu-sleeper
    image: ubuntu
    command: ["sleep", "1000"]
    securityContext:
      capabilities:
        add: ["SYS_TIME"]
        drop: ["CHOWN"]

Làm thế nào để chuẫn bị cho một kì thi

CKS được đánh giá là một kỳ thi khá khó. Nhưng dựa trên kinh nghiệm của tôi, tôi nghĩ rằng, với thực hành đủ tốt và nếu bạn hiểu các khái niệm mà kỳ thi bao gồm, nó sẽ có thể quản lý được trong vòng hai giờ.

Bạn chắc chắn cần hiểu các khái niệm cơ bản của Kubernetes. Và vì điều kiện tiên quyết đối với CKS là phải vượt qua kỳ thi CKA, bạn nên hiểu rõ về Kubernetes và cách nó hoạt động trước khi thử CKS.

Ngoài ra, để vượt qua CKS, bạn cần hiểu các mối đe dọa và tác động bảo mật được giới thiệu bởi điều phối vùng chứa.

Sự ra đời của kỳ thi CKS là một dấu hiệu cho thấy không nên coi nhẹ an ninh của các thùng chứa. Các cơ chế bảo mật phải luôn có sẵn để ngăn chặn các cuộc tấn công vào các cụm Kubernetes.

Vụ hack tiền điện tử Tesla nhờ vào bảng điều khiển Kubernetes không được bảo vệ, làm sáng tỏ những rủi ro liên quan đến Kubernetes hoặc bất kỳ công cụ điều phối vùng chứa nào khác. Hackerone có một trang tiền thưởng Kubernetes liệt kê các kho mã nguồn được sử dụng trong một cụm Kubernetes tiêu chuẩn.

Thực hành, Thực hành và Thực hành!

Thực hành là chìa khóa để bẻ khóa kỳ thi, cá nhân tôi thấy rằng các trình mô phỏng kỳ thi của KodeKloud và Killer.sh vô cùng hữu ích đối với tôi.

Tôi không có nhiều thời gian để chuẩn bị cho kỳ thi CKS như tôi đã có cho kỳ thi CKA, nhưng tôi đang làm việc trên Kubernetes trong công việc hàng ngày của mình nên tôi thực sự cảm thấy thoải mái với nó.

Thực hành là chìa khóa thành công. Chúc bạn may mắn với kỳ thi!

Nguồn: https://www.freecodecamp.org/news/how-to-pass-the-certified-kubernetes-security-specialist-exam/

#kubernetes 

Tubo Man

Tubo Man

1550715100

Where does Hyperledger Sawtooth store its ledger?

Where does Hyperledger Sawtooth store its ledger entries within the validator? Is it in a readable format?

What kind of a database does it maintain?

Can the transactions performed on the network be seen?

#hyperledger #blockchain

A gentle introduction to Hyperledger Sawtooth

Hyperledger Sawtooth is an open source project under the Hyperledger umbrella. It works as an enterprise-level blockchain system used for creating and operating distributed ledger applications and networks, particularly for use by enterprises.

Hyperledger Sawtooth is dubbed as an enterprise blockchain-as-a-service platform that can run customized smart contracts and logic without needing to know the underlying design of the core system. It also supports a variety of consensus algorithms, including Practical Byzantine Fault Tolerance (PBFT) and Proof of Elapsed Time (PoET), letting the user craft the performances of the blockchain in the most suitable way depending on the specific requirements.

Hyperledger is a development group sponsored by organizations such as the Linux Project, IBM, Intel, and SAP.

Sawtooth singularities

Sawtooth consensus algorithms

At the very core of the solidity of the blockchain architecture and, in the most general way, public ledgers, there is the consensus algorithm. The most traditional one is the Sakamoto Consensus Algorithm [2] that was designed to overcome the limits of the Byzantine Fault Tolerant (BFT) Consensus. Hyperledger Sawtooth provides three different consensus mechanisms: PoET, PBFT, and Raft.

Sawtooth PoET

Sawtooth Proof of Elapsed Time (PoET) is a Nakamoto-style consensus [2] algorithm that is designed to support large network populations. PoET relies on a “fair lottery” mechanism to select which node will add the next block: each node generates a random wait time during which nodes must sleep. The node with the shortest wait time will wake up first and win the lottery, thus being allowed to commit a new block to the blockchain. PoET is of course more energy efficient because nodes will not waste energy trying to put blocks in.

Sawtooth PBFT

Sawtooth Practical Byzantine Fault Tolerance (PBFT) (modified version with respect to the original PBFT [3]) is a voting-based consensus algorithm that provides Byzantine fault tolerance. It comes with the drawback of an exponentially increasing message count as nodes are added to the set.

Once the leader node proposes a new block to be added, a series of messages exchanged among the nodes starts. The algorithm provides a provable resistance to a percentage of malicious nodes that depends on the implementation.

Sawtooth Raft

Raft is a leader-based consensus algorithm that provides crash fault tolerance (CFT): the keystone of the system is the leader that is assumed to always act honestly. Blocks added by the leader have not been forged and its updates are trustworthy.

The leader has a cohort of nodes that will simply propagate the updates from the leader and, in the case a crash occurs to the leader after a given timeout, a new leader is elected among the followers.

This algorithm has a natural resilience to CFT. For instance, on a network of six nodes, the quorum to elect a new leader is four (one more than half of the six available nodes).

 

Raft has the advantage of being more efficient (also from an energy point of view) than PBFT and PoET because there is no competition to add blocks among nodes, wasting CPU time; updates are simply propagated as long as the leader is up and running.

Dev mode consensus

Let’s shortly describe the devmode consensus algorithm that is provided by Sawtooth to just let the developers understand how to write a consensus algorithm from scratch.

Dev mode is, as the smartest of you already understood, a consensus algorithm to be used just in development mode: it has no crash tolerance and uses a simple simplified random-leader selection.

Discussion

The algorithms above diverge from the classical PoW consensus for some reasons:

  • Sawtooth is designed for a scenario where the collaboration between the blocks committed by nodes are final, unlike lottery-style consensus algorithms such as Proof of Work (PoW) or Proof of Elapsed Time (PoET)
  • pBFT is commonly thought of as an algorithm that does not scale. This perception is usually brought on by the notion of a node == server, which should not be the case with pBFT when deployed in an enterprise production environment
  • pBFT should be used with a consortium of enterprise organizations, where each organization would represent a node on the network node == organization. Each of these organizational nodes should then have clusters of instances and load balancers behind the node’s endpoint to scale the computational power and ensure a quick response time

A sample application: Deploy a single-node Sawtooth installation

In this paragraph, we will start by deploying a single-node Sawtooth installation starting from a very simple Docker file that, for sake of simplicity, contains just the basic components needed for the demo.

In particular, we will deploy a single validator setting that is running a validator, a REST API, the dev mode consensus engine, and three transaction processors. The environment uses dev mode consensus and parallel transaction processing.

Sawtooth Node

To better understand how different this is from a more powerful setting, let’s compare it with a four validator node setting:

Four Validator Node Setting

Another simplification, with respect to a more realistic setting, is that we will use the dev mode consensus algorithm described above. I’ll explain how to change this to a more sensible consensus algorithm once the system works.

The repository and setup

We have provided a repository on GitHub for your convenience: you just have to clone from https://github.com/rosdec/single into a directory of your choice. Keep in mind that the suggested setting is under a Linux of choice, but with some more hammering, it will easily work under Windows or Mac OS.

Use Node 12 because some of the libraries are picky about the Node version. Install the dependencies and everything will be ready to run (further and detailed instructions are in the README on the repo).

The sample application has a very simple output and the whole logic behind it is not fancy: it will just store the payload (a string) in a specific address of the blockchain and it will retrieve it to check that everything works as expected.

Sawtooth Blockchain

A closer inspection of the code will help to understand what happens under the hood and will also let us catch the idea behind Sawtooth.

Source code inspection

The core of the sample application can be divided into two pieces: the processor (file processor/processor.js) and the interactions (file interact.js).

The processor is a sample transaction processor that expresses the full potential of Hyperledger Sawtooth: you can define what is a transaction and how it interacts with the blockchain storage.

This is a huge leap with respect to traditional blockchains (e.g., Ethereum and Bitcoin, of course) where transactions have a fixed way of interacting with the storage, mainly moving ethers or bitcoins between two or more accounts.

In Sawtooth, you can write your own processor in any language you prefer. In the sample application, our processor will simply store the transaction payload (a string) in a specific address (line 42). But you can design way more complex interactions, putting more logic at the transaction level instead of, for example, a smart contract.

Smart Contract With Sawtooth

This is the great advantage of using Sawtooth: it is a framework to write your own flavor of a blockchain, where logic can be pushed right in the transaction and not, necessarily, in smart contracts. As an example of this flexibility, you can check this repository where a transaction processor that will handle a tic-tac-toe game is described.

The interaction with the blockchain has just two methods, write_data and read_data, and both will interact with the blockchain by operating through the REST API (see the block in the diagram above). Reading from the blockchain is pretty straightforward; it is just the invocation of the API /state with the address from which to read.

Reading From Blockchain

Writing on the blockchain, on the other hand, consists of a specific sequence of steps. You can follow them in the interact.js file:

  1. First, the transaction header is created that, most importantly, will contain the transaction family. That is, the transaction processor that will be invoked to handle our transaction (lines 48–58). Second, the transaction is signed (lines 61–66) by using the private key of the subject who is sending it;
  2. Transactions are collected within a batch, a batch can collect transactions coming from different subjects and it is signed itself (lines 69–81);
  3. Once the signed batch of transactions is ready, it is encoded (lines 84–86) in order to be safely used in the API invocation (lines 89–93).

Changing the consensus algorithm

After inspecting the source code, let’s have a glimpse at the Docker-composed file named single-node.yaml. It contains exactly the five components depicted above:

  1. The transaction processor whose logic is described in the processor.js file;
  2. The Sawtooth REST API that will just specify on which port it will be bound;
  3. The mandatory settings transaction processor that allows interacting with the settings kept on the blockchain;
  4. The validator describes the configuration of the validator node. As you may expect, here it is where the consensus algorithm is specified (line 48). In this version, it is specified that we will use the dev mode algorithm;
  5. The devmode engine contains the (few) configurations of this specific algorithm

Changing the consensus algorithm is pretty simple: just modify the configuration of the validator node by choosing the algorithm you intend to use. For sake of clarity, we have used the dev mode engine, which runs comfortably with a single node; more complex algorithms need at least four nodes and, coherently, the docker-compose file is more complex.

As an example, check the GitHub that contains the configurations to use pBFT as a consensus algorithm (line 138) and how such an algorithm is set up for use in this scenario (lines 300–304); pBFT needs at least four nodes to work (because of the leader election), so you will find four validators nodes and, analogously, four pBFT engines, one for each validator.

Conclusion

Hyperledger Sawtooth is capable of accommodating a wide range of different blockchain configurations, allowing us to customize the way and the means of transactions. The consensus algorithm, which is central in the way the blockchain actually behaves, is configurable and, out of the box, an array of options are available in order to carefully select the performance of the blockchain and the resistance to Byzantine attacks.

Source: https://blog.logrocket.com/hyperledger-sawtooth-introduction/

#hyperledger #sawtooth

Una Suave introducción A Hyperledger Sawtooth

Hyperledger Sawtooth es un proyecto de código abierto bajo el paraguas de Hyperledger. Funciona como un sistema de cadena de bloques de nivel empresarial que se utiliza para crear y operar aplicaciones y redes de registros distribuidos, particularmente para uso de empresas.

Hyperledger Sawtooth se conoce como una plataforma empresarial de cadena de bloques como servicio que puede ejecutar contratos inteligentes personalizados y lógica sin necesidad de conocer el diseño subyacente del sistema central. También es compatible con una variedad de algoritmos de consenso, incluida la tolerancia práctica a fallas bizantinas (PBFT) y la prueba de tiempo transcurrido (PoET), lo que permite al usuario diseñar el rendimiento de la cadena de bloques de la manera más adecuada según los requisitos específicos.

Hyperledger es un grupo de desarrollo patrocinado por organizaciones como Linux Project, IBM, Intel y SAP.

Singularidades de diente de sierra

Algoritmos de consenso de diente de sierra

En el núcleo mismo de la solidez de la arquitectura de la cadena de bloques y, en general, de los libros de contabilidad públicos, se encuentra el algoritmo de consenso. El más tradicional es el Algoritmo de Consenso de Sakamoto [2] que fue diseñado para superar los límites del Consenso de Tolerancia a Fallos Bizantinos (BFT). Hyperledger Sawtooth proporciona tres mecanismos de consenso diferentes: PoET, PBFT y Raft.

PoET diente de sierra

Sawtooth Proof of Elapsed Time (PoET) es un algoritmo de consenso al estilo de Nakamoto [2] que está diseñado para admitir grandes poblaciones de redes. PoET se basa en un mecanismo de "lotería justa" para seleccionar qué nodo agregará el siguiente bloque: cada nodo genera un tiempo de espera aleatorio durante el cual los nodos deben dormir. El nodo con el tiempo de espera más corto se despertará primero y ganará la lotería, lo que le permitirá enviar un nuevo bloque a la cadena de bloques. Por supuesto, PoET es más eficiente energéticamente porque los nodos no desperdiciarán energía tratando de colocar bloques.

PBFT de diente de sierra

Sawtooth Practical Byzantine Fault Tolerance (PBFT) (versión modificada con respecto al PBFT original [3]) es un algoritmo de consenso basado en votación que proporciona tolerancia a fallas bizantinas. Viene con el inconveniente de un recuento de mensajes que aumenta exponencialmente a medida que se agregan nodos al conjunto.

Una vez que el nodo líder propone agregar un nuevo bloque, comienza una serie de mensajes intercambiados entre los nodos. El algoritmo proporciona una resistencia demostrable a un porcentaje de nodos maliciosos que depende de la implementación.

balsa de dientes de sierra

Raft es un algoritmo de consenso basado en líder que proporciona tolerancia a fallas de choque (CFT): la piedra angular del sistema es el líder que se supone que siempre actúa con honestidad. Los bloques agregados por el líder no han sido falsificados y sus actualizaciones son confiables.

El líder tiene una cohorte de nodos que simplemente propagarán las actualizaciones del líder y, en caso de que el líder se bloquee después de un tiempo de espera determinado, se elige un nuevo líder entre los seguidores.

Este algoritmo tiene una resistencia natural a CFT. Por ejemplo, en una red de seis nodos, el quórum para elegir un nuevo líder es de cuatro (uno más de la mitad de los seis nodos disponibles).

 

Raft tiene la ventaja de ser más eficiente (también desde el punto de vista energético) que PBFT y PoET porque no hay competencia para agregar bloques entre nodos, desperdiciando tiempo de CPU; las actualizaciones simplemente se propagan siempre que el líder esté en funcionamiento.

Consenso del modo de desarrollo

Describamos brevemente el algoritmo de consenso devmode que proporciona Sawtooth para que los desarrolladores entiendan cómo escribir un algoritmo de consenso desde cero.

El modo Dev es, como el más inteligente de ustedes ya entendió, un algoritmo de consenso que se usa solo en el modo de desarrollo: no tiene tolerancia a fallas y usa una selección de líder aleatorio simple y simplificada.

Discusión

Los algoritmos anteriores difieren del consenso PoW clásico por algunas razones:

  • Sawtooth está diseñado para un escenario en el que la colaboración entre los bloques comprometidos por los nodos es definitiva, a diferencia de los algoritmos de consenso de tipo lotería, como la Prueba de trabajo (PoW) o la Prueba de tiempo transcurrido (PoET)
  • pBFT se considera comúnmente como un algoritmo que no escala. Esta percepción generalmente es provocada por la noción de un nodo == servidor, lo que no debería ser el caso con pBFT cuando se implementa en un entorno de producción empresarial.
  • pBFT debe usarse con un consorcio de organizaciones empresariales, donde cada organización representaría un nodo en la red nodo == organización. Cada uno de estos nodos organizacionales debe tener grupos de instancias y balanceadores de carga detrás del punto final del nodo para escalar la potencia computacional y garantizar un tiempo de respuesta rápido.

Una aplicación de muestra: implementar una instalación Sawtooth de un solo nodo

En este párrafo, comenzaremos implementando una instalación de Sawtooth de un solo nodo a partir de un archivo Docker muy simple que, en aras de la simplicidad, contiene solo los componentes básicos necesarios para la demostración.

En particular, implementaremos una única configuración de validador que ejecuta un validador, una API REST, el motor de consenso del modo de desarrollo y tres procesadores de transacciones. El entorno utiliza el consenso del modo de desarrollo y el procesamiento de transacciones en paralelo.

 

Para comprender mejor cuán diferente es esto de una configuración más potente, comparémoslo con una configuración de cuatro nodos de validación:

 

Otra simplificación, con respecto a una configuración más realista, es que usaremos el algoritmo de consenso del modo desarrollador descrito anteriormente. Explicaré cómo cambiar esto a un algoritmo de consenso más sensato una vez que el sistema funcione.

El repositorio y la configuración

Hemos proporcionado un repositorio en GitHub para su comodidad: solo tiene que clonar desde https://github.com/rosdec/single en un directorio de su elección. Tenga en cuenta que la configuración sugerida está bajo un Linux de elección, pero con un poco más de martillazos, funcionará fácilmente bajo Windows o Mac OS.

Use Node 12 porque algunas de las bibliotecas son exigentes con la versión de Node. Instale las dependencias y todo estará listo para ejecutarse (las instrucciones adicionales y detalladas se encuentran en el LÉAME del repositorio).

La aplicación de muestra tiene una salida muy simple y toda la lógica detrás de ella no es elegante: simplemente almacenará la carga útil (una cadena) en una dirección específica de la cadena de bloques y la recuperará para verificar que todo funcione como se esperaba.

 

Una inspección más cercana del código ayudará a comprender lo que sucede debajo del capó y también nos permitirá captar la idea detrás de Sawtooth.

Inspección de código fuente

El núcleo de la aplicación de ejemplo se puede dividir en dos partes: el procesador (archivo procesador/procesador.js) y las interacciones (archivo interact.js).

El procesador es un procesador de transacciones de muestra que expresa todo el potencial de Hyperledger Sawtooth: puede definir qué es una transacción y cómo interactúa con el almacenamiento de la cadena de bloques.

Este es un gran salto con respecto a las cadenas de bloques tradicionales (por ejemplo, Ethereum y Bitcoin, por supuesto) donde las transacciones tienen una forma fija de interactuar con el almacenamiento, principalmente moviendo ethers o bitcoins entre dos o más cuentas.

En Sawtooth, puede escribir su propio procesador en cualquier idioma que prefiera. En la aplicación de muestra, nuestro procesador simplemente almacenará la carga útil de la transacción (una cadena) en una dirección específica (línea 42). Pero puede diseñar interacciones mucho más complejas, poniendo más lógica en el nivel de transacción en lugar de, por ejemplo, un contrato inteligente.

 

Esta es la gran ventaja de usar Sawtooth: es un marco para escribir su propio sabor de una cadena de bloques, donde la lógica se puede impulsar directamente en la transacción y no, necesariamente, en los contratos inteligentes. Como ejemplo de esta flexibilidad, puede consultar este repositorio donde se describe un procesador de transacciones que manejará un juego de tres en raya.

La interacción con la cadena de bloques tiene solo dos métodos, write_datay read_dataambos interactuarán con la cadena de bloques operando a través de la API REST (ver el bloque en el diagrama de arriba). La lectura de la cadena de bloques es bastante sencilla; es solo la invocación de la API /estado con la dirección desde la que leer.

 

Escribir en la cadena de bloques, por otro lado, consiste en una secuencia específica de pasos. Puedes seguirlos en el interact.jsarchivo:

  1. Primero, se crea el encabezado de la transacción que, lo más importante, contendrá la familia de transacciones. Es decir, el procesador de transacciones que se invocará para manejar nuestra transacción (líneas 48–58). En segundo lugar, la transacción se firma (líneas 61 a 66) utilizando la clave privada del sujeto que la envía;
  2. Las transacciones se recopilan dentro de un lote, un lote puede recopilar transacciones provenientes de diferentes sujetos y se firma en sí mismo (líneas 69 a 81);
  3. Una vez que el lote de transacciones firmado está listo, se codifica (líneas 84 a 86) para poder usarlo de forma segura en la invocación de la API (líneas 89 a 93).

Cambiar el algoritmo de consenso

Después de inspeccionar el código fuente, echemos un vistazo al archivo compuesto por Docker llamado single-node.yaml. Contiene exactamente los cinco componentes descritos anteriormente:

  1. El procesador de transacciones cuya lógica se describe en el processor.jsarchivo;
  2. La API REST de Sawtooth que solo especificará en qué puerto se vinculará;
  3. El procesador de transacciones de configuración obligatoria que permite interactuar con la configuración guardada en la cadena de bloques;
  4. El validador describe la configuración del nodo validador. Como es de esperar, aquí es donde se especifica el algoritmo de consenso (línea 48). En esta versión, se especifica que usaremos el algoritmo del modo dev;
  5. El motor devmode contiene las (pocas) configuraciones de este algoritmo específico

Cambiar el algoritmo de consenso es bastante simple: simplemente modifique la configuración del nodo de validación eligiendo el algoritmo que pretende usar. En aras de la claridad, hemos utilizado el motor de modo de desarrollo, que funciona cómodamente con un solo nodo; los algoritmos más complejos necesitan al menos cuatro nodos y, coherentemente, el archivo docker-compose es más complejo.

Como ejemplo, verifique el GitHub que contiene las configuraciones para usar pBFT como un algoritmo de consenso (línea 138) y cómo se configura dicho algoritmo para su uso en este escenario (líneas 300–304); pBFT necesita al menos cuatro nodos para funcionar (debido a la elección del líder), por lo que encontrará cuatro nodos validadores y, análogamente, cuatro motores pBFT, uno para cada validador.

Conclusión

Hyperledger Sawtooth es capaz de acomodar una amplia gama de diferentes configuraciones de blockchain, lo que nos permite personalizar la forma y los medios de las transacciones. El algoritmo de consenso, que es central en la forma en que la cadena de bloques realmente se comporta, es configurable y, listo para usar, hay una variedad de opciones disponibles para seleccionar cuidadosamente el rendimiento de la cadena de bloques y la resistencia a los ataques bizantinos.

Fuente: https://blog.logrocket.com/hyperledger-sawtooth-introduction/ 

#hyperledger #sawtooth 

Deploying DAML Smart Contracts on Hyperledger Sawtooth

In our last blog, Deploying DAML based Smart Contracts on project:DABL, we deployed our daml application on project:DABL, a blockchain platform by digital asset. We also discussed how DAML provides support on multiple blockchain platforms like hyperledger sawtooth, fabric, Corda etc.

In this blog we will take a step further in our DAML journey and deploy our application on another blockchain platform which is Hyperledger Sawtooth.

Hyperledger Sawtooth

So before jumping to deployment of applications and all the technical stuff, let’s just have a small introduction to sawtooth.

Hyperledger Sawtooth is an open source Blockchain platform founded by the Linux Foundation’s open-source blockchain project, Hyperledger. It is an enterprise-grade distributed ledger and was one of the first projects under the Hyperledger umbrella.

Hyperledger is a home to different distributed ledger frameworks like hyperledger fabric, Indy, and our today’s main focus which is hyperledger sawtooth.

Some Advantages of hyperledger sawtooth are :

  1. Permissioned/Permission less: Sawtooth can be configured to be either permissioned or permission less. By default, Hyperledger Sawtooth is permissioned.
  2. Scaleable: sawtooth can handle large amounts of transactions. Depending on the number of transactions it can be scaled easily.
  3. Multi-Language support: sawtooth allows developing smart contracts in Python, JavaScript, Rust, C++, and Go.
  4. Loose coupling architecture. The blocks within the Sawtooth’s network are not highly dependent on each other, which means that the change that is made to one element would not affect the network as a whole. It offers smart contract abstraction to allow developers to create contract logic in the programming language of their choice.

Now that we know what hyperledger sawtooth is let’s us understand how we can take DAML application and deploy it on sawtooth

#scala #daml #hyperledger #sawtooth