Create, Get and Delete Secrets in AWS Parameter Store using CLI

Hello Readers!! In this blog, we will see how to create, get and delete secrets in the AWS parameter store using CLI. In my previous blog, we have seen what is AWS Parameter store and how we can create parameters using the AWS console. Follow the below blog for more information:

https://blog.knoldus.com/getting-started-with-aws-parameter-store/

Prerequisites:

Install AWS CLI on your system. Follow the following blog for steps for installation:

https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

Configure AWS CLI.

https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html

Now, let’s get started with AWS CLI!!

Create parameter in Parameter store:

Use put-parameter to create and store a parameter in the AWS Parameter store. Below is the format for reference:

$ aws ssm put-parameter --name <name_of_parameter> --value <parameter_value> --type <type_of_parameter>

$ aws ssm put-parameter --name LINUX-AMI --value abcd12345 --type String 

For verifying that everything is stored in the file use get-parameter. So, for pulling the parameter use the following format:

$ aws ssm get-parameter --name <name_of_parameter>

$ aws ssm get-parameter --name LINUX-AMI

We can now see the value. As this parameter is of type string. So, it is not encrypted.

What if we want to store a password or an API key which I do not want to reveal. So, for this use type as SecureString.

$ aws ssm put-parameter --name <name_of_parameter> --value <parameter_value> --type SecureString

$ aws ssm put-parameter --name Password --value mySecretPasswordhere --type SecureString

Now, if I want to get this parameter then it will not give me the actual value. It will provide parameter store value in encrypted format because it is of type SecureString. Use the following command for getting the value:

$ aws ssm get-parameter --name <name_of_parameter>

$ aws ssm get-parameter --name Password

If we want to get this value in decrypted format. Use the following command:

$ aws ssm get-parameter --name <name_of_parameter> –with-decryption

$ aws ssm get-parameter --name Password –with-decryption

Create Nested Parameter store:

Now, we will see how we can create a hierarchical parameter store or we can say nested parameter store. For this use the below command:

$ aws ssm put-parameter --name <nested_path_for_parameter> --value <parameter_value> --type SecureString

$ aws ssm put-parameter --name /myDb/MySQL/Db_password --value myDBSecretPasswordhere --type SecureString

We can see in the AWS console also:

It is created. 

For getting parameters use the command:

$ aws ssm get-parameter --name /myDb/MySQL/Db_password 

As its type is SecureString it is in an encrypted format.

Update the parameter value:

If I want to update the existing parameter value use –overwrite flag. It will create a new version of that parameter store. Use the below command for updating the value:

$ aws ssm put-parameter --name <name_of_parameter> --overwrite --value <parameter_new_value> --type String

$ aws ssm put-parameter --name LINUX-AMI --overwrite --value new_password --type String

Create a parameter in other tiers:

By default, any parameter is created in the standard tier. But If you want to create in the Advanced tier use:

$  aws ssm put-parameter --name <name_of_parameter>  --value <parameter_value> --type <type> --tier Advanced

$  aws ssm put-parameter --name my_Password --value mySecretPasswordhere --type SecureString --tier Advanced

As you can see below advanced tier parameter in the AWS console:

Delete a parameter from the parameter store:

For deleting a parameter from the parameter store use the following command:

$ aws ssm delete-parameter --name my_Password 

$ aws ssm delete-parameter --name my_Password 

If I will try to get this parameter it will show ParameterNotFound.

We are all done now!!

Conclusion:

Thank you for sticking to the end. In this blog, we have learned how to create, get and delete secrets in the AWS parameter stores using CLI. This is really very quick and simple.  I hope this blog helped you somewhere. If you like this blog, please share my blog and show your appreciation by giving thumbs-ups, and don’t forget to give me suggestions on how I can improve my future blogs that can suit your needs.

Original article source at: https://blog.knoldus.com/

#aws #store #cli #delete #secret 

Sealed Secrets for Kubernetes

In this blog we will learn about secrets management in Kubernetes. This will be a descriptive blog and it will be followed by a practical implementation of sealed secrets in the upcoming blog. We will know how sealed secrets will help us follow the Gitops approach where secret manifests can be safely stored in a GitHub repository post encryption.

What is Kubernetes?

Kubernetes is an open-source container orchestration engine for automating deployment, scaling, and managing containerized applications. The open-source project is hosted by the Cloud Native Computing Foundation. Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates declarative configuration and automation. It has a large, rapidly growing ecosystem. There are many resources or objects used in Kubernetes.

