DevSecOps
Security actions/settings
Below are listed actual settings/actions how we apply security in to our implementation.
CI/CD
Do not store security tokens to pipelines
Use OIDC authentication
GitHub Actions: https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions and https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services
Sandbox environment
Generally we follow best practices from Home - EKS Best Practices Guides
But below is listed the most significant practices and how to implement those.
IAM
AWS Best practice / general guideline | How to achieve / implement | In action / Jira issue |
---|---|---|
Don't use a service account token for authentication | We are going to use OIDC | |
Employ least privileged access to AWS Resources | Creating own accounts for developers and sandbox admins. Accounts have only needed access | |
Use IAM Roles when multiple users need identical access to the cluster | We are using following groups
| |
Make the EKS Cluster Endpoint private |
| |
Create the cluster with a dedicated IAM role | Our IaC code creates IAM roles for following needs
| |
|
|
|
Multi-tenancy
AWS Best practice / general guideline | How to achieve / implement | In action / Jira issue |
---|---|---|
Namespaces - soft multi-tenancy | When installing BBs to environment we are using namespace | |
Network policies |
| SND-61: Create default deny network policy, except DNS queriesDone SND-62: Create network policy to allow communication between namespacesDone |
Quotas | With quotas, you can specify the maximum amount of CPU and memory that a pod can consume, or you can limit the number of resources that can be allocated in a cluster or namespace.
|
Detective Controls
AWS Best practice / general guideline | How to achieve / implement | In action / Jira issue |
---|---|---|
Enable audit logs | We have enabled
| |
Analyze logs with Log Insights | TODO: Create rules and or use AWS provided: https://aws.github.io/aws-eks-best-practices/security/docs/detective/ |
Network Security
AWS Best practice / general guideline | How to achieve / implement | In action / Jira issue |
---|---|---|
Create a default deny policy | Creating network policy to IaC scripts | SND-61: Create default deny network policy, except DNS queriesDone |
Create a rule to allow DNS queries | Creating network policy to IaC scripts | SND-61: Create default deny network policy, except DNS queriesDone |
Incrementally add rules to selectively allow the flow of traffic between namespaces/pods | TODO ( implemented when first time needed ) | SND-62: Create network policy to allow communication between namespacesDone |
Runtime Security
AWS Best practice / general guideline | How to achieve / implement | In action / Jira issue |
---|---|---|
Encrypt data at rest | TODO ( implemented when first time needed ) | |
Use AWS KMS for envelope encryption of Kubernetes secrets | TODO ( implemented when first time needed ) | |
|
|
|
Infrastructure Security
AWS Best practice / general guideline | How to achieve / implement | In action / Jira issue |
---|---|---|
Use an OS optimized for running containers | We are using EKS optimised AMI for node groups | |
Keep your worker node OS updated | We are using Amazon EKS managed node groups | |
Periodically run kube-bench to verify compliance with CIS benchmarks for Kubernetes | CIS-benchmark check is executed against local sandbox and results are analysed. However this check must be integrated to pipeline. | |
Deploy workers onto private subnets | We are using only private subnets |
Building blocks
Generally security must be handled by BB developing team. But here are some good starting points.
BB should contain tests and tests are executed automatically
Tests should contain also security test. e.g OWASP dependency plugin https://owasp.org/www-project-dependency-check/
BB must go thru API Testing process
TODO add link to API Testing
CVSS scores
Critical (9.0-10.0) score are not allowed
High scores ( 7.0 - 8.9 ) must be analysed before install and take mitigate actions if possible
Lower scores can be installed
How we operate
Generally security has been taken into account in every phase. Team members ensure that DoD ( TODO: add link ) is followed.
More about how we apply security in every DevSecOps phase:
Plan
Create guidelines how apply security
Design how and when security testing are executed
Build
Integrate security to CI/CD pipeline
Sandbox
Periodically run kube-bench
BB
OWASP dependency plugin to check vulnerabilities
Creating and running unit-tests
Test
Test OWASP TOP 10 (if applicable)
Deploy
Using IaC code to create environment, no manual steps
Terraform plan to ensure that changes are valid
Using Access management
Only environment admin can install/manage resources
Operate
Logging is enabled to audit and API level
Secure public API (if any): with limits and DDoS protection
Observe
Actively monitor our environment stage and create events
Access control
Vulnerability monitoring
Resource usage