 Introduced in GitLab 15.7, restricting tunnel access to a specific environment effectively prevents other environments from being accessed from a pipeline. This feature is part of our CI-CD workflow and is configured in the GitLab agent for Kubernetes, which is the foundational layer for Kubernetes cluster connections. On the left side of this image we see a pipeline execution before any restrictions have been put in place. In order to restrict access to a specific environment, one must add the environment name in this example we are using the staging environment to the configuration of the GitLab agent for Kubernetes. Once the agent configuration has been updated with this restriction, the pipeline only has access to the staging environment and no longer to the production environment as depicted on the bottom right side of this image. So what benefits does this feature offer? Restricting access to a specific environment can help organizations prevent the deployment of untested applications and infrastructure to production, lowering their risk of introducing errors that could cause an unexpected outage. And their ability to restrict access to a specific environment can also help organizations meet the stringent security and compliance requirements and audits. Now let's move on to the demo of this feature. We will cover how to restrict access to an environment. This is part of the CI-CD workflow of the agent for Kubernetes. So let's head to the configuration file of the agent and make an edit to it. We'll go ahead and add the environment to the CI access portion of the file and notice that the environments list only staging as an environment. This means that any pipelines that are running will only have access to the staging environment. Here the agent has detected its own configuration update and it's updated itself. As you can see environment staging, so all the projects that live under group MG will be allowed to only access the staging environment. So let's go to the MyJava application which is under the MG group and before we make a change or run a pipeline let's make sure that the staging and production environments have the same exact application running. As you can see they both say spring is here, they are identical. Now let's proceed to make a change to the application. Let's invoke the web IDE. Let's drill into the source files and there are two files we want to change. One of them is demo application Java and the other one is a unit test called demo application test.java. We need to make the strings inside of each the same so that the unit test will pass and the new string is spring is here only for staging. Let's commit the change, we'll commit the change to the main branch and let's head back to the project. This change already started a pipeline and if we go into that pipeline notice that it has a build stage, staging stage but no production stage. The reason that there's no production stage is that this project and the pipeline for this project does not have access to this environment as specified in the configuration of the agent. So here you see the agent is processing the deployments for staging. The old instance of the staging application is terminating and a new instance which is the updated instance in staging is already up and running. Let's do a get pods again and you see that there's only one instance of the application that has just started 43 seconds ago in the staging environment. The production pod you see in the listing is from a previous pipeline run before the restriction was enacted. Again there is no production stage or jobs for the incremental deployment to production because this pipeline does not have access to production only to staging. This is a previous run from a previous pipeline before we make the change and notice that there are jobs for the incremental deployment to production and in the last pipeline that we ran there is no such a stage. And just to triple check let's go see the running applications. Staging has the updated message spring is here only for staging but production should have the old message which is spring is here only. Restricting access to a specific environment can help organizations prevent the deployment of untested applications and infrastructure to production. Lowering the risk of introducing errors that could cause an unexpected outage and it can also help organizations meet stringent security and compliance requirements and audits. I hope you enjoyed this video and until next time.