Secrets in Kubernetes

Secrets in Kubernetes are the resource that manages the deployment of sensitive information, such as passwords, OAuth tokens, and SSH keys. It is suggested to store the sensitive information as a secret resource rather than having it imbibed in an environment variable. Secrets can be mounted as data volumes or exposed as environment variables to the containers in a Kubernetes Pod. Secrets in k8s are stored in a centralized repository named etcd in a base64 encoded format.

Problems with secrets in Kubernetes

The data in a Secret is obfuscated by using merely Base64 encoding. This encoding method does not encrypt the data within it. 

 Storing such files in a Git repository is highly insecure as it is easy to decode the Base64-encoded data. Anyone can accidentally commit the manifest files into the Git repositories, thus exposing sensitive information, such as credentials, tokens, or ssh keys.

Applications may also tend to expose the secrets in audit logs and monitoring systems.

Suggestions for secret management

We can follow these steps to safely use the secrets in Kubernetes:

1. Enable Encryption at Rest
2. Enable or configure RBAC rules to restrict access to the secrets in a cluster
3. Restrict Secret access to specific containers, or the containers that require access to the secret to perform their operations.
4. Consider using external Secret store providers

What are sealed secrets?

Sealed Secrets are the resource in Kubernetes that are basically encrypted Secrets that can be created by anyone, but can only be decrypted by the controller running in the target cluster. The Sealed Secret is safe to share publicly and upload to git repositories. Once the Sealed Secret is safely uploaded to the target Kubernetes cluster, the sealed secrets controller will decrypt it and recover the original Secret. 

Why to use sealed secrets?

If we follow the Gitops approach, there should be a single source of truth, which means all the manifests, configuration files, and deployment YAMLs should be present in the same repository. We cannot store sensitive information like passwords or secret tokens in a GitHub repository. This is a huge risk because the original sensitive credentials and values can easily be derived from the base64 encoding format.

Components of Sealed Secrets

Sealed secrets are comprised of these three components for their functionality:

1. A controller deployed to the cluster
2. A CLI tool called kubeseal
3. A customer resource definition called Sealed Secret

Controller: It is responsible for managing the sealed secret deployment. The primary task of the controller is to manage the private and public keys for encryption and decryption purposes.

Kubeseal: It is a CLI tool that creates a CRD for sealed secrets from a secret. It communicates with the controller and retrieves the public key needed for encrypting the secrets.

CRD: It is a custom resource definition that we can apply in our Kubernetes cluster to create a secret.

How to use Sealed Secrets?

The controller generates a 4096-bit RSA key pair. The private key is stored in the form of a secret whereas the public key is made public to encrypt the secret.

Kubeseal uses this public key from the controller to seal the secret values.

The value is symmetrically encrypted using AES-256 with a randomly generated session key. 

The session key is asymmetrically encrypted with the controller’s public key using SHA256.

Kubeseal creates a CRD for a sealed secret that can be safely pushed to the repository.

When the CRD Is applied in the cluster, the controller unseals it using the private key and creates a secret resource in the defined namespace. 

Original article source at: https://blog.knoldus.com/

#kubernetes #secret 

How to Use sealed secrets in Kubernetes

This is a practical implementation of the previous blog: Introduction to Sealed Secrets in Kubernetes. In this blog, we will create secrets in Kubernetes with the help of sealed secrets.

Pre-requisites:

1. controlplane with access to a k8s cluster

Install kubeseal

Kubeseal is a CLI tool that seals a secret with the help of the controller’s public key and creates a CRD for the sealed secret.

wget https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.19.2/kubeseal-0.19.2-linux-amd64.tar.gz

tar -xvzf kubeseal-0.19.2-linux-amd64.tar.gz

install -m 755 kubeseal /usr/local/bin/kubeseal

Install Sealed Secret Controller on Kubernetes

Sealed secret controller will create a key pair consisting of a private and a public key to encrypt and decrypt a secret.

kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.19.2/controller.yaml

Check the logs of the controller

It will search for a secret with the label sealedsecrets.bitnami.com/sealed-secrets-key in its namespace. If it does not get one, it will create a new one in its namespace and will print the public key portion of the key pair to its output logs.

Check the secret created by the controller to hold the private key

