Continuous integration and continuous delivery (CI/CD) is a way for delivering apps to clients on a regular basis by automating the app development processes. Any CI/CD pipeline helps with speedy and efficient app delivery, but it does not necessarily make apps safe. Although CI/CD procedures offer many advantages, because of their speed and lack of oversight, they may also raise new security issues. These risks can be reduced, but only if your CI/CD process gives security top priority.
Continuous integration and continuous delivery (CI/CD) is a way for delivering apps to clients on a regular basis by automating the app development processes. Any CI/CD pipeline helps with speedy and efficient app delivery, but it does not necessarily make apps safe.Although CI/CD procedures offer many advantages, because of their speed and lack of oversight, they may also raise new security issues. These risks can be reduced, but only if your CI/CD process gives security top priority.
For a while, one popular method for public cloud authentication with a git version controlling platform was to setup supply credentials, such as a password or token, authentication. These credentials are often kept in Repo as a secret, which the process provides to the cloud provider each time it is executed. On the other side, generating credentials in the cloud provider and then copying them in GitHub as a secret is required when utilizing hardcoded secrets.
With OpenID Connect (OIDC), a new strategy is possible by setting the process to ask the cloud provider directly for a temporary access token. Additionally, the cloud provider must set up a trust relationship that regulates which processes are permitted to request access tokens and support OIDC on their end. OIDC is now supported by a few of providers, including Azure, Google Cloud Platform, HashiCorp Vault, and AmazonWeb Services.
No need to copy your cloud secrets as long-lived GitHub secrets: Can establish an OIDC trust with the cloud provider, change procedures, and request a temporary access token throughOIDC.
Authentication and authorization management: Have more exact control over how processes may use credentials by employing the authentication (authN) and authorization (authZ) capabilities supplied by cloud providers to regulate access to cloud services.
Changing credentials: When using OIDC, the cloud service provider issues a short access token that is only valid for one task before expiring on its own.
ElasticContainer Service (ECS), Elastic Container Registry (ECR), and Fargate are the three AWS technologies we'll be using in this case.
In this real-world example, additional tools are added to CI/CD to guarantee that the organization is adhering to the best DevSecOps practices. Once the developer pushes the commits to the GitHub repo, the SonarQube Static Application Security Testing (SAST)Scanning tool will automatically scan the code for vulnerabilities.
SonarQube is a solution for ensuring code quality and security. Most prominent programming languages are supported, including Java, JavaScript, TypeScript, C#, Python, C, C++, and many others.
When the SAST is complete, the Container image will be built and pushed to the Amazon ECR (Elastic ContainerRegistry) by tagging the image version. After ECR verification, the ElasticContainer Service (ECS) Task Definition file will be updated, and the updated image will be deployed to the ECS Fargate Cluster.
To use GitHub Workflow to authenticate an AWS account, we must first establish trust between the AWS account and an OIDC-compliant IdP. (Identity Provider). OIDC identity providers are IAM entities that represent an OpenID Connect (OIDC)-compliant external identity provider (IdP) service.
When creating an IAM OIDC identity provider, one or more IAM roles must be created. A role in AWS is an identity that does not have its own credentials (as a user does). In this case, however, a federated user who has been authenticated by the organization's IdP is dynamically assigned a role. The company's IdP can now request temporary security credentials to access AWS.
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html
After validating the trust between the repo and the AWS account, instead of utilizing the traditional credential verification approach, the workflow file can use ROLE and REGION GitHub Encrypted Secrets to authenticate. Encrypted secrets can be used to store sensitive information in repository, organization, or repository settings.
OIDC Secrets used for AWS Authentication are clearly displayed in the GitHub Portal Action Section.
By using OIDC to establish a secure connection between the GitHub repository and the AWS Account, we are adhering to proper security practices. This has been a realistic example of how to setup your GitHub Actions build tasks to leverage IAM Roles in AWS safely and conveniently. You may also set up the same OIDC Authentication procedure using a different cloud provider, such as GCP or Azure.
.png)