kubectl get secret -n kube-system -l sealedsecrets.bitnami.com/sealed-secrets-key -o yaml

This will display the tls.crt and tls.key.

Create secret.yaml

apiVersion: v1
kind: Secret
metadata:
name: sealed-secret
namespace: test
data:
DB_PASSWORD: ZGJwYXNzCg==

Create Sealed Secret via kubeseal

cat secret.yaml | kubeseal \
--controller-namespace kube-system \
--controller-name sealed-secrets-controller \
--format yaml \
> sealed-secret.yaml

Apply the sealed secret

kubectl create ns test

kubectl apply -f sealed-secret.yaml

Check if the sealed secret is created or not

kubectl get sealedsecret -n test -o yaml

Check if the secret is created or not

kubectl get secret sealed-secret -n test -o yaml

Sealed secrets manage the secrets created by the controller

If we delete the sealedsecret, the corresponding secret will also be deleted

Disaster Recovery for sealed secrets

Without the private key that is managed by the controller, there is no way to decrypt the encrypted data within a SealedSecret.

• Create a backup of the private key and copy the content to a master.yaml file
  kubectl get secret -n kube-system -l sealedsecrets.bitnami.com/sealed-secrets-key -o yaml > master.yaml
• Delete the secret and sealed secret created previously
  kubectl delete secret -n kube-system -l sealedsecrets.bitnami.com/sealed-secrets-key
• Delete the controllers deployment from the cluster
  kubectl delete -f https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.19.2/controller.yaml
• Apply the secret containing the private key.
  kubectl apply -f master.yaml
• Deploy the controller again
  kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.19.2/controller.yaml
• Check the logs of the controller
  Controller will fetch the existing secret before trying to create a new key-pair. If it finds the key-pair, it wont create a new one.
  

As it depicts, the controller took the private key present in the secret called sealed-secrets-key9b5qd.

Original article source at: https://blog.knoldus.com/

#kubernetes #secret 

Driftwood: Private Key Usage Verification

Driftwood   

Driftwood is a tool that can enable you to lookup whether a private key is used for things like TLS or as a GitHub SSH key for a user.

Driftwood performs lookups with the computed public key, so the private key never leaves where you run the tool. Additionally it supports some basic password cracking for encrypted keys.

Installation

Three easy ways to get started.

Run with Docker

cat private.key | docker run --rm -i trufflesecurity/driftwood --pretty-json -

Run pre-built binary

Download the binary from the releases page and run it.

Build yourself

go install github.com/trufflesecurity/driftwood@latest

Usage

Minimal usage is

$ driftwood path/to/privatekey.pem

Run with --help to see more options.

Library Usage

Packages under pkg/ are libraries that can be used for external consumption. Packages under pkg/exp/ are considered to be experimental status and may have breaking changes.

Download Details:

Author: Trufflesecurity
Source Code: https://github.com/trufflesecurity/driftwood 
License: Apache-2.0 license

#go #golang #secret #key 

Gitleaks: Protect and Discover Secrets using Gitleaks

Gitleaks

┌─○───┐
│ │╲  │
│ │ ○ │
│ ○ ░ │
└─░───┘

Gitleaks is a SAST tool for detecting and preventing hardcoded secrets like passwords, api keys, and tokens in git repos. Gitleaks is an easy-to-use, all-in-one solution for detecting secrets, past or present, in your code.

➜  ~/code(master) gitleaks detect --source . -v

    ○
    │╲
    │ ○
    ○ ░
    ░    gitleaks


Finding:     "export BUNDLE_ENTERPRISE__CONTRIBSYS__COM=cafebabe:deadbeef",
Secret:      cafebabe:deadbeef
RuleID:      sidekiq-secret
Entropy:     2.609850
File:        cmd/generate/config/rules/sidekiq.go
Line:        23
Commit:      cd5226711335c68be1e720b318b7bc3135a30eb2
Author:      John
Email:       john@users.noreply.github.com
Date:        2022-08-03T12:31:40Z
Fingerprint: cd5226711335c68be1e720b318b7bc3135a30eb2:cmd/generate/config/rules/sidekiq.go:sidekiq-secret:23

Getting Started

Gitleaks can be installed using Homebrew, Docker, or Go. Gitleaks is also available in binary form for many popular platforms and OS types on the releases page. In addition, Gitleaks can be implemented as a pre-commit hook directly in your repo or as a GitHub action using Gitleaks-Action.

Installing

# MacOS
brew install gitleaks

# Docker (DockerHub)
docker pull zricethezav/gitleaks:latest
docker run -v ${path_to_host_folder_to_scan}:/path zricethezav/gitleaks:latest [COMMAND] --source="/path" [OPTIONS]

# Docker (ghcr.io)
docker pull ghcr.io/zricethezav/gitleaks:latest
docker run -v ${path_to_host_folder_to_scan}:/path zricethezav/gitleaks:latest [COMMAND] --source="/path" [OPTIONS]

# From Source
git clone https://github.com/zricethezav/gitleaks.git
cd gitleaks
make build

Github Action

Check out the official Gitleaks GitHub Action

name: gitleaks
on: [pull_request, push, workflow_dispatch]
jobs:
  scan:
    name: gitleaks
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0
      - uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE}} # Only required for Organizations, not personal accounts.

Pre-Commit

Install pre-commit from https://pre-commit.com/#install

Create a .pre-commit-config.yaml file at the root of your repository with the following content:

repos:
  - repo: https://github.com/zricethezav/gitleaks
    rev: v8.12.0
    hooks:
      - id: gitleaks

for a native execution of GitLeaks or use the gitleaks-docker pre-commit ID for executing GitLeaks using the official Docker images

Auto-update the config to the latest repos' versions by executing pre-commit autoupdate

Install with pre-commit install

Now you're all set!

➜ git commit -m "this commit contains a secret"
Detect hardcoded secrets.................................................Failed

Note: to disable the gitleaks pre-commit hook you can prepend SKIP=gitleaks to the commit command and it will skip running gitleaks

➜ SKIP=gitleaks git commit -m "skip gitleaks check"
Detect hardcoded secrets................................................Skipped

Usage

Usage:
  gitleaks [command]

Available Commands:
  completion  generate the autocompletion script for the specified shell
  detect      Detect secrets in code
  help        Help about any command
  protect     Protect secrets in code
  version     Display gitleaks version

Flags:
  -c, --config string          config file path
                               order of precedence:
                               1. --config/-c
                               2. env var GITLEAKS_CONFIG
                               3. (--source/-s)/.gitleaks.toml
                               If none of the three options are used, then gitleaks will use the default config
      --exit-code string       exit code when leaks have been encountered (default: 1)
  -h, --help                   help for gitleaks
  -l, --log-level string       log level (debug, info, warn, error, fatal) (default "info")
      --no-banner              suppress banner
      --redact                 redact secrets from logs and stdout
  -f, --report-format string   output format (json, csv, sarif)
  -r, --report-path string     report file
  -b, --baseline-path          path to a previously generated report with known issues that gitleaks should ignore
  -s, --source string          path to source (git repo, directory, file)
  -v, --verbose                show verbose output from scan
  --max-target-megabytes       files larger than this will be skipped

Use "gitleaks [command] --help" for more information about a command.

Commands

There are two commands you will use to detect secrets; detect and protect.

Detect

The detect command is used to scan repos, directories, and files. This command can be used on developer machines and in CI environments.

When running detect on a git repository, gitleaks will parse the output of a git log -p command (you can see how this executed here). git log -p generates patches which gitleaks will use to detect secrets. You can configure what commits git log will range over by using the --log-opts flag. --log-opts accepts any option for git log -p. For example, if you wanted to run gitleaks on a range of commits you could use the following command: gitleaks detect --source . --log-opts="--all commitA..commitB". See the git log documentation for more information.

You can scan files and directories by using the --no-git option.

Protect

The protect command is used to uncommitted changes in a git repo. This command should be used on developer machines in accordance with shifting left on security. When running protect on a git repository, gitleaks will parse the output of a git diff command (you can see how this executed here). You can set the --staged flag to check for changes in commits that have been git added. The --staged flag should be used when running Gitleaks as a pre-commit.

NOTE: the protect command can only be used on git repos, running protect on files or directories will result in an error message.

Creating a baseline

When scanning large repositories or repositories with a long history, it can be convenient to use a baseline. When using a baseline, gitleaks will ignore any old findings that are present in the baseline. A baseline can be any gitleaks report. To create a gitleaks report, run gitleaks with the --report-path parameter.

gitleaks detect --report-path gitleaks-report.json # This will save the report in a file called gitleaks-report.json

Once as baseline is created it can be applied when running the detect command again:

gitleaks detect --baseline-path gitleaks-report.json --report-path findings.json

After running the detect command with the --baseline-path parameter, report output (findings.json) will only contain new issues.

Verify Findings

You can verify a finding found by gitleaks using a git log command. Example output:

Finding:     aws_secret="AKIAIMNOJVGFDXXXE4OA"
RuleID:      aws-access-token
Secret       AKIAIMNOJVGFDXXXE4OA
Entropy:     3.65
File:        checks_test.go
Line:        37
Commit:      ec2fc9d6cb0954fb3b57201cf6133c48d8ca0d29
Author:      Zachary Rice
Email:       z@email.com
Date:        2018-01-28T17:39:00Z
Fingerprint: ec2fc9d6cb0954fb3b57201cf6133c48d8ca0d29:checks_test.go:aws-access-token:37

We can use the following format to verify the leak:

git log -L {StartLine,EndLine}:{File} {Commit}

So in this example it would look like:

git log -L 37,37:checks_test.go ec2fc9d6cb0954fb3b57201cf6133c48d8ca0d29

Which gives us:

commit ec2fc9d6cb0954fb3b57201cf6133c48d8ca0d29
Author: zricethezav <thisispublicanyways@gmail.com>
Date:   Sun Jan 28 17:39:00 2018 -0500

    [update] entropy check

diff --git a/checks_test.go b/checks_test.go
--- a/checks_test.go
+++ b/checks_test.go
@@ -28,0 +37,1 @@
+               "aws_secret= \"AKIAIMNOJVGFDXXXE4OA\"":          true,

Pre-Commit hook

You can run Gitleaks as a pre-commit hook by copying the example pre-commit.py script into your .git/hooks/ directory.

Configuration

Gitleaks offers a configuration format you can follow to write your own secret detection rules:

# Title for the gitleaks configuration file.
title = "Gitleaks title"

# Extend the base (this) configuration. When you extend a configuration
# the base rules take precendence over the extended rules. I.e, if there are
# duplicate rules in both the base configuration and the extended configuration
# the base rules will override the extended rules.
# Another thing to know with extending configurations is you can chain together
# multiple configuration files to a depth of 2. Allowlist arrays are appended
# and can contain duplicates.
# useDefault and path can NOT be used at the same time. Choose one.
[extend]
# useDefault will extend the base configuration with the default gitleaks config:
# https://github.com/zricethezav/gitleaks/blob/master/config/gitleaks.toml
useDefault = true
# or you can supply a path to a configuration. Path is relative to where gitleaks
# was invoked, not the location of the base config.
path = "common_config.toml"

# An array of tables that contain information that define instructions
# on how to detect secrets
[[rules]]

# Unique identifier for this rule
id = "awesome-rule-1"

# Short human readable description of the rule.
description = "awesome rule 1"

# Golang regular expression used to detect secrets. Note Golang's regex engine
# does not support lookaheads.
regex = '''one-go-style-regex-for-this-rule'''

# Golang regular expression used to match paths. This can be used as a standalone rule or it can be used
# in conjunction with a valid `regex` entry.
path = '''a-file-path-regex'''

# Array of strings used for metadata and reporting purposes.
tags = ["tag","another tag"]

# Int used to extract secret from regex match and used as the group that will have
# its entropy checked if `entropy` is set.
secretGroup = 3

# Float representing the minimum shannon entropy a regex group must have to be considered a secret.
entropy = 3.5

# Keywords are used for pre-regex check filtering. Rules that contain
# keywords will perform a quick string compare check to make sure the
# keyword(s) are in the content being scanned. Ideally these values should
# either be part of the idenitifer or unique strings specific to the rule's regex
# (introduced in v8.6.0)
keywords = [
  "auth",
  "password",
  "token",
]

# You can include an allowlist table for a single rule to reduce false positives or ignore commits
# with known/rotated secrets
[rules.allowlist]
description = "ignore commit A"
commits = [ "commit-A", "commit-B"]
paths = [
  '''go\.mod''',
  '''go\.sum'''
]
regexes = [
  '''process''',
  '''getenv''',
]
# note: stopwords targets the extracted secret, not the entire regex match
# like 'regexes' does. (stopwords introduced in 8.8.0)
stopwords = [
  '''client''',
  '''endpoint''',
]


# This is a global allowlist which has a higher order of precedence than rule-specific allowlists.
# If a commit listed in the `commits` field below is encountered then that commit will be skipped and no
# secrets will be detected for said commit. The same logic applies for regexes and paths.
[allowlist]
description = "global allow list"
commits = [ "commit-A", "commit-B", "commit-C"]
paths = [
  '''gitleaks\.toml''',
  '''(.*?)(jpg|gif|doc)'''
]
regexes = [
  '''219-09-9999''',
  '''078-05-1120''',
  '''(9[0-9]{2}|666)-\d{2}-\d{4}''',
]
# note: stopwords targets the extracted secret, not the entire regex match
# like 'regexes' does. (stopwords introduced in 8.8.0)
stopwords = [
  '''client''',
  '''endpoint''',
]

Refer to the default gitleaks config for examples or follow the contributing guidelines.

Additional Configuration

gitleaks:allow

If you are knowingly committing a test secret that gitleaks will catch you can add a gitleaks:allow comment to that line which will instruct gitleaks to ignore that secret. Ex:

class CustomClass:
    discord_client_secret = '8dyfuiRyq=vVc3RRr_edRk-fK__JItpZ'  #gitleaks:allow

.gitleaksignore

You can ignore specific findings by creating a .gitleaksignore file at the root of your repo. In release v8.10.0 Gitleaks added a Fingerprint value to the Gitleaks report. Each leak, or finding, has a Fingerprint that uniquely identifies a secret. Add this fingerprint to the .gitleaksignore file to ignore that specific secret. See Gitleaks' .gitleaksignore for an example. Note: this feature is expirmental and is subject to change in the future.

Secured by Jit

We use Jit to secure our codebase, to achieve fully automated, full-stack continuous security using the world's best OSS security tools.

Exit Codes

You can always set the exit code when leaks are encountered with the --exit-code flag. Default exit codes below:

0 - no leaks present
1 - leaks or error encountered
126 - unknown flag

Download Details:

Author: Zricethezav
Source Code: https://github.com/zricethezav/gitleaks 
License: MIT license

#go #golang #git #security #secret 

Learn About Kubernetes ConfigMaps & Secrets

Kubernetes provides us two separate objects for these use cases.The first one is ConfigMaps, which we can use for storing general configuration.The second one is Secrets, which as the name suggests is for storing sensitive information.The two are quite similar in usage and support a variety of use cases.

#kubernetes #secret 

How To Create A FullStack Playground using GraphQL And FastAPI 🚀

FastQL - FastAPI GraphQL Playground

Generate a FullStack playground using FastAPI and GraphQL and Ariadne :rocket:.

This Repository is based on this Article Getting started with GraphQL in Python with FastAPI and Ariadne, Read Article to know how to use it.

Overview

• FastAPI is a modern, fast (high-performance), web framework for building APIs with Python 3.6+ based on standard Python type hints.
• GraphQL used to create a schema to describe all the possible data that clients can query through that service. A GraphQL schema is made up of object types, which define which kind of object you can request and what fields it has.
• Ariadne is a Python library for implementing GraphQL servers using schema-first approach.

Features

• Full Docker integration (Docker based).
• GraphQL playground based on Graphene and Ariadne.
• Docker Compose integration and optimization for local development.
• Production ready Python web server using Uvicorn.
• Secure password hashing by default.
• JWT token authentication.
• SQLAlchemy database integration using PostgreSQL.
• Alembic migrations for database schema.
• rabbitMQ (asynchronous) message broker.
• API tests based on Pytest, integrated with Docker, so you can test the full API interaction, independent on the database.

Getting Started

Prerequisites

• Python 3.8.6 or higher.
• Docker.

Project setup

# clone the repo
$ git clone https://github.com/obytes/fastql.git

# move to the project folder
$ cd fastql

Creating virtual environment

• Create a virtual environment using virtualenv.

# creating virtual environment
$ virtualenv venv

# activate virtual environment
$ source venv/bin/activate

# install all dependencies
$ pip install -r requirements.txt

Running the Docker Container

• We have the Dockerfile created in above section. Now, we will use the Dockerfile to create the image of the FastAPI app and then start the FastAPI app container.
• Using a preconfigured Makefile tor run the Docker Compose:

# Pull the latest image
$ make pull

# Build the image
$ make build

# Run the container
$ make start

Note: Running the test on the Container CLI pytest or when you use the command make start the container will be started and the tests will be run before the Uvicorn server is started.

Environment variables

SECRET_KEY= #secret key for JWT token
QUEUE= #rabbitMQ queue name

change all the environment variables in the .env.example and don't forget to rename it to .env.

Preconfigured Packages

Includes preconfigured packages to kick start FastQL by just setting appropriate configuration.

Package	Usage
FastAPI	FastAPI is a modern, fast (high-performance), web framework for developing APIs with Python 3.6+ based on standard Python type hints.
GraphQL	GraphQL used to create a schema to describe all the possible data that clients can query through that service. A GraphQL schema is made up of object types, which define which kind of object you can request and what fields it has.
Ariadne	Ariadne is a Python library for implementing GraphQL servers using schema-first approach.

Contributing

• If you have any questions or suggestions, please open an issue or create a pull request.
• If you are a contributor, please check out:
  • Is your pull request or issue relate with FastAPI?
  • Is your pull request or issue relate with GraphQL?
  • And make sure you take a look at the schema of the GraphQL playground. schema.graphql
  • Also for People who gonna add a new features or fix somethings please make sure that its build on Docker.

License

This project is licensed under the terms of the MIT license.

Author: obytes
Source Code: https://github.com/obytes/fastql
License: MIT License

#fastapi #graphql 

Shamir's Secret Sharing Step-By-Step - Qvault

Adi Shamir’s Secret Sharing is an algorithm that allows participants to share ownership of a secret by distributing shares, which can be thought of as parts of a secret key. In order for someone to gain access to the original secret, a minimum number of shares (the threshold) must be used together.

Example Problem

To illustrate, let’s imagine that a family of four all share a single Bitcoin wallet. This Bitcoin wallet contains a single private key that all members of the family co-own. Because there is a single key, any of the family members can use that key to spend all of the Bitcoins.

The family has a problem: If they each keep a copy, then only one of their copies needs to be compromised to have all the coins stolen. If only one of them keeps the key, then that person may lose it or decide to double-cross the other family members.

Luckily, one of the family members is also a cryptographer. Instead of naively sharing the original key, they use SSS (Shamir’s secret sharing). The family creates four shares and sets a threshold of three, with the Bitcoin key as the original secret. Now, their plan has the following properties:

• They have not stored the bitcoin key in a single place which makes it harder to steal
• Members of the family need to cooperate to spend the Bitcoin, one family member can’t betray the others
• If a family member dies or loses their share, the other three members can still reconstruct the key

Understanding the Threshold

Every Shamir sharing scheme has a total number of shares and a threshold. The threshold is the number of shares required to reconstruct the original secret. For example, with five shares and a threshold of three, you only need three of the five shares to calculate the original secret.

The Math – Lines

One of the fundamental mathematical properties used in Shamir’s secret sharing is the fact that it takes k points to define a polynomial of degree _k _– 1. For example:

• Only one line can be drawn between two points
• Only one possible parabola crosses through the same three points
• Only one cubic curve passes through the same four points
• An infinite number of lines can be drawn through the same point
• An infinite number of parabolas can be drawn through the same two points

The Math – Walkthrough

Let us construct a scheme to share our secret 1954 (S) with 4 (n) shares and a threshold of 3 (k).

First, we randomly choose k – 1 positive integers, so in our case, 2 positive integers. We randomly choose 43 and 12.

Then, we build a polynomial of the form

y = a0 + a1*x + a2*x^2

Where a0 is the secret, and a1 and a2 are our randomly chosen integers. We are left with:

y = 1954 + 43x + 12x^2

Then, we use this formula to create 4 points (shares) that we give to each participant.

Share 1

(x, y) where x = 1

y = 1954 + 431 + 121^2 = 2009

(1, 2009)

Share 2

(x, y) where x = 2

y = 1954 + 432 + 122^2 = 2088

(2, 2088)

Share 3

(x, y) where x = 3

y = 1954 + 433 + 123^2 = 2191

(3, 2191)

Share 4

(x, y) where x = 4

y = 1954 + 434 + 124^2 = 2318

(4, 2318)

Reconstruction

Each participant in our scheme now owns one (x,y) point which is a single share. Remember that we set our threshold to 3 and that 3 points define a parabola (polynomial of degree 2) perfectly. That means that if we use three points, we can draw a parabola and calculate a0 (the secret).

#cryptography #bitcoin #security #cryptography #encryption #scheme #secret #shamir #sharing